Ubuntu Wiki

Dapper is a long term supported release, so 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.

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

The Distro

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 outweight the number of new bugs that will inevitably be introduced by the sync.

2. UpstreamVersionFreeze will be 2 (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).

3. Final release will be 1 (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 ISO's.

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 SKU's (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 ISO's 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 dont 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.