Thanks for the update on the update stream ;)

We are currently working with alex on a new namespace class and we 
should think how the
KCP pending items should be treated.

Stef

On 12 sept. 04, at 21:18, Marcus Denker wrote:

>
> 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.
>
>
>