Launchpad Bugs feature

[James Westby]

On (16/04/07 12:32), Wouter van Heyst wrote:
> On Sat, Apr 14, 2007 at 07:46:48PM -0700, Robey Pointer wrote:
> > We have a system like this where I work.  Commits can be associated  
> > with a bug, and the commits show up in the bug report.  It is not  
> > unheard of for a bug to require more than one commit.  Sometimes you  
> > think you solved the bug but there was a deeper issue. :)
> > 
> > So I'd be opposed to using the word "--fixes" there.  Something like  
> > "--bug" would be more honest.

I think you have a very valid point here Robey. What you suggest also
fits in better with the non-versioned nature of the properties, so as
you say one commit doesn't always fix a bug, and closed bugs do not
always stay closed.

Does adding this feature using rev-props make it difficult to change to
another model later that fits in more with the nature of bugs? Is this
better left to a full blown system like bugs-everywhere? I guess there
is a middle ground that can suit most people well.

> 
> Referencing a bug is certainly nice, but the Debian bts style of closing
> bugs on the upload of a package is invaluable too.
> 

Yes, it works very well, but the BTS also implements a sort of
versioning to help in this.

Perhaps we can explore extending the current code to work better with
individual systems where we know how they work. In .deb packaging the
bug closing goes in the changelog with a known syntax, and is then often
copied to the commit message. Now it can go on the command line, and
also be closed with an email to the BTS, or at least tagged pending with
the upload closing the bug. There is plenty of opportunity to
consolidate this, and some work has already been done on some of that.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256