Ubuntu Wiki

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

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

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

2. UpstreamVersionFreeze will be two weeks earlier than it was in Breezy. Of course, feature goals such as Gnome, KDE, Firefox, OpenOffice and other items that are identified up front will continue to sync until their upstream stable release. Note that we will be especially careful with the versions of server products included in the Ubuntu-for-servers ISO. The extra two weeks will give us substantial time. Both Main and Universe will observe UVF simultaneously (** see below for discussion of this, it's very much open for debate).

   • Alternative proposal: 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.

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

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

Documentation and Translation

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

Hardware Certification

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

2. 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. The server deadline will be

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.

Discussion

• Documentation team wants UserInterfaceFreeze and ArtworkFreeze toughened up and clarified.

• MOTUs want to have an UpstreamVersionFreeze, but a few weeks later. Dependencies tend to get in the way, however - this is particularly problematic for dependencies in main.

  • We have to measure our resources, not all MOTUs will work on the merges.
• 1300 non-main source packages modified in breezy.
  • Many of them could be synced from Debian Sid

• Create a MergeStrikeForce to kick the crap out of our early merge problem?

  • Prioritise merges by library, base, etc. Build a tool to generate these.Process

  • Keep track of # of merges during cycle, so we don't end up with 1000s at UpstreamVersionFreeze.

• Request to increase the size of the Review team as the release approaches (currently this task falls on Colin and Matt only).
• 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.

• Do not create the 6.04 symlink to dapper until the FinalRelease.

• We'll ship a week later than we did for breezy (27 weeks).