[mcclim-devel] One char patch to presentation-defs

Christophe Rhodes csr21 at cam.ac.uk
Tue Aug 9 09:54:33 UTC 2005


Timothy Moore <moore at bricoworks.com> writes:

> On Aug 8, 2005, at 1:11 PM, Christophe Rhodes wrote:
>> Thanks, I've applied this patch.  (Whether it should take two weeks to
>> apply a one-line patch, I don't know; you be the judge...)
>>
> No, it shouldn't. In my lame defense, I'm traveling and not paying much 
> attention :)  Thanks, Christophe.

I was going to start this message by saying "I wasn't trying to
apportion blame", but then I realised that that would be a slightly
disingenuous response.  I was not and am not trying to apportion
blame, but it was a pointed message nonetheless, and for the
pointiness I apologise.

It does raise at least one question, though: who "owns" the McCLIM
code, where by "owns" I actually mean "feels that he has ownership
of"?  Perhaps more to the point, who "owns" the development process?
It's obviously harder to provide timely responses at present, when
no-one can devote even a substantial portion of their time to McCLIM
development, than it has been in the past, when students both feckless
and directed have had as part of their tasks to work on it: now many
of those students are Real People, with jobs and so on to sap their
time and energy...

Now, we at work are using McCLIM as a substrate for our research and
library work, but we seem to be diverging (not too rapidly yet,
thankfully) in our local tree despite my having write access, simply
because I cannot afford the time to take "ownership" (responsibility,
if you will) of the various problems we encounter and work around --
such as the incremental-redisplay performance issues I've mentioned
before, the status of arbitrary output-recording streams as candidates
for updating-output, and suchlike -- we think we have another problem
with freetype fonts (but the report for that might well be stuck in
the mailing list moderation queue...), and so on, and so on.

I hope I'm not coming on too strong -- I certainly don't expect the
world to arrange itself for my convenience, so that I can have what I
want, right now -- but I think that we as a time-poor developer
community need to think how best to manage going forward with McCLIM,
now that a sufficient base of functionality has been built.

We don't have the luxury of commercial resources being thrown at us,
and I suspect that this isn't going to change in the near term.
Sadly, nor do I see much in the way of research funding in this area;
these things are always possible -- I will try to sneak in requests
for some time to work on the stack of lisp code that we use in future
grant applications, for instance -- but the timescale and the odds are
unfavourable.  We even managed to avoid the shower of money (which, as
Einstein proved, is equivalent to time) thrown at the Lisp community
by Google -- the project I proposed to integrate R-trees into
output-recording was not funded...

I suppose this boils down to two questions.  Firstly, how do we best
manage the development resources that we currently have?  Some of this
is a social problem, but the good news is that it's mostly technical:
experience tells me that we're much better at solving technical
problems than social ones.  My own feelings on CLiki-as-bugtracker are
known, I think, but Paolo is a perfectly acceptable User Interface
from my point of view, so while he remains willing to serve like that,
it's fine.  What we lack is any kind of automatic regression testing
to give confidence that bugs remain fixed; lacking a wide userbase as
we do, we can't depend on timely notification of regressions from
users.  I have some of a Null backend for McCLIM which could be used,
if completed, as a means of testing even the graphical output
protocols; somewhat inevitably, though, I don't have time to advance
on it at more than a snail's pace...

Secondly, how do we cause the available development resources to grow?
Absent sources of funding, this means finding people to work for
free... never a great prospect on its own.  Killer apps and a certain
amount of "evangelism" help; whether a text editor and a score editor
are sexy enough for that, I don't know -- is anyone else working on
anything exciting?  (People here may not know that the closure web
browser is at least partially revived: it is known to run in McCLIM
using the X backend and recent CMUCL or SBCL releases; on the other
hand, there's no way that a web browser is going to be a killer
application in today's world...)

I'm afraid I don't have any easy answers -- and I know that these
things take time.  On the other hand, it's possible that a little
thought now would reduce the time it takes for the situation with
regards to active development to improve...

If you've made it down to here, congratulations, and thank you for
reading :-).  Any thoughts?

Cheers,

Christophe



More information about the mcclim-devel mailing list