On Fri, 13 Jan 2012 15:48:43 +0100
markus schnalke wrote:
>
> No, put meta information in the header, where it belongs to. anno(1)
> from MH does it for you.
>
> Any newer message might change these attributes. Well, you might want
> to update these attributes in the first message, to have the latest
> state there, but in its header. Also, the change history would still
> be available. I don't know how debbugs stores the meta data, but their
> change history is great. Be sure to play with it.
>
What makes old plain TODO interesting is zero setup offline usage and
direct access to data (checkout repository and open in your favorite
editor).
I don't see how Debbugs is improvement in this case - hide data behind
mailing list. Why I need to setup MH (or other mailing client) and
download mail archive or use fancy web interface just to look up (read
access) for existing issues?
I would say there is no difference between flat files database and SQL
database if you can't easily play with it (at least read access). Some
random note from Debbugs presentation paper [1]:
>
> Unfortunately, the ”metadata” is just the raw HTML notes included in
> the web pages, which isn’t amenable to translation or parsing.
>
Mbox formats are human readable, and file per issues makes it
accessible. Throwing everything into one file (like mbox mail archive)
or splitting everything into zillon files (file per message like
maildir) requires additional techniques/tools just to find interesting
issue.
History of issues in many cases is just garbage. What I need is status
of issue and responses to specific issue. Git/Mercurial or any other
version control system can provide history if you really need that.
Almost every open source projects nowadays gives read access to source
code repository, so what is the point of writing custom log format?
This way you can also track interesting issues without subscribing to
mailing list or using web interface.
Right now best interfaces for issue trackers are search engines (e.g.
Google "site:adress_of_bug_tracker interesting issue") and mail
archives (Gmane and so on) in my opinion.
[1]
http://debconf5.debconf.org/comas/general/proposals/file/paper.ps
Received on Fri Jan 13 2012 - 17:28:19 CET