[squeak-dev] Forking

Keith Hodges keith_hodges at yahoo.co.uk
Mon Dec 8 21:48:37 UTC 2008


> I'd like to empasize this:
> - Pharo has the clearly established nearly-achievable goals (good or
> bad - depends on people's preferences)
> - does Squeak has the same clearly established nearly-achievable goals?
>
> If yes, then why they not on squeak.org, but on
> (http://installer.pbwiki.com/311) 
Hi Igor,

We had a meeting with everyone that was interested perhaps 9 months ago.

Having re-iterated the goal, of more modularity, and better tools. It
was agreed that the tools on their way at the time, particularly "MC2"
(and now Sake) were likely to change the workflow to the extent that we
were not in a position to establish any further goals beyond the "more
modularity" and "better tools".
 
The rationale for this being that what is achievable with the old tools
and the means to get there was likely to be entirely different with the
new tools.

With this task based approach, you can make your own personal ideas for
goals into tasks, and get started. When you are ready we simply include
your task in the build. If the "release-team" dont like your task, or it
is not ready for the mainstream, it may still be distributed with the
release, for people to see what you were up to, and to contribute
further to it. (roll on namespaces!?!)

The goals of 3.11 are mainly philosophical and social.

Technical goals currently on their way for 3.11 include:

* LevelPlayingField as standard (Monticello itself unload/loadable
without losing essential state)

* Atomic Loading

* Traits as standard (but removable via unload task)

* Nail the package dependencies issue provide a mechanism to get all
things working for everyone.

* Release a reasonably functional basic image (rather than a kernel
image) but provide working unload tasks for non-essentials

* Remove a few more modules (but definitely ensure they are re-loadable)

* Removable tests (but definitely re-loadable)

* Ship with the very latest packages (3.10 shipped with out-of-date
Installer/SqueakMap etc)

* Facilitate integration testing, the other side of the coin to image
whittling and modularisation. i.e. be able to build and test a very full
image.

* Bob the Builder for testing and image building, and one-click-image
building

* Tidy up class organization

* Auto finalize the image, e.g. Readme, Release notes etc. version
controlled (in mc)

+ "Fixes" as per usual (but automatically documented in verbose detail)
we have about 90 so far.

Items marked with a + are specific to 3.11, items marked with a * are
tasks which may potentially be applied to any 3.7+ image if you have
been left behind or have been forced to fork.

Keith














More information about the Squeak-dev mailing list