On Thu, 8 May 2003, Daniel Vainsencher wrote:

> We're talking about storing all ENH/FIXes posted to the list on it, not
> just KCP/MCP stuff. Actually, the way they work is less of a hassle to
> review their stuff.
<snip>
> As I see it - the server creates a package for every unique message
> subject (same rules as bug fixes archive uses). For every message with
> the same name, create a version containing the code (might need to limit
> to one changeset per message. Pretty raw. Ideas?), and associate with it
> also the message subject, text so forth.

If you really want to know how I would do it - I think we need to move
away from the idea of changesets and update streams, and start dealing
with packages as coherent units.  I would like to try doing something
along these lines:

- start a CVS repository on squeakfoundation.org
- put a Monticello package file into it for every toplevel system
category: Kernel.mc, Collections.mc, Morphic.mc, and so on
- projects like the KCP and MCP would have direct commit access to
the repository, as would the guides.  Other ENH or FIXes would have to go
onto branches (not sure exactly how we work this).
- emails to the list would be generated automatically from the CVS logs;
if we got fancy these could even include an auto-generated .cs, as well as
the usual textual diff
- guides can merge any of the branches with ENH or FIX into the main trunk
- anyone can update their local working copy to this main trunk (or any
other version) and use Monticello to either look at the changes, or update
their image to match

Then we actually have a rational set of complete versions of the system,
that can be browsed, updated, and rolled back with the usual CVS tools,
rather than a bunch of changes that need to be applied in the correct
order, to the correct initial state.

Of course, this means everyone has to learn how to use CVS.  I don't think
this is that big a deal for a temporary measure, much as we might hate to
introduce a non-Squeak tool into the process.

In the not-so-long-run, we need to replace CVS with a pure-Squeak
equivalent.  A lot of the framework for that is already there, it just
needs a UI.  *However* I think the first change that needs to be
made is a cultural one: basically, we need to get used to representing
complete versions of "Squeak" (at least as defined by its source code)
*outside* of an active image.  CVS is a good way of bootstrapping this
approach.

I realize that there are places where this simply will not work - when
changes absolutely need to be applied in a certain order, or there are
postscripts or preambles that must be run (and don't make sense in a class
side #initialize method).  This is why I haven't proposed doing this
earlier - but it may be that, as you essentially propose, just stuffing
such scripts into commit logs will be a good 80% solution for now.

My $0.02.

Avi