[V3dot10] Release team problems

[Keith Hodges]

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