[V3dot10] Release team problems

[Pavel Krivanek]

Hi Keith,

It may be good idea to have both approaches - maybe in two different
test servers - one for release building and the second for harvesting
of patches from Mantis that are mainly in the form of changesets. Or
one complex  sophisticated build&test system.

To enable processing of arguments by the KernelImage we have to solve
this issue http://bugs.impara.de/view.php?id=4849.

Few months ago I created this very simple test system:
http://weeklysqueak.wordpress.com/2006/10/07/a-simple-squeak-testing-server/
Its advantage is that it doesn't need direct support for test server
in the image.

-- Pavel

On 2/19/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> 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
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
>