From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Mon, 11 Jun 2007 10:00:48 GMT
Subject: Re: [RFC] git integrated bugtracking
Message-ID: <46a038f90706110300r20dd992excfcb6fbd9d2b8d6c@mail.gmail.com>
In-Reply-To: <20070611084533.GA24327@artemis.intersec.eu>

On 6/11/07, Pierre Habouzit <madcoder@debian.org> wrote:
>   That one is easy. Indeed, the big politics in bugtrackers are ...
> severity-ping-pong, or close-wars. Good example of that is btw:
> http://sourceware.org/bugzilla/show_bug.cgi?id=4509.
>
>   Okay, what would we gain in a DBTS: developer would still be (sorry)
> a perfect asshole with the user. That is a thing we cannot fix. Though,
> the release manager will probably disagree with him. So this bug that
> _he_ considers non existant will be closed in his repository, but still
> remain open in the main one. Meaning that if another developer steps up,
> he'll see this issue is not fixed. Else nobody will have any chance to
> step up, ever.

I've seen all those bugtracker-wars. But they never block a developer
or fellow user from saying --hey, here's a patch. And with a DSCM,
that clears things up quite quickly.

I don't understand how  "Else nobody will have any chance to step up, ever."

> > >  Honestly ? No, because that would be horribly slow (but I'd love to be
> > >proven wrong).
> >
> > What part would be slow?
>
>   The perl scripts. It would perceptibly slow down commits. And I don't
> want that now that I finally have a fast SCM. I just don't want to turn
> git into bzr.

The model I was thinking of was of _not_ slowing down your commits ;-) but

 * Stick to a mostly centralised BTS that tracks a limited set of repos
 * When you push to the public repo, the BTS updates its bug status
 * on git-pull, update a (fast!) local cache of BTS data
 * on gitk use a similar technique to the "follows" line shown for
each commit to display bug info "inline"

cheers,


martin