csr21 at cantab.net
Sat Feb 28 20:22:52 UTC 2009
Timothy Moore <moore at bricoworks.com> writes:
> Christophe Rhodes wrote:
>> PS: I know that this is a little bit of a reversal for me, but I begin
>> to see the advantages of bug trackers even if they are not blessed
>> with perfect interfaces. Does the McCLIM project have one, and if not
>> would there be objections simply to turning on Trac on common-lisp.net?
> See http://intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems
Heh. I think the value of a bug tracking system increases as the
inverse of the number of people who have the knowledge and the time to
deal with bug reports. Why? Because if there's someone, or more than
one, who looks at a bug report and either fixes it or ignores it, the
problem has essentially gone away: either the bug is gone or it
probably wasn't that important in the larger scheme of things.
What we have in McCLIM now is \epsilon active developers. This makes
a bug tracker infinitely more useful, because it can then act (if
people get on board, anyway; that's usually the difficult bit) as a
repository of knowledge, even if that knowledge is "this doesn't work"
-- and when the blue moon in the month of Sundays comes around and
someone has some time to spend on fixing something (because, say,
they're using McCLIM in some random project of theirs), less time
needs to be spent wondering what it was in the first place that wasn't
working any more.
Of course, my perception is coloured by the fact that, at least this
month, it's me who's finding bugs, hacking around them, wondering
whether what I'm fixing is actually a bug rather than someone's
intentional behaviour, and generally getting all angsty that people
might think that I'm taking responsibility...
Bah. Looks like you're having way to much fun.
More information about the mcclim-devel