[V3dot10] Release team problems

[Keith Hodges]

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
Sounds great.

> 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 
experimentation-testing.

Keith
 

		
___________________________________________________________ 
All New Yahoo! Mail – Tired of Vi at gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html