Re: [RFC] git integrated bugtracking
On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:
Show 24 quoted lines
>
>
> 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.
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.
>
> 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@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>