[mcclim-devel] Yet another bug for the bug list
Christophe Rhodes
csr21 at cam.ac.uk
Sat Feb 19 11:30:48 UTC 2005
Paolo Amoroso <amoroso at mclink.it> writes:
> Christophe Rhodes <csr21 at cam.ac.uk> writes:
>
>> I'm sure most of you know this already, but windows opened by
>> OPEN-WINDOW-STREAM are not automatically closed when their parent is
>> closed, even if they share the same event queue -- and once the parent
>
> Could you please add an entry here?
>
> http://mcclim.cliki.net/Bug
>
> It's not that I'm lazy and I don't want to do it myself (I'll gladly
> do it if you can't). It's just that I'm trying to spread the voice
> about the above unofficially official bug list.
Yeah. I understand what you're trying to do here -- but I'm uncertain
that it's the best use of resources...
The issue I have is that I've used a raw cliki-based bug tracking
system before -- entomotomy -- and while it was by no means an
unmitigated disaster, I think it would be fair to say that for those
who had the most interaction with it, it was more work than it needed
to be.
What I would like to see is something which can be driven by e-mail,
much like debbugs, working maybe from header information, maybe from
stuff in the body. So when a bug report like mine arrives, someone In
Charge of Bugs forwards the mail on to mcclim-bug at common-lisp.net,
say, with a few commands in the new body:
open open-window-stream-windows-not-closed-by-parent
submitter csr21 at cam.ac.uk
thanks
and then the body of the original message, or even just a message-id,
if the system would be smart enough to convert that to a URL to the
mcclim-devel archives. Closing a bug should likewise be done by
e-mail; discussion can be done over the mailing list, with any
particularly pertinent messages likewise forwarded to the magical bug
system (with command "addto" or something).
I suppose what I'm getting at is that I've interacted with bug
trackers that are so much better in terms of convenience than an HTML
textarea that I'm pretty unwilling to spend my time with a vanilla
cliki on something which shouldn't interfere with my workflow. (Don't
feel too bad about this, though, because I have the same visceral
hatred of both the Sourceforge bug tracker and bugzilla-based systems
-- in all cases, they are /way/ too much work for the end-user to
submit bugs, and quite often they are also too much work for the
administrator).
So if you don't mind, I'll pass on vanilla cliki interactions for
things like this; on the other hand, if people want to collaborate on
something which talks to a cliki given e-mail input, then I'm willing
at least to share ideas and maybe even get down and dirty.
Cheers,
Christophe
More information about the mcclim-devel
mailing list