From: Rogan Dawes <lists@dawes.za.net>
Date: Mon, 04 Jun 2007 13:29:32 GMT
Subject: Re: [RFC] git integrated bugtracking
Message-ID: <466413BC.1080007@dawes.za.net>
In-Reply-To: <20070604102037.GB7758@.intersec.eu>

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

>   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