Re: [RFC] git integrated bugtracking

On 6/11/07, Pierre Habouzit [off-list ref] 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."

quoted

quoted

 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