[V3dot10] Release team problems

Sun Feb 18 15:55:31 UTC 2007

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

On 2/18/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> Although Ralph has been silent, I do not think that we need to worry
> just yet, there are plenty of constructive things to do in the meantime.
> If you happen to get bored I have put some things to do that are looking
> for someone to do them in square brackets below.
>
> Furthermore I do not agree with the statement that the team is taking a
> while to get going.  From my perspective plenty of work has been done
> although it is not directly on 3.10 it is proposed as a major component
> of the process for any future releases and I am nearing completion of
> the first major phase. I will be looking to encourage people to start
> using this stuff beginning this coming week. The automatic testing part
> of the auto-build system is now functioning as of today! Watch this space.
>
> An example of the raw testing output is available here at
> http://squeak.warwick.st/tmptests
>
> In order to provide a framework that others can understand and consider
> where they might join in, I thought that I would take a moment to
> outline the process that I am aiming for with the auto build system.
>
> This process is being developed and I aim to demonstrate it with the
> simpler goal of producing a 3.9 version with some fixes harvested, i.e.
> 3.9.1
>
> So, step 1:
> Collect fixes and updated packages for 3.9.1 on the squeak310.pbwiki.com
> web site. Anyone who wants to contibute can start to do so now
> [harvesting fixes], there is lots of work to do there! Fixes can be
> added to either the stable branch or to the unstable branch, harvesters
> can even have their own private branch if they want to test more radical
> ideas out.
>
> The auto-build system automatically builds AND tests the new 3.9.1
> image. Thus one feedback loop is completed.
>
> Testing is divided into two testing phases, quick and slow, in order to
> speed the initial feedback loop. The full test suite does take quite a
> long time to run. [some categorising work to be done to make this fly]
>
> The auto-build system also automatically builds and tests images derived
> from 3.9, such as Seaside-Magma-Pier and possibly the Dev image, the
> proposed full/fun images [script for the full/fun images], and a load
> everything that is in the 3.9 Universes image [script for bloated
> image]. People can contribute their own image building scripts to this
> part of the process too. [tools for version control of the readme files
> and making the final presentation of these images look good.] [tools for
> automatically collating change logs and release notes (some have been
> done such as MCWorkingCopy report=workingCopies)]
>
> All of the generated images can be automatically tested also, thus a
> second feedback loop is completed.
>
> So within step 1, we have a complete mechanism for harvesting fixes, and
> for writing and trying out more tests.
>
> Then comes phase 2. Phase 2 is probably the difficult bit. It can be
> done by hand, but the main effort in Phase 2 is to improve the tools for
> taking an image with a load of fixes and outputting the packages to
> Monticello in such a manner as to make those packages reloadable. Some
> of these tools have been discussed before. Atomic loading is a must
> have. I also think that it may be possible to remove the need for
> packages to be loaded in a specific order, Stef and I have been
> discussing the possibilities, I do not know whether it is possible.
>
> Phase 3, is where Phases 1 and 2 meet with the real 3.10 (Edgar's) work
> and the KernelImage work approaching from the other direction.  This is
> the process of moving from a 3.9 or 3.9.1 image to a minimal image, and
> back again by loading packages.
>
> I have to rush to work now, but I thought I would put this on the table
> before everyone gets to upset about what is or is not happening.
>
> best regards
>
> Keith
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___________________________________________________________
> All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
> http://uk.docs.yahoo.com/nowyoucan.html
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
>