Release Process/Development

General process

At the beginning of the development phase, the appropriate release page should be updated to reflect this. At the very least, the status property should be updated to say "in development". The release page should also state the build system version and configuration being used, along with the relevant dropboxes, etc.

An announcement should be sent to the devel mailing list, informing the community that development has started.

Development build configuration

The Build system should be configured to pull packages directly from Fedora's release repository, and from updates and updates-testing. RPM dropboxes should be created for the release - one for generic bits (e.g. f14), and one for each laptop model (e.g. f14-xo1 and f14-xo1.5).

Similarly, the build system should pull activities from activities.sugarlabs.org, so that we are always receiving the latest and greatest during development.

Development builds should start with a build number of 1 and be published at http://build.laptop.org (accessible on dev.laptop.org at /var/www/build).

Development builds should be published once or twice a week, with each build announced on the devel mailing list.

Bug & task tracking, code inclusion, QA

We use trac at http://dev.laptop.org to manage bugs and tasks. A milestone (or a series of smaller milestones) should be created for each release. Bugs should be triaged by the release manager (or appointed person) as they come in.

Not all contributions need to be tracked by tickets. Use trac when it helps you organise and coordinate, but don't feel pressured to spend time using it when you could just submit a small fix through the normal channel and be done with it.

If working on a ticket basis, when a ticket is resolved by the contributing developer the developer is responsible for: obtaining code review and upstream inclusion, performing initial tests and for packaging the fix in an appropriate form for inclusion, which is one of the following:

1. If the fix is in an activity, the new activity should be published on http://activities.sugarlabs.org
2. If the fix is in a package, the new package should be submitted to Fedora updates-testing
3. In exceptional cases, the package is not suitable for Fedora and can be placed in an appropriate RPM Dropbox
4. Kernel fixes should be pushed to the appropriate branch, for automatic build and inclusion via RPM dropboxes
5. Build system changes simply need to be committed to the appropriate place

When the ticket has reached this state, details of the newly submitted activity or package should be noted, and the developer should put the ticket in "add to build" state.

When the release manager releases a development build, he should review all "add to build" tickets and move them to "test in build" state, with a note e.g. "test in 11.2.0 build 6". Make sure that the ticket has a test case listed.

The ticket is now ready for QA; the QA team normally handles this by verifying the fix and closing it, or by performing an initial verification and by moving the ticket state to "finalize" for further verification later.

New locales/languages

Even though there is a documented process for requesting inclusion of new languages it does not hurt to proactively ask relevant people at this point in the cycle to identify new languages to include.