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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar