Pierre Habouzit writes: > Hi, I'm currently trying to think about a bug tracking system that > would be tightly integrated with git, meaning that it would have to be > somehow decentralized. > > 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. > > 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. > > Also, a good thing is that when you "report" a bug, it gets commited > in the repository, and taints all the commit chilren, until you commit > the closing patch. This allow a release manager to rapidly _see_ if his > stable branch has this or this bug. > > OTOH it comes with many problems. First, and most obvious IMHO, it's > that it'll mean bugs will have to be pulled into the mainlines. Let's > take example with the linux repository, I'm not sure Linus would be > really keen on doing rounds of bugs pulls, not to mention it'll bloat > the repository somehow. > > The other problem I see is that at the time a bug gets reported, the > user knows it's found at a commit say 'X'. But it could in fact have > been generated at a commit Y, with this pattern: > > --o---o---Y---o---o---o---o---X---o---o--> master > \ > o---o---o---o---o---o--> branch B Mainly for that reason, I would suggest having it outside the code base's namespace: probably a different root in the same $GIT_DIR, but I can see people wanting to have a separate $GIT_DIR. If the database tracks bugs by what commit(s) introduce or expose the bug -- at least once that is known -- then you get nearly free tracking of which branches have the bug without having to check out largely redundant trees. Michael Poole - 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
