Re: [RFC] git integrated bugtracking
- From
- Rogan Dawes <lists@dawes.za.net>
- Date
- Jun 4, 2007, 13:29 UTC
- Message-ID
- <466413BC.1080007@dawes.za.net>
- In-Reply-To
- <20070604102037.GB7758@.intersec.eu>
Pierre Habouzit wrote:
Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 5 quoted lines
>> 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.
Show 22 quoted lines
> 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@example.org/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.
Show 8 quoted lines
> 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