On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@xxxxxxx 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@xxxxxxxxxx> 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 :) > 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgp54Fm3rf9UE.pgp
Description: PGP signature
