Re: [RFC] git integrated bugtracking

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

On Sun, Jun 10, 2007 at 18:59:13 +1200, Martin Langhoff wrote:
> On 6/10/07, Pierre Habouzit <madcoder@debian.org> 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@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]