Paolo Amoroso <amoroso@mclink.it> writes:

Christophe Rhodes <csr21@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@common-lisp.net, say, with a few commands in the new body: open open-window-stream-windows-not-closed-by-parent submitter csr21@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

To: mcclim-devel@common-lisp.net Date: Sat, 19 Feb 2005 15:16:36 +0100 From: Paolo Amoroso

Christophe Rhodes <csr21@cam.ac.uk> writes:

...

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

Any comments from the McCLIM developers? What should be done with the bug list page at McCLIM CLiki? Shall we drop it?

How about a CLIM based front end that sumbits a properly formatted bug report to an Email address? Might make an interesting first app for someone wanting to learn CLIM but who also wants to contribute something useful. Mike McDonald mikemac@mikemac.com

Paolo Amoroso <amoroso@mclink.it> writes:

Any comments from the McCLIM developers? What should be done with the bug list page at McCLIM CLiki? Shall we drop it?

While we have it, we should probably keep it up to date -- unless someone is actively tagging and tracking bug reports sent to this list. However, I'd urge people interested in these infrastructural issues to think about a better system as a matter of relative urgency. (It would be nice to have a system in place for the next release.) Cheers, Christophe