On Sun, Jun 03, 2007 at 12:07:44PM -0700, david@xxxxxxx wrote: > >>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 Do you see any problem with taking as bug id the hash of the first entry submitted ? Just like in a classical BTS, the bug id gets allocated at submussion time. Further informations then get associated with the initial report - here that would problably translate into the initial report being an annotation to a source commit, and further information being annotations to the initial annotation. > 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. Is that a problem ? > > 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. This is he work of a QA team, and although it is not as common in the Free Software world as it should be, there are people willing to do the job. This discussion is about giving these people a better tool to help them focus on the tasks where a human being is really needed. Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
