[V3dot10] Proving the auto-build system

[stephane ducasse]

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

yes because we got a lot of problems due to the fact that one method  
should be changed before another one.
if all the packages would be installed atomically then these problems  
vanish (I feel stupid not to have the time
to look at MC2 and just talk....) Should do something but I'm again  
sick.

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

But sometimes you cannot loading one package at the time is the  
problem. MC supports the loading
of multiple package as if it would be one big package and this is  
excellent because you do not have
to resolve dependencies between package and this is really important  
in squeak. This is why
we used the script loader and not MCConfig (also because we could not  
get how to use it).

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

I see.

> 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.)

You lost me there.

>>
>> 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)
>

Stef
> 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
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
>