[V3dot10] two levels of external packages

[Lex Spoon]

The release team has indicated that a priority for 3.10 is to separate
the image into multiple packages.  I am writing to suggest that the
external packages actually be grouped into two priority levels.

The highest priority level is the "core" or "standard" packages that
Ralph described in this message from January:

http://lists.squeakfoundation.org/pipermail/v3dot10/2007-January/000099.html

I'll say "core" because I don't know if a name was ever selected for
these packages.  The "core" packages are things that are watched
directly by the release team and are maintained most dilligently. 
Examples would likely be Morphic, URL's, key network protocols, and
VMmaker.  The precise list would, itself, be a matter of management by
the release team, and packages could certainly migrate from one
designation to the other as the years go by.

A second level is also important, but should be managed differently. 
Call it "contributions".  Contributions packages are contributed and
maintained by members of the Squeak community who are not directly
working on the release.  There are about 100 packages in the 3.9 stable
universe, and most of them would count as "contributions" packages.

Management is different for the packages in these two groups.  A patch
to the kernel image should probably *never* cause a test to fail in a
core external package.  A patch *may* cause a contribution package to
break, but the release team would want to be aware of it when it happens
and try to minimize it happening.

As a release nears its end, the set of contributions packages will get
frozen and undergo final cleanups, so that there can ideally be a
simultaneous release of three things: a new core image, a set of core
packages, and a set of contributions packages.  To achieve this, it is
acceptible to eject contributions packages, but not core packages, that
cause problems for other packages.


This is just a thought.  The first step to effectively managing
packages, is to sort out what exactly we are managing.  Does this
two-level designation of packages sound good to the folks on the release
team?  If so, how about we use the "squeak3.10" package universe to
manage the core external packages, and the "development" universe to
manage contributions ?


Lex Spoon