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. > 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. Linus - 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
