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

[Robert Strandh]

Christophe Rhodes writes:
 > 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"?  

It would be hard to come up with such a person, I think.  

 > Perhaps more to the point, who "owns" the development process?

That's a more reasonable question to ask.  I think it would have to be
a very active current developer, but I don't see one like that at the
moment.  Probably Tim Moore would be the one that comes closest. 

 > 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...

True, and I do think McCLIM needs such an owner (I have called that
person a Newman-type person for McCLIM).  I am afraid there are no
candidates at the moment.  And Tim now has a real job, so we can
expect even less work on McCLIM from him. 

 > 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.

There are indeed many such problems that need to be addressed.  While
technically speaking I have the time over the next year to take on
this ownership, I do not think I will, because I have at least two
more large-ish programming projects to take care of.  Though I guess
if Dave Murray takes care of Climacs, and someone else of Gsharp, I
could work on McCLIM :-)

Also, like I have said many times, McCLIM needs a near-total overhaul
in terms of code maintainability and compliance with the standard.  So
if I were to take ownership, I would not start by fixing immediate
problems, but by improving the code in order to make such fixes
easier.  We are talking at least a few months of work I would think.

 > 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.

Sure.

 > I suppose this boils down to two questions.  Firstly, how do we best
 > manage the development resources that we currently have?

I think this will be hard unless there is at least one person willing
to invest time in understanding the spec and the code.  Only someone
with a relatively global view of both would be able to determine
whether a suggested patch for a problem will break something else.
Now, with a bit of luck, that person would not have to actually do
that much coding, but could rely on others to actually suggest
patches.

 > 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...

Automatic regression testing would be very nice, but it is a huge task
in itself.  It requires, it seems to me, having understood the spec,
which we know is both ambiguous, self contradictory, and incomplete.  

 > 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 -- 

A score editor certainly has some limited audience, but it could be a
killer app to its particular audience.  For that, it needs to work
properly, which is why I was planning to work on it a bit more this
year. 

A text editor could be a killer app when it acquires functionality
comparable to SLIME, and even better in some areas.  Implementing most
of SLIME in Climacs probably requires a lot of work, but I am guessing
that the existence of features unique to Climacs would attract more
developers willing to put into it what is currently in SLIME.  Though,
that will not help McCLIM very much. 

 > 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...)

There are two different meanings here to "killer app".  The first
meaning is an application that is interesting to the general public
and that provides functionality that existing applications do not
have.  Gsharp could become such an application, but it would attract
very few, if any, developers. 

The second meaning is an application that is uniquely hackable because
it is written in CL and would therefore attract CL developers who
would be willing to put up with fewer features than what some similar
existing application have, in return for easily being able to add
their own features.  Closure and Climacs are such applications.

I think the second type of applications would be more suited to
attract new developers for McCLIM. 

And to answer your question, no I am not personally working on
anything else, exciting or not. 

 > 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...

Definitely. 

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

I really do think that someone would have to sacrifice the better part
of a few months to fully read and understand the spec and the code.
It would be easier for someone who has already read and understood the
spec, of course.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------