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. > > 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). Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
