On 01.03.2006, at 21:51, Simon Michael wrote:

> Me too - thank you Marcus, Jerome, Bert and all others.
>
> Marcus, would it be possible to have a breakdown of that log you  
> just posted, suitable for folks who've been away from things ? I  
> think:
>
> -  the 700x numbers are release numbers, corresponding to release  
> announcements, uploaded images etc. Two "unstable releases" were  
> announced here.

In 3.9a we are trying to use Monticello for managing the image...

The update numbers (700x) are the number of changesets put in the  
update stream. The changeset loads one package ("ScriptLoader") that  
then has a build-script,
mainly loading a set of Monticello packages from the squeaksource  
server, sometimes the scriptloader script  has a postscript when  
needed (e.g. deleting preferences).

>
> - ------ separates logical changes or change sets, though probably  
> not actual changesets just at the moment ? No, it looks like the  
> second one was a changeset. One of these logical changes  
> (updates ?) might include fixes for many mantis issues (the 000xxxx  
> numbers).

the text was done by hand and follows no logic ;-) the numbers are  
manits bug numbers, yes. I don't post the full description there, but  
when a
changeset was done with a nice preamble, I choose mostly to post that  
instead of the mantis number.

The best name for the release-numbers would be "build" I'd say: I  
load changesets (or fix stuff directly when seeing a simple to fix bug).
Then I commit regularly to the source.squeakfoundation.org  
repository. When changes have piled up to be big enough for making
it worth the effort, I make a build script, put in on the  
updatestream and upload an image.

As I said, the setup is far from perfect.... and we really need to  
improve it. e.g. updating is far too slow, and updating over multiple  
builds is broken...

I like MC as a versioning system (it should be speed up at bit...).  
But for providing what we had with the update stream it's not
as good... what I would like would be a mix of the two: MC builds  
changesets that it then loads. There is a feature in SqueakSource
that allows this to be done on the server an then cached (Bert  
implemented that). But this brakes down as soon as you change
the code in the image via a normal changeset or a postscript: The  
diff the server builds between version is not the diff between
the real images, as the postscript is ignored. But it should be  
possible to build a changeset when building the release image....
somehow, with taking the postscripts into account. This could then  
even set all MC data (e.g. version number) correctly, beeing a true  
diff.

This then should be available for people through the update stream,  
allowing for fast update without the need of having MC load
ad decompress and diff everything on all clients... anyone would like  
to try implementing that?

And besides that, we need to automate much much more... I would like  
to have a system where I can commit to SqueakSource,
and every night a build is done *completely* automatic, with image  
generation+upload, mail to list with changelog, generation
of a changeset for the updatestream, everything.

> - changes sometimes have no author information. That means they've  
> come from.. where ?

Either I have forgotten the author information (which would be bad,  
sorry to everyone who had that happen).
Or the change is from me (e.g. I refactored some code now that  
CompiledMethods know their Selector and Class,
or some small stuff, or stuff for the NewCompiler overrides/ 
ClosureRuntime merge).

        Marcus