Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/dapper-release-process

See DapperReleaseSchedule for the final DapperReleaseSchedule.

Rationale

Dapper is a long term supported release; its release cycle will be RIGID and BORING. Nevertheless, we need to consider some tweaks to our standard release schedule to make sure we can deliver on the promise of a super-stable and ultra-polished Ubuntu for the masses.

The documentation team wants the UserInterfaceFreeze and the ArtworkFreeze toughened up and clarified, in order to be able to deliver screenshots in time.

Design

We propose to make the following changes to the process that was followed during the development of Breezy:

The Distribution

• We will open up the entire archive for syncing from upstream, from Debian, and other sources, until UpstreamVersionFreeze. This is in contrast to an initial proposal only to sync feature goals and universe. Upon analysis, it seems that the benefits of syncing newer packages outweigh the number of new bugs that will inevitably be introduced by the sync.

• We will try to deliver Flight CD 1 (the first milestone CD release) around 17th November, depending on how much work on this can be done during the Launchpad part of UBZ. After this, we will aim for a milestone CD release every two weeks.

• We will schedule an early merge push (ideally immediately after Flight CD 1, depending on how quickly that can be delivered) in order to capture most of the risk into Dapper as early as possible, and leave UpstreamVersionFreeze at its present position. In particular, we should merge all packages in main as close to the start of the release cycle as possible, then again directly after UpstreamVersionFreeze. While this may involve some extra development effort, we feel that the substantial reduction in risk makes it worth it.

  • We will prioritise library and base system merges, etc. We will build a tool to show us the merge to-do list (e.g., packages which haven't been merged since Breezy) in some reasonable priority order.

  • There is a risk of ending up with an excessive merge workload at UpstreamVersionFreeze. We will monitor the count of required merges and schedule additional merge pushes during development if necessary.

  • We have found in the past that newer universe packages tend to demand newer dependencies in main. Accordingly, universe will enter UpstreamVersionFreeze at the same time as main, in order to reduce dependency tension between newer versions of packages in main and universe. The exact details of sync and merge schedules will be the decision of the MOTU team. As in main, syncs and merges to universe after UVF must be verified to build and install on current Dapper (or exceptions granted for new or updated dependencies).

  • Since entirely new packages in universe are relatively safe and attract a number of new developers, they will be liberally admitted until FeatureFreeze if they do not require additional or newer dependencies.

• We will move StringFreeze and DocumentationStringFreeze one week earlier, to allow documentation to be reviewed before finalising it for translation. This still allows plenty of time (three weeks) from the GNOME string freeze to ours.

• We will consider expanding the review team to take advantage of peer review or to add additional upload approvers during the earlier, less conservative phases of the freeze, in order to reduce bottlenecking on approvers. However, in order for this to actually save us time we will need to discuss infrastructural changes with the Launchpad team, such as adding a lightweight reviewing workflow.

• Final release will be one week later than usual, to allow for extra non-invasive polish-only changes, settling, testing, documentation of errata and bugs, and the taking of a collective deep breath before MDZ rolls the ISOs. This will not affect the release date for Dapper+1 (that is, the Dapper+1 release cycle will be shortened by one week).

• The ArtworkDeadline has been eliminated, and is instead part of the (much earlier) UserInterfaceFreeze at T-8 weeks.

• Preview will be known as Beta instead, due to messaging problems with 'Preview' being seen as a very buggy sneak preview, rather than a testing checkpoint. We will make explicit efforts to encourage very widespread testing of the Beta release, with specific emphasis on finding and fixing hardware support regressions.

• On a similar note, we will make an effort not to include "6.04" in visible branding (/etc/issue, /etc/lsb-release, CD image volume labels, CD image file names, symlinks in the archive and on cdimage, etc.) until the release candidate, to avoid bugs in the Dapper preview being reported as bugs in 6.04.

Documentation and Translation

• We will introduce a freeze date for changes to menu structures, application menus, and (broadly) application strings, to allow for the maximum coverage of our translation teams. In addition, we will freeze core documentation to allow for the translation of the documentation itself.

• There has been some discussion of an earlier documentation freeze to allow a final review pass before sending documentation to translators. Any such freeze will be managed internally by the documentation team; DocumentationStringFreeze will remain as the hard deadline.

Hardware Certification

• This release cycle will include a deadline for hardware certification applications. We are building a list of specific hardware SKUs (model numbers) on which Dapper will be certified pre-release. We will work to ensure that ALL hardware on that list before the deadline is perfectly detected, configured and activated upon installation. Hardware vendors that join the hardware certification program after that date will have to work towards additional drivers separately installed after the core OS, or custom ISOs that include the extra code needed for the detection and configuration of their hardware.

• In addition to the LaptopMission, which continues into Dapper with even more laptop models formally tested, we will have a specific testing program for servers, including a deadline for server manufacturers to submit hardware for testing. The exact deadline has yet to be decided.

Links and cross-references

DeveloperResources has the freeze exception process

GNOME 2.13.x/2.14 release schedule

CategorySpec