Re: [RFC] git integrated bugtracking
On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
Show 29 quoted lines
> On Sun, 3 Jun 2007, Pierre Habouzit wrote:
>
> >On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
> >>Pierre Habouzit <madcoder@debian.org> writes:
> >>
> >>> 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 ;
> >>
> >>That's my feeling too. "Commiting" bug information in the tree is only
> >>half of a good idea. You want to be able to say, after the fact, "This
> >>commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
> >>merging a branch would automatically close bugs fixed by this branch
> >>is a really cool thing.
> >
> > That would work with notes, as while merging you'll get the notes of
> >the commit in your branch, *and* the note about the fixing patch. So
> >there is no loss of "concept" here. In fact that was the thing that I
> >looked for. Notes are good. They just may not be enough to write an
> >in-git bugtracking tool, as a bug needs the "notes collection" concepts,
> >and maybe a few other.
>
> how would you identify bugs in such a way that they will match up when
> you merge different trees?
well, because they will be sha1's, a git object. And when it's a
duplicate, well, let's face it, not bugtracker helps *automatically*
tracking duplicates. The merge work is up to the QA people. Yeah,
bugtracker won't do all the tracking. In a way, that's good, that means
there is still place for humans in that world :)
Show 5 quoted lines
> if you can manage to do this it sounds like a great idea. but I'm not
> seeing a good way to do it at the moment. the answer may be a combination
> of a number of factors.
>
> 1. bug number doesn't work well in a distributed environment
Sure, SCM revisions either. But git solved that once, I don't see why
the solution found at that time would be less of a solution now :)
> 2. something based on indentifying the cause of the bug (commit id + file
> + line????) will only work after you know the real cause of the bug
It does not work in a real world, where real user don't grok code.
> 3. description is worthless, too many ways to describe things that have
> the same underlying cause
Sure, though it could help finding dupes. BUt in my experience what
helps most, is fine grained categorizing, because you end up with few
bugs for a given component, and "same" bugs end up actually being near
in the UI or query tool. Of course it let space for bugs that get
actually miscategorized. But hell, my experience is also that many bugs
are discovered as beeing fixed years after the fix anyway.
I don't plan fixing all that stuff, it can't really be. I just would
like to create a tool that isn't as painful for the programmer as
bugzilla (or rt or ...) is, while it would still be as pleasant and easy
to stick a web UI for the users over it, hence not making the user
experience less pleasant.
My experience with bugtracking is that the most efficient way to deal
it is to let the programmer in charge of the responsible module deal
with those bugs. What programmer aren't willing to do is the triaging,
and pulling the bugs off a distant database/UI/.. off something that
isn't in their usual workflow.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>