Re: [RFC] git integrated bugtracking

> On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
> >
> > Call me a fool, but writing a <new> bugtracker looks like a
> > boil-the-oceans scheme.
>
>   Sure, what if I like it anyway ?

> > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is
> > what is going to make the difference. Most of those have already the
> > ability to "link" to one or more commits -- after the commits are done
> > and in GIT.
>
>   Sure, you can do that and still inherit from the many downsides of
> those tools: central, needs another separate tool to work with, and a
> tool that nowadays tends to eat 500Mb of your memory if you take the
> most hype implementation of it (Yes I'm describing a web browser), that
> is slow like hell (because yes, there is many clients at the same time
> on the central server, that is overloaded like hell), and so on.

> > So you can tell your bugtracker
> > - which commit fixed it -- usually auto-linked if you include the
> > bugnumber in the commit message
> > - which commit added the test -- auto linked as above
> > - which commit introduced the bug -- if such thing exists and someone
> > digs it up
>
>   yeah, that is what bugtrackers already do. Though, that's of no use
> for release managers. What is useful is what people call "milestones" in
> trac e.g., meaning a set of bugs that has been flagged as needing to be
> fixed. And what a release manager need is a tool to deal with this set
> of bugs as a whole.

>   That's the same argument that Linus has against per-file tracking.
> Also atm when you e.g. backport a patch that fixes this or this bug,
> you're no BTS helps you tagging the bug as fixed in that branch as well.
> Not to mention that BTS I know do not make any use of the commits DAG.
> And for a very good reason, there is no real DAG in many existing tools
> (svn, cvs, ...).

> > 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.
>
>   No it should not, because it can't. I want the distributed and
> Bug status spanning-DAGS be a central feature.

> > Bugtrackers are co-owned by developers, users and (where they exist)
> > project managers.
>
>   That's exactly why distributed rock. Because everyone could _really_
> own _his_ bugtracker. This solves the same range of ACLish issues git
> solves with respect to the code.

> > Well - hmmm. Git's database is great at tracking _content identity_.
> > But a bug's content identity (description+comments+status) changes all
> > the time. I don't think it's naturally a good match.
>
>   Oh, because the code never changes. Doh, how stupid I am :)
>   No, really, you name your bug after the sha hash of the first report,
> I think that's pretty obvious. That gives you a bug name. Then you ask
> git for "what's the current sha for this bug in the tip of the BTS
> branch", then you ask "so now what this new sha is pointing to in the
> code". That's a small indirection that I suppose is bearable.

> > And at git's end we can get the smooth integration using/abusing that
> > loose coupling strategy. So if git-log/gitk/qgit grow some hooks that
> > can be used to perform a lookup... I can think of a perl script that
> > gets events for each SHA1 that git-rev-list produces and returns one
> > bug number, url and title (or more than one) that then git-log / gitk
> > / qgit / annotate can use to further "decorate" the commit info in a
> > similar style to what gitk is doing now with head names in each
> > commit.
> >
> > Would that fit your vision of a nicely integrated tracker?
>
>   Honestly ? No, because that would be horribly slow (but I'd love to be
> proven wrong).