Pierre Habouzit wrote:
For that part, as the "right" way to deal with bugs is IMHO through
mail, my heart balance between a ${bug_sha1}.mbox or a ${bug_sha1}/
maildir. The former avoids to bloat the files, the latter avoids
painless merges (chance to have a conflict in the comments is near zero
through maildirs) but would see 3 directories (cur new tmp) be spoiled.
One downside of using maildir (which I agree has several desirable
properties), is that the filenames include characters that are illegal
on various platforms (specifically ":" in Windows). This is quite
unfortunate.
In addition to that a ${bug_sha1}.status (or alike) flat file would be
needed to store metadata about the bug (who it is assigned to, which
module/category it's in, ...).
Note that mails are mostly textual, flat, and allow attachments,
signature, whatever... and are IMHO very well suited for a bugtracking
use.
I think it would be very neat to be able to use the built-in mechanisms
in mail clients for threading, etc, and handling attachments, sorting
and filtering. Tracking things like who a bug is assigned to wouldn't
work too well, but I imagine that many kernel developers have fine tuned
their email clients to such a degree that it wouldn't be impossible :-)
I'm not familiar with how messages move around in {cur,new,tmp}, but I
suspect that if we simply make a convention that all mails are created
as "read", then we won't have clashes between developers holding some
bugs as unread, etc while others have already read them.
Closed bugs would be deleted from the filesystem, but would obviously be
available via the history.
IMHO we should keep the .status file for closed bugs, and use the
history to lookup for the content of the mail{box,dir} if needed.
Maybe.
Merging is also easy, it's just a matter of merging the "mails".
Yes.
Cloning bugs is just a matter of copying a report.
etc… every usual BTS operation is mapped trivially on FS/git
operations. And that's not really surprising, as bugs are contents, and
git actually tracks contents right :)
Indexes or categories could be implemented by means of symlinks/symrefs
in a different set of "index directories". e.g.
/categories/drivers/deadbeef -> ../../bugs/de/adbeef
/assignedto/joe@xxxxxxxxxxx/deadbeef -> ../../bugs/de/adbeef
or similar. These might not be strictly necessary, since all that
information will be in the report anyway. Perhaps the indexes would be
stored simply as cached data, and rebuilt if out of date.
IMHO that should be in a cache, all valuable information would be in
the *.status files anyway, it's just a way to index them. FWIW I think
this should be dealt with in a higher level tool. What is needed first
for the developer is a way to deal with a bug he knows is here. Dealing
with large collection of bugs must be built on top of that, and is easy
to keep up to date through proper hooks.
Yes, hooks might be the right approach for this.
IMHO the sole features it should provide and design specifically are:
* the efficient linking with the rest of the repository (through
annotations, decorations, or whichever implementation) ;
* the storage backend, in a supple enough way to allow usual
operations (threading, answers, attachments, use through mail or
{web,G}ui, ...)
* versioning of the BTS datas.
The rest can just be built on top of that.
Agreed.
Rogan
-
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
