Am 11.09.2004 um 21:49 schrieb Diego Gomez Deck:

>> Marcus what does exactly means unstable stream :)
>
> I second this question!
>

We sat at camp smalltalk on saturday, with 150 changesets that needed 
to be put in the stream.
We were certain that we would need to try loading the stuff before 
making it available.

There has always been a mechanism for testing new updates. We just made 
that one available for
everyone to see. We think that this will be nice to have for any new 
procedure that we establish in 3.8a.

Unstable means that your image may break in various unpleasant ways if 
you choose to update from that.
For example, if you load updates from it right now, any flaps you might 
have will be lost. Also, bringing up
an etoy viewer results in a walkback. So this is sort of a buffer to be 
able to actually test the updates in the
  sequence that they will later be released.

The main intention is to create a "fast lane" to get fixes out at a 
higher rate than was possible lately.
Harvesters could now directly post to the unstable stream when 
approving a changeset. In a sense,
you could call it the "harvesting" stream.
  It's similar to the SqC internal update stream which reportedly worked 
very well.

> What is the procedure to follow with the new unstable update stream?

What about that one:

The harvesting process stays exactly as it was until now, except for 
the new ability for the
  harvesters to directly push an approved update into the unstable 
update stream.
The Master Harvester (Doug) still needs to move the updates over to the 
regular
stream when a few days have gone by without anyone noticing bad 
conflicts.

Until BFAV is extended to do this automatically, you as a harvester 
have to do this:

	- save the changeset, uncompress it if necessary
	- make sure the changeset does only have one dot in the name (remove 
the version number, xyz.1.cs becomes xyz.cs)
	- choose "broadcast as update" in the file list (not yet tested... ;-))
	- select the "unstable" server
	- enter the password
	- if all goes well, the changeset will have got a number and a file 
Unstableupdates.list.prior is in your image directory.

and then of course

	- check your stuff by updating a vanilla image.

That would be a first step. Another thing we discussed was that it 
might be nice to give certain trusted developers (e.g. the squeakland
developers) direkt access to the unstable stream without having to go 
through the reviewing process.