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. > > See as an example the git "todo" branch, ie you can always look at what > Junio may or may not be planning with a > > git show remotes/origin/todo:TODO > > which just shows the "TODO" file in the "remotes/origin/todo" branch. > > The same approach could be done for bug tracking: you *could* check out > the bug-tracking branch separately (and you can create a repository that > has _only_ that bug tracking branch, or _only_ the actual development > branch in it), but you could also access it without even checking it out > at all, and mix the two projects in the same repository. Well I went that way, but we loose the quite cool "if I branch my repository I branch the bugs coming with them too"-feature. And I'd be sad to give that up. But maybe it's an error to want to use git to encode that relation. [10 minutes of pondering later] Well yes, I think it's basically an error to encode the bug dependencies in git branches and so on, because bug tracking is often done asynchronously from devel. So you'll have to assign bug to parts of the history that are already cold from a devel point of view. My conclusion is indeed that a separate branch is really the way to go. That does not tells how I'll be able to answer the usual "what are the current opened bugs in my branch" question fast, but well, one step at a time. > > 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. > > IOW, bug-reporters obviously have to have write access to *some* > bug-tracking thing, and I don't think you want to try to merge the > bug-tracking together with the real development. I agree, but I don't see how it's very different from you not trusting the average kernel contributor and wanting your lieutenants to ack patches first. My point is, the user-exposed part doesn't *has* to be pushed in the mainline repository, it could be in ... the bugs repository, from which developpers could pull some bug reports that are worth. Or you can also have more layers if you have a QA team in charge of the bugs. Possibilities are endless, and well, I don't pretend to be the one that will teach you that :) Though I don't like 100% the idea of a .bugs repository. The reason why I came up with that, is that (experience talking), as a developper/maintainer/...whatever I have to get in touch with the reporter. Most convenient way : mail. So I want to be able to use `$MUA -f /path/to/bug/mbox` to answer, because this is the sole operation that makes sense. Though I suppose it could be easy to make a thin wrapper that does a local checkout calls $MUA, and commits the new mail. So I'd easily give up on that, as I acknowledge I've no real reasons to design it that way. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpUb2YwgFoZX.pgp
Description: PGP signature
