On Sun, Jun 03, 2007 at 10:17:23PM +0200, Yann Dirson wrote: > 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. > > > 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpFNH6JVLMvi.pgp
Description: PGP signature
