Dear All,
having discovered that we lack concensus... here goes with my idea.
I venture to suggest that every release team performs certain functions...
1. Harvesting Fixes 2. Removing Deprecated Stuff 3. Loading the latest and greatest packages 4. Producing some documentation for workspaces etc.
My plan is to take each potential activity as a sub-project, whose results generate either a script on installer.pbwiki.com or a Sake/Task.
So to generate a release candidate for testing we run the script end to end assembling all of the parts for example.
3.10 + MinorFixes + PackageUpgrades + Clean.
This produces a cantidate for 3.11, well at least the proposed content for 3.11, we then look at how to deliver it using the new tools we are developing.
Option 1. Run the script using using DS to record all of the changes made to the image, then generate a cs from that which can be placed upon the update stream.
Option 2. Save all packages from the prototype image to MC.
Generate 3.11 by taking 3.10 and loading in all the latest packages from MC. (requires atomic loading)
Having done this...
3.12 becomes 3.11 + MinorFixes + PackageUpgrades + Clean
and we go around again every 6 months or so.
Keith
Having done this...
3.12 becomes 3.11 + MinorFixes + PackageUpgrades + Clean
and we go around again every 6 months or so.
Keith
My understanding is that the main objective for 3.11 is to get to the point of testing the tool chain from end to end rather than worrying too much about actual innovations for the kernel. Aim to tidy and remove of packages that can be reloaded wherever possible.
The tool chain of course includes the build server which goes through the process pretty much automatically.
1. Generating the content candidate test image, 2. Generating the release candidate base image, 3. Loading packages and tests 4. Running tests. 5. and generating published images derived form the base image.
Step 1 Is working, via Installer + installer.pbwiki.com
Step 2 Is at the stage where we are not sure as to how exactly to go about it. We definitely need atomic loading for this though.
The following to be automated by Bob the Builder.
Step 3. Sake/Packages now makes this possible Step 4. Code has been written in latest SUnit, needs tidying, perhaps refactoring a bit. Step 5. Awaits Sake/Tasks and Rio handling of remote ftp sites.
best regards
Keith
At 10:56 PM +0100 5/30/08, Keith Hodges apparently wrote:
Dear All,
having discovered that we lack concensus... here goes with my idea.
I venture to suggest that every release team performs certain functions...
- Harvesting Fixes
- Removing Deprecated Stuff
- Loading the latest and greatest packages
- Producing some documentation for workspaces etc.
My plan is to take each potential activity as a sub-project, whose results generate either a script on installer.pbwiki.com or a Sake/Task.
So to generate a release candidate for testing we run the script end to end assembling all of the parts for example.
3.10 + MinorFixes + PackageUpgrades + Clean.
This produces a cantidate for 3.11, well at least the proposed content for 3.11, we then look at how to deliver it using the new tools we are developing.
Option 1. Run the script using using DS to record all of the changes made to the image, then generate a cs from that which can be placed upon the update stream.
Option 2. Save all packages from the prototype image to MC.
Generate 3.11 by taking 3.10 and loading in all the latest packages from MC. (requires atomic loading)
Having done this...
3.12 becomes 3.11 + MinorFixes + PackageUpgrades + Clean
and we go around again every 6 months or so.
Keith
I think it might be a good idea to plan for a way to save a snapshot of the base starting image as well as all the scripts that were run to create the version. I'm thinking It would be good to always be able to recreate a version from whatever starting point was captured.
Ken G. Brown
Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Option 1. Run the script using using DS to record all of the changes made to the image, then generate a cs from that which can be placed upon the update stream.
Option 2. Save all packages from the prototype image to MC.
I think it might be a good idea to plan for a way to save a snapshot of the base starting image as well as all the scripts that were run to create the version. I'm thinking It would be good to always be able to recreate a version from whatever starting point was captured.
Ken G. Brown
It is possible to snapshot the installer.pbwiki.com site as a zip.
It is also possible to obtain and save the script run by installer - Installer view: 'MinorFixes'.
The plan outlined here is to harness the non-deternministic sources into something version controlled before generating the final release. i.e MC, DS, or Sake/Tasks Then generate the new release form the old release + the version controlled stuff.
Sake/Tasks is simply a variant on ReleaseBuilder, but each task specifies dependencies. A typical fix to a class specifies a dependency upon that class being in the image.
One idea is to take the fixes from mantis and load the source of each fix into a Sake/Task method, so that the set of fixes, including their sources can be version controlled as an mcz package.
The nice thing about this is that the "fix" tasks can be applied to any image because the dependencies have been captured.
regards
Keith
release@lists.squeakfoundation.org