Re: [RFC] git integrated bugtracking

["Martin Langhoff" <martin.langhoff@gmail.com>]

On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:
> > 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.
>
> You are a brave person to say this (no sarcasm --- I wish I
> were, too).
>
> On one hand, I very much applaud and appreciate your comment for
> injecting sanity to the discussion.  On the other hand, if Linus
> had such an attitude, we might not be hacking on git right now.

Thanks for the reply - sorry for being a bit of a stirrer ;-) Yes, I
do appreciate the irony and I'd have never started git. If anyone
really wants to do their own bugtracker... be like Linus not like me
(a mere follower) ;-)

> After looking at the above existing alternatives, some brave
> soul might decide and say, "Hey, I can write something better in
> 2 weeks" ;-).

Definitely. But that takes a deeper look into the above alternatives,
and probably a good perspective. I hope noone takes offence if I say
that -- as a user of several bugtrackers over ~10 years -- I haven't
yet read anything in this thread that is exciting.

And "it's closely integrated with git" can actually be a misfeature.
Cool if it's what gets you going, but not enough for world domination
;-)

> All of your examples are going from a single bug to commits, but
> from a release person's point of view, you are never interested
> in a single bug, just like a top-level maintainer is never
> interested in a single file.  A release person would want to go
> in the reverse direction: from a commit range to a set of bugs.

That's right. It's not that hard to correlate commits-in-the-changelog
and ask the bugtracker to produce a "tracker changelog" showing all
the bugs/tasks that link to the commits (with that liberal view of
"links to" discussed before). Formatting of the tracker changelog _is_
tricky but that's due to the ambiguities in those relationships.

(In Moodle I use JIRA, a non-FOSS tracker, and it does exactly that. I
think it has some notion of CVS branches, and where tags sit, so you
can ask for a report of which bugs are fixed in the release you are
preparing on branch X).

> What bugs were fixed and what regressions were introduced during
> this release cycle.  While embedded ticket numbers in commit log
> messages would certainly help, a change made to fix a particular
> bug may fix another as its side effect, and the develeoper who
> did the change may not know about the latter when the commit log
> message is written.

I agree it's useful, but I don't think it has any benefit having it in
the SCM _at all_. Having them in the BT is a lot more flexible -- and
the fact that git has stable commit IDs makes it easier to integrate
in a BT; as the BT can spot that the commit fixing bug 123 is now
merged into head ZZ as well as head YYY.

So the BT holds "external tags" to your commits. Lots of them. With a
ton of data. And that's great -- in fact there's no stopping it -- the
stability of SHA1s means that the whole internet holds tags to your
repo. Every time a SHA1 (or output of git-describe) is mentioned in a
mailing list, wiki or forum, there's a tag.

Now, to rule the world, BTs gain a lot more from being able to
integrate with different SCMs, automated test systems (like
tinderbox), MTAs (debbugs), wikis (traq), stats tracking for PHBs
(bugzilla), etc. So loose coupling wins here, and git's SHA1s are
great for that.

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?



martin (who's now thinking how to craft a proof of concept)