Re: [RFC] git integrated bugtracking
On Sun, Jun 03, 2007 at 10:17:23PM +0200, Yann Dirson wrote:
Show 18 quoted lines
> On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:
> > On Sun, 3 Jun 2007, Pierre Habouzit wrote:
> > > Though there is a few design issues I have, that block me from doing
> > > first decisions about how to implement some kind of Proof of Concept. My
> > > main problem is: should I put this bug tracking system in the repository
> > > it tracks bugs for, or not.
> >
> > Make it a separate (and independent) branch of the repository you track,
> > and then you can do it - or not do it - as you want later.
>
> And since we have cheep branches, we can even have one BTS branch for
> each project branch.
>
> But then, since we probably want git-merge to merge the BTS branch
> when present in the local repo, that would mean adding some support in
> the core porcelain - eg. a config option declaring some coupling
> between a branch and its bug-tracking pal, so git-merge can be taught
> to merge it too.
In fact, I don't think so. In my answer to Linus, I was almost writing
the same thing as you. In fact, no, we don't want a BTS branch per
project branch. We just want to be able to list commits where we found
the bug, and commits where we didn't found them. Lets call them good and
bad commits (yeah, ring a bell ;p). One of the "good" commit will be
better than any other good one, as it'll be the "fixing" commit. Or one
of the fixing commits, as you may have different ones if you just
cherry-pick just the patch in a stable branch.
So what you need is a way to link a bug to git objects, namely
commits. Linking to files or subtrees also makes sense. In fact we need
to link bugs to well git objects (what a shock :D).
And if you want to know what affects a given branch, well, you need to
list bugs whose affected objects are present in that given branch. Even
if you have one branch per project branch, as the bug branch chronology
will not be the same as the project's one, you'll still need to answer
the previous question the very same way. And I don't think it's be more
complicated if all project's branches (or may project's branches) are
dealt with or not.
Show 14 quoted lines
> > > I mean, the immediate idea is to have some .bugs/ directories (or
> > > alike). This has many good properties, e.g. for projects like the linux
> > > kernel with its many subsystems or driver, it would make sense to have
> > > per driver/subsystems/... bug packs, and move bugs from one pack to
> > > another would be the way of assigning bugs to different modules.
> >
> > I would suggest _not_ doing this kind of mixing. I think it might be
> > appropriate for some cases, but I don't think it's appropriate in general.
> > Partly because I don't think the people who change the bugs are at all
> > necessarily at all the same people who actually do development.
>
> The same functionality could probably be obtained through more
> annotations (ie. record which subsystem the bug relates to, just like
> any other property of the bug).
Well, annotations are certainly useful to create a [git object] ->
[bug #id] map. That way, listing bugs in a branch is "just" a matter of
listing still open bugs in the ancestry graph. Sadly, if I'm not
mistaken, this is at least a linear operation wrt the number of objects
in the branch (supposing that access to objects is O(1)). IMHO that's
not good enough, but I'm not really in the implementation stage yet.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>