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 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.

• 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.

• 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).

• UpstreamVersionFreeze will apply to universe as well, though new packages will be liberally admitted after UVF if they do not require additional/newer dependencies. All syncs and merges to universe after UVF, as in main, must be verified to build and install on current Dapper (or exceptions granted for new/updated dependencies).

• 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.

  • I think we should have a dual document freeze: Breezy taught us that lots of errors in the documentation got picked up after document freeze and this left us either correcting them and reuploading for translation and/or not correcting them at all. Therefore I would propose that the document string freeze is made slightly earlier, allowing for a period of proper review, followed (1 week, 2 weeks?) by a full freeze after which NO further changes can be made and documents to go for translation. (MatthewEast)

• I suggest that any earlier documentation freeze be managed internally by the documentation team, and the existing DocumentationStringFreeze remain as the hard deadline. (MattZimmerman)

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.

Outstanding Questions

• Should Universe freeze later than Main?

  • MarkShuttleworth: we have found in the past that newer Universe packages tend to demand newer dependencies in Main. If we ask the MOTU to observe the same UpstreamVersionFreeze then we will go through the "rush to get the latest thing I care about" at the same time, reducing the risk of tension between Main and Universe post-UVF. Alternatively, we can afford to be more aggressive in Universe, so perhaps we should allow newer versions into universe as long as those do not require newer versions in Main.

  • OliverGrawert: I like the idea of freezing for the sake of stability, but I'd also like to propose that we keep universe open longer for NEW packages that don't require changes to underlying libraries. New MOTU hopefuls often get attracted by packaging something from UniverseCandidates and it gives you a sense of achievement to see "your" package in the distro... So to not drag manpower away from merging and transitions that happen before UVF I propose that we have a timeframe of two or three weeks where all this NEW stuff that applies to the above criteria can get in.

  • ColinWatson: BOF decision: UVF universe as Mark suggests; delegate decision on sync/merge schedule to MOTU; extend UVF for new packages to FeatureFreeze.

• Ideas for expanding the review team: peer reviews or additional upload approvers during the earlier, less conservative phases of the freeze (proposed by MartinPitt)

  • ColinWatson: Need infrastructure for this so that it actually saves us time, but in general we would like to do this; will discuss with Launchpad team.

• Consider more merges during development, so we don't end up with 1000s at UpstreamVersionFreeze.

  • ColinWatson: Will monitor the delta and see how it goes; we will do a big merge push early in the cycle, if possible immediately after Flight CD 1 (depending on how quickly that can be delivered).

Links

[http://live.gnome.org/TwoPointThirteen GNOME 2.13.x/2.14 release schedule]