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/
Received on Fri Jan 13 2012 - 19:17:13 CET