On Fri, Jan 13, 2012 at 05:28:19PM +0100, Paul Onyschuk wrote: > What makes old plain TODO interesting is zero setup offline usage and > direct access to data (checkout repository and open in your favorite > editor).
and then it turns into a huge mess when some vim nerd has expandtab turned on. > 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? this works both ways. why do I need another code checkout just to look at existing issues? you clearly already have a mail client, you're clearly already subscribed to lists. > 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]: I can't even begin to describe how much worse an RDBMS backing store is as an idea. I don't care what format gets used as long as it isn't binary (i.e. sqlite, mysql, db44, other such shit) > 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. when the spam comes in you're going to want a way to delete that. from a tool-writing perspective that's probably easiest on maildir. > This way you can also track interesting issues without subscribing to > mailing list or using web interface. So what? With a mail interface you can track interesting issues without having to install Python and check out a mercurial repository. > 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. Note that 'hg repos' wasn't on the list you just provided. Mail archives were. debbugs is a bit overblown. As a systems administrator I've had the profound displeasure of interacting with dozens of issue trackers over the years; everything from RT to Trac to JIRA and on and on. The problem is always the same: people want bug trackers to do too much. All you really need is a good mail gateway and a decent way to browse. A mailing list, with the archive accessible in source control of some kind, sounds absolutely fantastic. All you really need as far as metadata is a string for project name, a small enum for status (i.e., new, in-progress, fixed, rejected), and an index number. The Agile programming idiots will tell you different, but anything more than that list is a completely useless distraction. I used to be partial to werq[1] (no relation to Uriel's werc), but that was long ago and I might be remembering it more fondly than it deserved. Best Practical started work on something called sd[2] which was backed by their weird distributed db called Prophet. The backing store and replication mechanisms were a little ridiculous, but at least it shows that even Best Practical considers the bug-tracking problem unsolved... and they've been working on RT since the dawn of time. 1- http://www.math.duke.edu/~yu/wreq/ 2- http://syncwith.us/sd/
