Keith Hodges wrote:
> Andreas' proposal is to throw every package within the kernel and the
> image as a whole out to be treated as an "external package" to be hacked
> on by any approved person who fancies a go.

Really, the fundamental idea of the proposal to have a shared repository 
where I can collaborate with other Squeak developers on core packages.

> The result can be viewed and used by anyone by publishing to MC and
> subscribing via an updates mechanism.

Correct.

> The image will probably be a bit unstable for a bit, but we cant go to
> the extent of breaking it ever, because we are not distibuting a new
> image, just updates, everything must continue to work seamlessly.

Not necessarily. If there is a need to distribute a new image, we can 
certainly do that. I'm just not in favor of requiring a new image any 
time you want to do anything. Keep in mind that in previous messages 
I've pointed out Bob's role in building images based on the trunk 
packages. That's useful because people can fetch the latest version for 
playing with it which is right in line with the idea of reducing hurdles 
since the need to go through a lengthy update process can be just as 
bothersome as the need to download a new image every week.

In short: Updates and images go hand in hand. Yes, there will be images, 
and I would like Bob to play a role in building these automatically (say 
on a weekly basis).

> Everything has to be done in small evolutionary steps as required by an
> updates mechanism. There is no mechanism for removing things from the
> image, or for changing the image structure. You will have to clear out
> stale package references, repository references from your image
> yourself.

All of this can be done automatically. Removals and doIts can be 
deployed (for example) via package preambles/postscripts and since the 
MCM update mechanism can be instructed to load precisely those version 
with the scripts attached to it you can utilize the process in a similar 
manner as preambles/postscripts in change sets.

> Then it is supposedly up to Bob to take these packages as an **input**
> putting the image into an unpredictable state.

Actually, you start with some base image (like the previous release) 
which I think we can agree on as being called stable. Then you run the 
package updater process just like any client would. Not much difference 
to a SakeTask (which could be produced from the MCM automatically) and 
it leaves the image in a no more unpredicable state than loading any 
other code would.

> Then Bob is expected to apply some fixes from mantis which were perhaps
> submited a year ago and were definitely not targeted at the image in
> which bob has to get them to work. Bob then uploads the resulting
> packages up to the trunk repo,
> Bob is now an automated contributor to the single trunk repository.

That's the point where I would hope that Bob can help us to drastically 
reduce the turnaround times. A fix produced a year ago should not stall 
for a year in Mantis. If Bob identifies the fix within a week or two, if 
Bob can prove that the fix doesn't break an existing test and does allow 
the provided tests to run then there should be little need to wait for a 
year. The point being that Bob's stamp of approval can help us screen 
tests that "look ready" much, much faster.

> Bob also helps out by running tests in the hope that at some point in 2
> years time, we get to a point where all the enthusiastic contributors to
> trunk have calmed down and have arrived at a reasonably stable working
> image. At which point a release will be asssembled manually by someone,
> probably Andreas, who will manually update the versions number, and
> manually ftp the new image up to ftp.squeak.org or publish an mcm for
> people to use.

Something along those lines, yes. I think that having an ongoing release 
team would be useful, for example to work out which demos should be 
included, how the contents is presented, which extra parts (fonts, 
media, etc) to include and so on.

Cheers,
   - Andreas