[V3dot10] Prototyping an autobuild system

[Milan Zimmermann]

On 2007 January 23 08:39, Keith Hodges wrote:
> >> When a bug fix in the base of 3.9, effects, 3.9-stable 3.9-unstable
> >> 3.9-dev, 3.9 full and 3.9-bloated, then it is nice to have someone else
> >> do all the work for you.
> >
> > Let me ask a question only marginally relevant to the multiple images you
> > mentioned. I assume the release process has to have a defined workflow of
> > how to validate fixes. It seeems to me a fix would not be tested after it
> > is applied, but after a Package or several Packages (Monticello packages)
> > affected by the fix are reloaded. My thinking of the workflow
>
> Yes indeed
>
> > 	1) Take "current" image
> > 	2) Load into "current" the Packages that are potentially affected by the
> > fix + any dependent Packages
> > 	3) Apply fix to the image
> >
> > 	4) Export the fixed (affected) Package(s)
> > 	5 Take "current" image again (as in Step 1)
> >
> > 	6) Load into "current" the packages that were affected by the fix (they
> > include the fix now) + any dependent Packages  (as in Step 2, except
> > Packages now contain the fix)
> > 	7)  test the image.
> > It this wrong? If it is correct,
>
> I think that that pretty much sums it up. I am not sure that you need to
> do 4,5, and 6 in order to test the fix, only to ensure that we can get
> to the same point by loading fixed packages rather than loading fixes.

Thanks for commenting. I agree that 4,5,6 do not need to be done when testing 
the fix (for example by harvester in his test image") - they happen at the 
point when fixed packages are used to build the image again and test.

> Then as you say if the tests pass on the base image we can progress to a
> verification and information gathering excercise.  Loading every package
> that will load (i.e. image -bloated) and running those packages' tests
> we discover if our fix has broken any of those packages.

yes that makes sense. Building and testing the "bloated" is still needed, for 
example to verify some refactoring in the "base", or fix applied on a package 
in "base" did not affect something in one of the packages outside of base.

>
> I would like to put in place a coherent Logging facility, a number exist
> to choose from.

yes

>
> > better, have a "TestResult" class in the image, that can be inspected
> > without GUI present?
> >
> > Milan
>
> I hadn't thought of that option for a non-GUI situation but it might be
> useful I dont know.

I am mostly thinking having TestResult or LogCaptureClass in the image would 
be interesting from the perspective of not needing to deal with files at all 
during the auto-testing process. The tests would run in the image, results 
and logs would be captured inside the image, and at the end, instead of 
another process reading log files, there could be some other image that 
attached to the tested image, and ask it to pass the TestResult and 
LogCaptureClass objects. While it feels (perhaps) elegant, it probably goes 
too far and feasability of such approach is questionable, so I will stop :)

MIlan
>
> cheers
>
> 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