"Internal" updates (was: RE: [Squeakfoundation]Possible extra text

goran.hultgren@bluefish.se squeakfoundation@lists.squeakfoundation.org
Mon, 13 Jan 2003 09:20:15 +0100

Daniel Vainsencher <danielv@netvision.net.il> wrote:
> I think we should definitely convert, for the 3.5 cycle, to one update
> stream. We already have mechanisms to protect the wary - stop updating
> when you get to a "Continue updating for 3.5a" question. We could
> improve one these as mentioned, either using a special marker, or a
> whole new SM-like update mechanism, but we certainly don't have to wait
> for either of those.

Agree - we shouldn't wait - a new tool takes time to develop.

> I think SM based update streams would be great for the packages
> themselves, and possibly maintainance of the Image release could benefit
> from this mechanism, but I propose we don't tangle these until such a
> mechanism is pretty well proven. IOW, I propose we 
> * finish up 3.4 as we have so far, 
> * for 3.5 simply convert to a single update stream, so people can decide
> their own exposure, 
> * and consider alternatives only for the version after 3.5.

Sounds like a plan to me. And then perhaps we can finally get ALPHA to
really mean "stuff falling on your head" as it is intended to.
Seriously. The Squeak community has often IMHO been far to careful when
it comes to letting bugfixes into the stream (enhancements/additions is
another story) - as long as we are in alpha I think we should let stuff
in without much resistance (one experienced Squeaker approving it based
on looking at it (no real testing necessary) should be enough) and then
perhaps run a quick "batch review" of all the changesets in the alpha
again when we intend to go into beta.

Anyway - in short, lets get rid of the internal stream for 3.5 and tell
the community in BLOCK LETTERS that alpha now really means ALPHA.

I also think that the harvesting for 3.5alpha could be sped up
significantly if lower the bar for bugfixes as I explained above - a
single harvester (=experienced Squeaker) can approve a FIX by simply
looking it over. This is just to prevent really "stupid" fixes or
obviously inexperienced code sneaking in.

And then if this will let in a few fixes that we need to improve or back
out then so be it - no harm done. At least we will have a reasonable
chance of keeping up with the onslaught. :-)

regards, Göran

PS. Doing Dolphin right now for a customer - really interesting stuff
too, advanced optimization - roughly the CSP (cutting stock) problem.
Great fun!