Re: [RFC] git integrated bugtracking

[david@lang.hm]

On Sun, 3 Jun 2007, Pierre Habouzit wrote:

> 
> On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:
>> 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 :)
>
>> 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 :)

git's tracking of revisions works becouse it's tracking the content, it 
doesn't care _how_ the content got that way, if it's the same it's the 
same and will have the same hash.

with bugs the reports aren't the same so you can use the sha1 to track a 
particular entry/tag/comment but not to identify the bug itself

>> 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.

fine grained categorization is something that takes place long after the 
bug is reported, users don't know how to correctly categorize bugs any 
more then they know what code caused the bug.

>  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.

this only works if someone goes to the work to send the bugs to the right 
programmer. in many cases this is non-trivial.

David Lang