CODE FREEZE (or at least slush...)!

[Jim Gettys]

NOW READ THIS!

This is the "home stretch" for our stable build for first deployment.  

ZEROTH: THANK YOU for all your hard work and contributions to date!!!!
Barring unforeseen events, we are now one week from mass production.

FIRST: there will be a release after this within a reasonably short
period of time, and another after that, and so on, as we have with
Trials 1-3.  If what you are working on isn't ready, do remember this
and make realistic assessments as to whether your software is really
able to make the following dates.  Remember that in the *first* week of
production there will be more systems built than all systems built to
date: are you REALLY prepared to handle the resulting bug reports and
questions? 

SECOND: A fundamental difference with this release and (some of) the
previous builds is that it must line up with shipment of actual
hardware: the train has started moving and we must be on board in time
for G1G1 and country deployments. We MUST have the build in hand as
these systems go into the distribution channels.  These channels take
time.

THIRD: terminology: as many of you know, we have a build sequence called
"joyride" we've been using for rapid testing. "killjoy" was universally
hated as a name: the name of the release we are working on is
"Update.1".  It is the first update to the software going onto
production systems in the factory this week.

Transition of packages from joyride to our Update.1 candidates will
thereafter be controlled; what is more, you should only be using Joyride
for final testing before this commitment. The Update.1 build sequence
will start in the next day or so as soon as Cscott has it running,
derived from today's Joyride.  He will send out an announcement when it
is ready.

FOURTH:  We must collect source packages for all software; we need to
ensure our software can be built reproducibly both for legal reasons and
to be able to resolve security and support problems in a
timely fashion. You will find we will become increasingly insistent that
source packages are available.  Mako Hill will be inventorying our
packages and ensure we have everything.

FIFTH: Testing

Here is the link to the test plans: http://wiki.laptop.org/go/Tests

This page contains all the test plans that have been written so far.
Many of these are out of date, as activities change faster than we can
change the test plans. 

Activity developers should edit these plans and/or write their own. You
know how your activity should work better than anyone else, and it
spreads out the work load. The test plans would be, in a way, tutorials
of the activities. By having and using these test plans, it will
encourage you to retest your activities after making changes, catching
regressions as soon as they occur, and enable others to help you with
testing. 

The first item listed on the page is the 1 Hour Smoke Test. It is meant
as a test to quickly see if any great regressions have occurred between
builds. This is a work in progress. Suggestions are welcome. Note: yani
is working on the connectivity part of the test, so that should be added
soon.

Note the existence of the smoke was found very useful this last weekend.
We encourage everyone to spend a bit of time thinking about a test plan,
so that others can test your software.

SIXTH: Update.1 process going forward

You should now be complete with your development at this date (November
5, all over the world: good thing I'm a bit sloppy about my knowledge of
timezones, but even so, note I'm no longer confused... :-))....

Changes MUST be approved by the process described at
http://wiki.laptop.org/go/Update.1_process, as explained below.

Everyone please concentrate on testing and bug fixing the build we
intend to ship.  Once we're pretty much frozen for shipment, joyride
will be reopened for further work for Update.2, much as Trial-3 froze a
several weeks before mass production.  

***Only upload items into "joyride" you expect will work for final
testing before commitment to update.1 AND which are to be fixed for
Update.1***  

You should normally be doing your development on the Update.1 builds,
(which should become available in the next day) *NOT* joyride, except
during such final integration testing.

If you are not finished with any feature:
        
You MUST notify the community of any significant code beyond a simple
bug fix you expect you would like to change in the next week ASAP, and
*WHY*. This should include bug numbers for each feature.


SEVENTH: Approval process.

The release team will approve tickets and assign to the designated
release engineer (temporarily cscott until Dennis is up to speed) . 

The bundles/RPMS are expected to be present in Joyride for anything not
coming from Koji (the Fedora build system).  Note that SRPM's for each
RPM MUST also be present, and should be updated each time the binary RPM
is updated.  Activity bundles that are solely Python do not need
separate SRPM's; if your activity contains binary code, we expect the
source/SRPM's to also be present along with the activity bundle.

To get approval for bug fixes or some remaining enhancement to actually
go into Update.1, use the following process:

o there MUST be at least one ticket in Trac, it should already have
been marked for resolution in Update.1; it can reference 
additional tickets to be closed by the commit, and should 
clearly indicate exactly which bundle or RPM should be applied 	
to Update.1.

o If there are any inter-dependencies on other fixes, please
make sure that is clear.
	
o the ticket should contain the patches being applied to resolve the
issue(s). If possible, please tell us how to verify the bug fix.
	
o Assign the trac bug to the user "ApprovalForUpdate".  Add yourself to
the list to ensure you get notification of any changes. This will let
Jim/Kim/Walter have a single work queue; if you can catch us on IRC, you
may be able to get approval immediately.
	
o If the change is approved, we'll assign it to our buildmeister
 (cscott this instant; Dennis when he's ready) to process.
	
o When the update is in the new Update.1 build, the buildmeister
will reassign it back to you.
	
o You are then expected to test the resulting update build,
and mark the bug(s) closed and verified.

EIGHTH: Release notes.

Please mark any bugs/issues that should be release noted by the keyword:
"relnote".

        
Questions? Comments? Suggestions? 
                            Best Regards, and thanks again,
                                - Jim Gettys

-- 
Jim Gettys
One Laptop Per Child