[V3dot10] Proving the auto-build system
Keith Hodges
keith_hodges at yahoo.co.uk
Fri Jan 19 13:11:34 UTC 2007
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
More information about the V3dot10
mailing list