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
