On 6/11/07, Pierre Habouzit <madcoder@xxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
