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
Sadly, the bug report has been commited at 'X', hence it does taints
branch B. As "inserting" or "moving" 'X' commit before the branch is not
an option as it would rewrite history, that becomes also a major no-go
for in-tree collecting of bugs.
Last of all, I'd also like to have a design where bugs pulls do not
create too much painful merges and conflicts. If we e.g. say that a bug
is a status file and a mbox of comments (makes sense to me), the mbox
can be merged easily (concatenate all mboxes, and purge duplicates), but
the status file is quite problematic on its own too.
So here are the first ideas/problems/remarks I have with that. I'd
be thrilled to have your comments about those points.
PS: What I left over, is why I wanted such a tool. Programmers tends (or
say I tend to, maybe I'm over-generalizing, but I seem to remember a
thread on the lkml where Linus was basically saying the same) to
hate bugzillas and such out-of-tree tool because they suck, and do
not really fit in the programming cycle. I'd rather see a
bugtracking system where the backend is in-tree, basically mboxes so
that you can read them easily with your favourite MUA, as well as
adding new comments in it the same way. It also accommodates with
linux-like workflows where bugs usually are sent on the lkml, a bit
like patches and pull requests are handled. That's the reasons why I
came with this idea.
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpYJj2eaiQ90.pgp
Description: PGP signature
