[V3dot10] Proving the auto-build system

[Keith Hodges]

stephane ducasse wrote:
> Keith
>
>
> the problem is the following
>
>     - can you publish new packages once you loaded your fixes
>     - can you reload your packages once you saved them
>
> Because you can have a vicious CS that is manually edited that loads 
> well.
> Then you save your package it work well.
> Then some weeks later you reload the packages because you merge something
> and the code does not reload because the package code does not inforce 
> the
> same load order....and boum you cannot have a reproduceable set of
> packages.
>
Yes I appreciate that this is the difficulty, and no I have done nothing 
to attempt to alleviate this difficulty up front.

I am under the impression that you think that with Atomic loading this 
problem may well be solved. Is this the case?

It looks like we may need a -testFromLoadingPackages branch in the build 
system too.

Apart from using Atomic loading I would expect to work on solving this 
problem one package at a time. For example, we discussed in the past 
having a Kernel version of Chronology, making the bulk of Chronology 
safely loadable non-atomically. The Kernel version of Chronology itself 
would absolutely depend on having atomic loading working (I have tried 
reloading chronology and it didn't work - just as you described) because 
the method time stamping code in change sets needs chronology to be 
initialised and working in order to load the code for the initialisation.

To this end I have aimed to add the methods #askFor: and 
#askFor:ifAbsent: in an attempt to enable some components to tweaked in 
order to be less tightly coupled. Even more controversially I would like 
to smuggle the message eating Null into the image. I thought that I 
might do this as part of a Logging component since Null makes a great  
implementation of the NullLogger case. There are a number of other 
Null-type classes that it may be able to replace. I have also tested 
Null as a great NullStartUp action for my new AutoStart implementation 
(for seaside hosting, starting up an image which presents with a dialog 
for "do you want updates, is a problem, it would be nice to have a 
reliable means to prevent this from happening" from outside, hence 
having  Null as a startup document would do this.)
>
> What is the output of your process? A set of new packages?
>
The primary outputs from this process are, new images, at several stages,

1. before testing, (or after testing short tests only)
2, after testing all tests
3. after all test code has been removed.

with various logs for, how this image was built, a zip file snapshot of 
the website with the current state of the website in it, and logs for 
test results.

Further requirements, such as a set of packages from which the image can 
be reliably rebuild loading from Monticello, are a secondary and 
desirable deliverable. These will rely on

a) innovation that help it to work, i.e. Atomic Loading, MC2
b) developed improvements to the components themselves and the way 
squeak is organised to enable it to happen. i.e. decoupling dependancies 
between components. (e.g. my work on AutoStart, and things such as 
Kernel-Chronology-Kernel)

cheers

Keith

		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html