update stream policy

Avi Bryant avi at beta4.com
Sat Jan 17 18:55:30 UTC 2004


On Jan 17, 2004, at 10:23 AM, Markus Gaelli wrote:

> Hello Frank,
>
>> I feel that everything, including tests, that *can* be factored out of
>> the upgrade stream bottlenecked base/kernel image and put on SqueakMap
>> *should* be so factored out.  I gather the tests are *already* 
>> factored
>> out, so it sounds like madness to me to undo that by putting them back
>> into the base/kernel image.
>
> This "madness" could help us to create a more living system:
>
> "One key idea is to keep the system running while testing and
> especially while making changes." (Alan Kay)
>
> How could this be done without having tests by default in the image?

Ok, this discussion seems to be going in circles, but:

It's not about whether the tests are in the image "by default".  It's a 
matter of *how* the tests get added to the image, and how they get 
maintained.

Traditionally, when we add a new bunch of code to the image, we do so 
by bundling it up into a big changeset and dumping that into the update 
stream.  When there are changes to the code later, they get posted as 
an ENH or a FIX, go through the approval process, and finally end up in 
the update stream as well.  This process has a number of problems:

- it makes building a minimal image harder
- it increases licensing complexity (anything put into the update 
stream in this way is almost certainly "infected" by the Squeak-L)
- it puts added load on the BFAV approval process, and on Doug or 
whoever maintains the update stream

The alternative way *of getting code into the image* is to put it as a 
package on SM, preferably in an "updatable" package format like .mcz, 
and issue a simple, small item into the update stream that loads it 
from the map.  Any changes to the code get made to the external 
package, and SM gets updated with the new version.  Anyone who wants 
these changes can grab them from SM as soon as they want; eventually, a 
new small item can be added to the update stream that loads the new 
package version into everyone's image.

My understanding was that we were going to move away from the first way 
of doing things and towards the second, with the goal that eventually 
most of the code in the image would be maintained as external packages 
(*even if it was also included in whichever default image people 
download*), rather than with the update stream.

To be perfectly clear, I would propose that we institute the following 
policy for the update stream.  The only acceptable kinds of updates 
are:

- those that make fixes to code already in the image
- those that remove code from the image
- those that load or update packages from SM

Markus, Stef, do you have objections to that?  Guides, am I correct in 
thinking that this was the intent, moving forward?

Avi




More information about the Squeak-dev mailing list