Re: [RFC] git integrated bugtracking

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4488 bytes --]

On Sun, Jun 03, 2007 at 03:48:29PM +0200, Johan Herland wrote:
> On Sunday 03 June 2007, Pierre Habouzit wrote:
> > On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:
> > > Pierre Habouzit writes:
> > >
> > > >   The other problem I see is that at the time a bug gets reported, the
> > > > user knows it's found at a commit say 'X'. But it could in fact have
> > > > been generated at a commit Y, with this pattern:
> > > >
> > > >   --o---o---Y---o---o---o---o---X---o---o--> master
> > > >                      \
> > > >                       o---o---o---o---o---o--> branch B
> > > 
> > > Mainly for that reason, I would suggest having it outside the code
> > > base's namespace: probably a different root in the same $GIT_DIR, but
> > > I can see people wanting to have a separate $GIT_DIR.  If the database
> > > tracks bugs by what commit(s) introduce or expose the bug -- at least
> > > once that is known -- then you get nearly free tracking of which
> > > branches have the bug without having to check out largely redundant
> > > trees.
> > 
> >   Sure, but if it's completely out-of-tree, then cloning a repository
> > don't allow you to get the bug databases with it for free. I mean it'd
> > be great to have it somehow linked to the repository, but also I agree
> > that not everybody wants to clone the whole bugs databases. So maybe it
> > should just be in another shadow branch that annotates the devel ones.
> > Hmmm I definitely need to read the git-note thread...
> 
> I guess I'm the one responsible for starting that git-note thread...
> 
> For the moment, I'm busy implementing some concepts that came out of that 
> discussion (refactoring tag objects and building some infrastructure needed 
> to support notes without the drawbacks present in my first version).
> 
> Hopefully I'll have a proof-of-concept ready before too long. In the 
> meantime I'll be happy to answer questions you might have.
> 
> Regarding the notes themselves, I thought about possibly using them as a 
> link between the repo and the bug tracker, with some glue code in between 
> for making the connections. I haven't thought about integrating them more 
> deeply into a bug tracker, but it might be worth thinking along those 
> lines, especially for the kind of system you're proposing.

  Yeah, now that I read that thread, well yeah, I think notes are a hell
of a good concept for my ideas. I mean, a bug report would be basically
a collection of notes:
  * the bug has been found at this commit ;
  * the bug has been not-found at this commit ;
  * this commit is a fix for that bug ;
  * this commit enhance features for that wish and so on.
Some other bits are more followup comments and are disconnected to
commits, but could be attached to the "bug object" whatever would be
used for bugs, the whole concept is blurry anyways, we're just
discussing ideas :)

  Though, for a good bug tracking system, you need to be able to answer
some kind of questions fast enough:
  * list bugs that affect a given stage of the repository
    (tag/branch/commit/...) ;
  * be able to trace history of a given bug (yes, it's fairly obvious,
    but unlike many other bug tracking systems, for us it would not be
    contiguous, so it's not necessarily a O(1) operation) ;

  Other things nice to have is textual search, git-grep can help of
course, but that's an operation you do often with a bug tracking system,
and you expect it to be faster than git-grep is (though maybe an
optionnal index can be built around the notes for that purpose and not
be versionned ?).

  Another think that notes do not address are another operation we
usually do on bugs: merge (or duplicates). There is a think I hate in
bugzilla and love in debbugs, it's that duplicate bugs are closed in the
former, and merged in the latter. When two bugs are the same, their
history are often *both* valuable, and you really don't want to lose one
half, you want to merge them. And you also want the option to "unmerge"
them, but for that the better option is to have the ability to duplicate
a bug (aka debbugs cloning).

  Anyways it's just gossip, but maybe someone will have a brilliant
ideas, so I'm just throwing my thoughts into this mail :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]