[V3dot10] Release team problems
keith_hodges at yahoo.co.uk
Mon Feb 19 12:01:53 UTC 2007
Pavel Krivanek wrote:
> Hi Keith,
> I would like to show you my point of view.
> The KernelImage is now in state than is different from the state where
> it was in time when Ralph planed the release process. Now we have
> kernel and EToys as Monticello packages. That means that now is very
> simple to have not only automatical build&test server but it may be
> fully supported by Monticello directly. So the process of image
> building and testing can be:
> - take basic kernel image with preloaded primitive packages
> - update kernel and pritimtive packages from MC repository - build image
> - load SUnit and test for the kernel - run it
> - load MinimalMorphic - build image - load tests for it - run it
> - load EToys - build image - load tests for it - run it
> - continue for next packages
> - publish images and reports
> EToys image has almost the same code base as normal Squeak 3.9 without
> Nebraska now.
> We don't need system for processing changesets, because this packages
> are independent and we may process everything using Monticello - the
> problems with atomic loading are less important here because we have
> well defined dependencies and order of packages.
> If we will be able to avoid overrides in MinimalMorphic and EToys
> package, we will have easy update stream too. Of course this big
> packages need next division.
> I don't see any reason why we should prefer the mix of pre-monticello
> and monticello-based release model.
> -- Pavel
Your scheme is similar to mine, except that your starting point is
understandably further back. You are starting with a kernel image,
loading some packages and running tests. You just have more of the
system available in package form.
I am starting with 3.9 (almost), loading some packages, and running
tests. Notice I still load packages where packages are available (i.e.
SUnit) but I am mainly using changesets for fixes because I do not have
access to any of the main repositories.
On a pragmatic level the changeset and scripting approach has its
advantages particularly for reorganising things and experimenting before
committing to the master repositories.
Some of these "experiments" such as enabling underscores in selectors,
may best be carried out with changesets, until certain of the
effectiveness of the solution. The more I think of ways to move squeak
forward, the more I see changes that would impact across many packages.
But as long as the end result can be released to MC thats what counts.
I think that the differences are simply in the process. You use the word
"release". I think that my process enables more pre-release
All New Yahoo! Mail Tired of Vi at gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
More information about the V3dot10