Re: [RFC] git integrated bugtracking
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- Jun 11, 2007, 10:00 UTC
- Message-ID
- <46a038f90706110300r20dd992excfcb6fbd9d2b8d6c@mail.gmail.com>
- In-Reply-To
- <20070611084533.GA24327@artemis.intersec.eu>
On 6/11/07, Pierre Habouzit <madcoder@debian.org> wrote:
Show 11 quoted lines
> 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."
Show 8 quoted lines
> > > 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