update stream policy
Diego Gomez Deck
DiegoGomezDeck at ConsultAr.com
Sat Jan 17 19:23:58 UTC 2004
> > 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:
Yes... All of us enjoy the discussion more than the action. Just
compare the emails in license thread versus the emails with [ENH] or
[FIX] subject this month.
> 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
> 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
Sure. And the opposite is also true.
It's really difficult to create a big image from the parts. Example:
Scamper and Celeste are not translatable in 3.7 but in Small-Land image
> - it increases licensing complexity (anything put into the update
> stream in this way is almost certainly "infected" by the Squeak-L)
You said: everything is "infected" by Squeak-L. I don't see complexity.
> - it puts added load on the BFAV approval process, and on Doug or
> whoever maintains the update stream
Probably the problem is the methodology.
We created a procedure to work with tens/hundreds of developers, but in
fact only a few of us are working on the "bureaucratic" part of the
process and every public enlarge the hard-workers team failed.
I'm not being extreme saying that the process is alive thanks to Marcus
Denker, Stephane Duccase and Doug Way. Only 3 of us.
> 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.
The problem is not in the installing process but in the testing!
To build an image from the parts, in the current state of Squeak (with
not good isolation features), is really complex.
> 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
> - 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?
I propose to evaluate FIRST which resources we have before going with a
list of goals/wishes.
How many of us are active working? How many time we're spending on this
Diego Gomez Deck
More information about the Squeak-dev