[mcclim-devel] Statement of intent: release McCLIM on Mothering Sunday (2005-03-06)

Timothy Moore moore at bricoworks.com
Tue Feb 15 09:41:10 UTC 2005


On Feb 14, 2005, at 9:37 PM, Andreas Fuchs wrote:

> Hi all,
>
> I'd like to use my new-found McCLIM committer powers to push a new
> release of McCLIM out the door.
>
> This is the schedule that Xophe came up with on #lisp a few days ago
> (augmented with real dates):
>
>  * Freeze McCLIM proper on 2005-02-21
>  * Freeze Apps/ and Examples/ on 2005-02-28
>  * Release on 2005-03-06
>
Yes, this is a great idea. Of course there's some major features I'd 
like to get in before a release :), but that's the whole point of the 
time-boxed release schedule proposed here.
Here are my priorities for an imminent release. Only two of these are 
personal tasks of mine, hint hint  :

Make sure McCLIM works well, out of the box, with climacs. I don't 
think that will be too hard -- we should be there -- but climacs is 
clearly the major client of McCLIM now; climacs users should be able to 
install and use McCLIM without problems.

Fix bugs that  have turned up in accepting-values and updating-output. 
I hope to have this fixed up today or tomorrow.

Look at Paolo's bug list and see if there's any low-hanging fruit. One 
bug that is not low-hanging but that is extremely embarrassing is 
numbers-pane-layout-specifiers. Every new user tries an example that 
specifies the relative sizes of panes using ratios and then wonders why 
it doesn't work. I've looked at this problem before, wandered deep into 
the frame layout code, got lost and abandoned, but I would really like 
to have this bug fixed before a release.

Someone should look at the Beagle backend, make sure that it can build 
and pop something up. Documenting what's missing would be good too.

It would be *fabulous* if the Freetype support was useable in CMUCL and 
SBCL (and OpenMCL too, for I understand that its alien stuff is not too 
different from the others) with a minimum of user intervention. Does 
anyone want to take that on?

For Apps and Examples:
  there may be examples that are so old that they should be banished, 
even if they do work.

Some integration of the Inspector and the Listener would be nice.

For the release:
Some work on the documentation would be nice. I'm planning to write a 
chapter on "Writing a CLIM application" that would be good to include. 
A comprehensive list of what's missing or broken would be very useful; 
I think we can do this with respect to the Franz User's Guide as that 
would be more helpful the spec for existing CLIM users. Going 
function-by-function through the guide and listing differences in the 
McCLIM manual would be very useful, but is probably too much work 
before this release. That would be a great project if someone wants to 
take it on.

asdf-install enabled! I'd be comfortable dumping support for 
mk:defsystem -- or any defsystem -- if that would help get things into 
shape for asdf.


> If that isn't messing with anybody's plans, I'd like to stick to that
> schedule and upload a nice official tarball in the end. (-:
>
> If this release goes well, we could try a bi-monthly release schedule
> based on that - hack a 6 weeks, freeze two (or just one) weeks,
> release. Evidence from the mcclim-cvs list archive of the last few
> months suggests that this could provide usable snapshots of a steadily
> progressing McCLIM.
>
Yes yes yes :)

Tim




More information about the mcclim-devel mailing list