[V3dot10] Prototyping an autobuild system

Keith Hodges keith_hodges at yahoo.co.uk
Tue Jan 23 13:39:11 UTC 2007

>> 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.
> it seems that we do not need to apply fixes 
> and test them against multiple images, if the above process fails 
> for "current image base"
Current image base is the Image with minimal packages loaded, and tests 
should pass, in order for the fix to be accepted.

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.

If we feel generous we can create change sets for all of those packages 
too., and saving them to their respective repositories may not be our 
responsibility, but we can have our own local repository for the purpose 
in order to publish the changes back to the maintainers.
>  but succeeds against "current image bloated" we have 
> a dependency problem rather then a problem with the fix... Sorry this is 
> probably unrelated to what you ment...
> The no-gui situation seems valid, there seems a need for tests to function 
> without GUI, can we redirect/copy test results into a log file, or even 
I would like to put in place a coherent Logging facility, a number exist 
to choose from.
> 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.



All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 

More information about the V3dot10 mailing list