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
|