On Sun, Jun 10, 2007 at 18:59:13 +1200, Martin Langhoff wrote: > On 6/10/07, Pierre Habouzit <madcoder@xxxxxxxxxx> wrote: > > FWIW I've begun to work on this (for real). I've called the tool > >"grit". You can follow the developpement on: > > > > * gitweb: http://git.madism.org/?p=grit.git;a=summary > > * git: git://git.madism.org/grit.git/ > > Call me a fool, but writing a <new> bugtracker looks like a > boil-the-oceans scheme. I don't know about any *distributed* bug tracker, which is the point here. We have several distributed version control tools, but no other distributed tools for the other tasks in configuration management. > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is > what is going to make the difference. It would certainly be useful. But the problem with these bug trackers is, that they don't go all that well with how many hackers work. And the less they fit with distributed workflow. - The web interface is usually not a good match for the problem. Email interface is better in many respects, but it still does not cut it. - You can't really use the ability of version control to work disconnected, when you don't also have the bug information. - Distributed version control is designed to decrease the workload of the central maintainer(s) while keeping him in control. But with centralized bug tracking he still has a lot of work with that that the mob can't help him with. It helps if the bug tracker can close bugs based on something in commit-log, but you also need to see what it is that will be closed, which requires integrating the bug tracker into the version control. The other thing is, that a good bug tracker also needs to be integrated with the *mailing list*. The major part of bug tracking is discussing those bugs and discussions usually take place on mailing-lists (and on irc -- integrating that as well would be nice too). I've actually already seen some attempts at something like this project. The first one was for GNU Arch. Instead of using a bug-tracker, there was a branch where each bug had it's mbox with all the relevant data. This mbox was moved between directories depending on it's state. AFAIR there was no tool to maintain it, just a description of the workflow. (Tom Lord called it "the game". See eg. http://www.dasbistro.com/~sam/mail/tom-lords-game) The other attempt is obviously the Bugs Everywhere thing. A related thing is Bazaar's "Bundle Buggy". It tracks patch submission rather than bugs, but it is roughly what I meant by the "mailing list integration" above. It "reads" the mailing list, watching for anything labeled [PATCH] or [BUNDLE] with patch or bundle (bundle is bazaar's extended patch) attached. It also watches for replies with review (review outcome is stated with "-1" (veto), "-0", "+0" and "+1" (ok)) and with further patches/bundles (updated versions of the patch). > [...] > > And definitely, if you use git as an alibi to write a new bugtracker, > don't use the "works only with git" as a feature. It should work with > as many SCMs as possible. If it uses git as it's database, which it probably will, it will definitely require git. Now it should be possible to have the code in different version control, but it would be integration with things like git format-patch, that will really make it cool stuff -- and that won't work with other version control out of the box. > OTOH, that's just me, I'm lazy and like to work on already-successful > projects that are 99% there for my needs (and where I can add that > 1%). Yes. But for many people current bug tracking tools do NOT work 99%. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
