Debian-news is about one simple thing - news about Debian GNU/Linux and the top free distributions based on Debian GNU/Linux.


Development of Ubuntu 6.04 begins

The archive for development of the next release of Ubuntu is open. This means that developers can start their work on the next Ubuntu release.
You can also check it out at The Fridge, but Mark Shuttleworth announces:

As of today the archive for development of the next release of Ubuntu
is open. Here are some pointers to information about the goals we have
set for Dapper, the roadmap, the process we are following to identify
and specify features, and the tools we will be using to coordinate and
deliver The Drake.

We are preparing for our Montreal Developer Summit, which takes place
<> in Montreal, Canada next week,
and where the final list of features and release schedule will be
decided. If you would like to participate in that discussion, please
read the documents attached to this mail, or the newest versions on the
web at the URL's given, and make sure that you contribute your feature
specifications and suggestions. Don't mail them to me – capture them on
the wiki and in so that the entire community can
participate in shaping them, prioritising and implementing them.

Most of these are pages on the web site, or on the wiki. I have attached
copies of them to this message and will summarise them below, so that
offline readers have them handy.

1. *High Level Dapper Goals: *We have a statement on the high-level
goals of Dapper at (attached).
In summary: we aim for this to be an extremely *polished* release,
on both the desktop and the server. While we will ship the latest
Gnome and KDE environments, as usual, we will put extra effort into
polishing those to ensure the smoothest possible end-user
experience. We will also make server stability and deployment of a
new server-oriented Ubuntu derivative a high level goal for the first

2. *Planning for Ubuntu Below Zero*. The best place to start is the
FeatureSpecifications page in the Ubuntu wiki at (also attached). This
describes the process of creating a good feature specification,
registering it with Launchpad and putting it on the UBZ agenda.
*Please register all UBZ specs by 27 October*. The team will
triage and prioritise specs between the 27th and Ubuntu Love Day
on the 30th in Montreal.

3. We have a proposal on *changes to the standard Release Schedule*.
As Jdub put it, “We want Dapper to be different, so we'll have to
think differently about the release”. This proposal will be
discussed further at UBZ and finalized by the end of the
conference, what you'll find on the DapperReleaseSchedule page at is a current
suggestion, comments welcome.

4. Final decisions on the plan for Dapper features and priorities
will be taken during UBZ, and published through the wiki on a
spec-by-spec basis. I really encourage **everybody to participate**
through the wiki as we polish the final list. You can see the
actual specs being discussed at
(again, a copy of the current version of that page is attached but
it is changing rapidly at the moment as we finalise the agenda
so make sure your own key requirements are suggested before the
deadline of the 27th).

Breezy has had a wonderful reception out in the wild. That was in large
part thanks to the sheer number of people who chipped in a little bit of
sparkle… You all made Breezy a gem. Every time I get mail from someone
doing something amazing with Breezy my “Breezy ROCKS” counter gets a
bump, and I get even more motivated to build a truly free distribution
that I can share with pride and confidence. So I'm really excited about
this roadmap. The Drake will take the world by storm.

Be bold. Be professional. Be Dapper.

Meeting Overview

The November 2005 Ubuntu Developer Summit is being called “Ubuntu Below Zero” because of the location, in Montreal, CA. This meeting will include a co-hosted LTSP meeting and EduBuntu meeting, and the Launchpad team will be there too.
View the Meeting Home Page
Oscar the Grouch
Draft (Medium): Oscar the Grounch wakes up occasionally and complains about inconsistancies he finds in the database. He also can be persuaded to collect garbage.
Removing Default Programs
Braindump (Medium): Removing Default Programs – better mechanism to remove programs included in the default installation. Not removing ubuntu-desktop, maybe somehow remembering this is a default installation minus program removed, so you won't have problems when upgrading to a new distro version.
Autopackage Integration
Braindump (Wishlist): Autopackage Integration – Autopackage integration in Ubuntu to make it easy for commercial software to have installers. (also have a look at [WWW] klik)
Back Ports Promotion since back ports are now official and not everyone are aware. ( Martin Meredith)
Braindump (Wishlist): Backports is now official, and a lot of people use it. It would be nice to have a way for new users to know it's there and to be able to enable it in a similar way to enabling universe
Beagle integration
Braindump (Medium): We should make Beagle work out of the box for convenient searching in the desktop
Improving the wiki for documentation works.
Braindump (Low): Better Wiki – Moin needs some major love for doc work. We need to talk about how to achieve that.
How to move canonical over to using bazaar-ng ( mbp)
Braindump (Medium): Canonical is currently preparing to switch its internal development into bzr. This page is about this dogfooding process, our requirements and the current status of this project. We're making this public so that interested folk in the community can both contribute to, and gain from, the lessons and tools we use.
Adding gnupg signatures to bzr revisions ( mbp)
Braindump (Medium): We wish to add the Arch feature of gpg-signed commits. These serve as protection against accidental or malicious corruption of an archive, by testifying that a revision was actually created by the person who claims to have created it.
Handling keyword expansion in bazaar-ng ( mbp)
Braindump (Medium): We wish to support expansion of $Id$ style keywords, as used in cvs and svn. Expansion should be off by default, and optionally turned on per file.
Launchpad capitalization ( Matthew Paul Thomas)
Braindump (Low): Consistent capitalization for headings, and consistent capitalization for menu items.
CD Burning Solution
Braindump (Low): CD Burning Solution – evaluate solution used in breezy: many programs vs. one centralized program (e.g. gnomebaker).
faciliate mass installations of ubuntu in clusters
Braindump (Low): Enabling users to easily setup a computer pool (cluster) with ubuntu installations. We already have fully automated installation with d-i using preseeding (and/or kickstart). We plan to have a NetworkAuthentication facility. Let's put all parts together so they work out-of-the-box. Additionally, it should work nicely with ltsp setups. The admin must be able to choose if a specific box is intended to boot with ltsp or in d-i preseeded/kickstart mode
Provide Infrastructure for managing system configuration in ClusterInstallation
Braindump (Low): A ClusterInstallation enables the admin to install ubuntu unattended on his computers in his pool. We need some Infrastructure to manage configuration of his network.
Distribution Policy Decision Tracker
Braindump (Wishlist): When a policy decision is made for a $DISTRO, the discussion and rationale should be recorded in a structured form for future reference. This should be trackable in the Launchpad. Review Requested by Sivan Greenberg. Please review and approve of appropriate.
do not use ( Sivan Greenberg)
Braindump (Medium): do not use
Evaluate Ubuntu Guide
Braindump (Medium): Evaluate Ubuntu Guide, the forum howto's and the wiki pages to see what can be made easier to do in Ubuntu. * comment – Please note that the ubuntuguide has been evaluated, hacked up and integrated into Ubuntu by the documentation team. The “official” version of the guide is found by clicking “System->Help” and selecting “Starter Guide”. It will also be available online. As for the wiki, the DocumentationTeam and WikiTeam are working hard on it. * Reply: The point here is not to create/improve documentation, but evaluate what can be made easier so no guide will be needed. E.g. easier installation of nvidia/ati drivers (two recent howto's for ati drivers for breezy already have been viewed for more than 10,000 times together! And one already has over 100 replies. All this in 5 days!). Maybe it needs a better title.
Example content
Braindump (High): For each desktop application in the default install where it is practical, we should provide at least one piece of example content. This is valuable for testing, experimentation and demonstration of Ubuntu (especially the live CD). These examples should be small but meaningful, and easily discoverable. For example, when opening Rhythmbox for the first time, there should be an appropriately licensed song available for immediate playback, and gthumb should contain a couple of photos.
Discuss how to improve and fix non ubuntu docs.
Braindump (Wishlist): Existing Documentation – Fixing existing non-Ubuntu documentation (location, register to Yelp, etc.)
Extra CDS for download/purchase.
Braindump (Wishlist): Extra Cds – Making additional CD images available for download/purchase with software from universe with each a certain theme, e.g. a programming utilities cd. Mainly important for those of us that are not so fortunate to have broadband internet, who at the moment have a very difficult job installing extra software.
Eye Candy
Braindump (Wishlist): EyeCandy – more (optional?) eyecandy in Ubuntu
identify what takes the gnome session so long to start, streamline it down and get from gdm to desktop so fast we don't need a splash screen.
Braindump (Medium): For Dapper , we'd like to have a speedy gdm to gnome process when login is done.
Finding Packages
Braindump (Low): Development of more sophisticated and effective mechanisms for finding the right software package for a specific task.
Firefox Updates/Firefox plugins
Braindump (Low): There has to be a nice way to make firefox not display the “install missing plugins” link but tell to use apt to install plugins. Same for updates.
Integrating the forums with the rest of the Ubuntu community
Braindump (Low): This spec tries to identify problems with the integration of the Ubuntu forums community and the rest of the Ubuntu community and brainstorm solutions to fix these.
Taking wiki snapshot for offline use.
Braindump (Low): Ubuntu Wiki Snapshots (from the official one and from the LoCoTeams) on the users desktop
Modelling Bazaar's ghost revisions in Launchpad
Braindump (Medium): The database schema needs to be modified so it can model revision with ancestors whose only the revision-id is known.
Hardware Activation ( Scott James Remnant)
Braindump (Medium): Our current boot process has parts that rely on certain pieces of hardware being available, such as networking, bluetooth, sound and printers. We should instead provide a means to activate these when the hardware is detected rather than assuming it exists, and move the startup scripts into activation scripts instead.
Hardware Detection ( Scott James Remnant)
Braindump (Medium): Covers how we detect hardware, both when the system is running (udevd listening on uevent netlink socket?) and how we ensure that at startup we capture potentially missed events (synthesise udev events from a combined udevstart/coldplug replacement in initramfs?). Should also cover how we make sure we don't process events before we can deal with them (ie. network card module built-in, but none of ifupdown in initramfs). This mechanism should be used consistently in early userspace, userspace, the installation system and the live CD.
Make help truely helpful for users. ( mbp)
Braindump (Medium): Ubuntu offers vast opportunities for improvement in the quality, targeting, and presentation of its help and documentation. For Breezy, code effort should concentrate on adding search and print functions to the help viewer, and writing effort should concentrate on and local help for Ubuntu in general. After Breezy, code effort should go into making help presentation more compact and integrated, and writing effort should go into pushing properly-written help upstream.
Ship nautilus with ${home}/ as desktop
Braindump (Medium): Nautilus currently defaults to ${HOME}/Desktop/ as the Desktop folder. It is however possible to configure nautilus to have ${HOME}/ as the Desktop. This specification is about having this as default.
Home User Backup
Braindump (Wishlist): Home User Backup – Backup tool available in menus. Possibly backing up home dir + list of installed graphical apps? Allow incremental backups. Allow backup to harddrives, FTP ? Allow backup of shared partitions (typically FAT32 shared with windows).
Releasing docs on a predicted milestones instead of just before release.
Braindump (Wishlist): Inclusion of Documentation WIP in milestone releases – have the documentation team map out internal milestones that coincide with distro milestones, instead of doing much of the integration work a few weeks before release.
Installer for Windows, installing Ubuntu from within Windows.
Braindump (Medium): Installer for Windows -Ubuntu installer forWindows See InstallationUbuntuFromWindows.
Juke Box Centralization
Braindump (Wishlist): Jukebox Centralization is good, right now there are many programs to do similar tasks, for example, there's a ripper, a cd player, a music jukebox, there should be a centralized jukebox with support for playing cd's & ripping, maybe next version of rhythmbox? Do we need eog & gthumb? gthumb is better, and maybe f-spot gets better by the timeframe of dapper.
Launchpad Error Reporting
Braindump (Medium): Developers need better access and be informed when exceptions occur on the production and staging systems. Users need a token which they can give to launchpad developers allowing them to track down exception and environment information from the broken request.
Launchpad Rollout Procedures ( Stuart Bishop)

Braindump (Medium): With more and more infrastructure relying on Launchpad and the database being available, we need to define policies and procedures for rollouts so required downtime does not affect other peoples schedules. Some guidelines as to what people consider acceptible downtime will also need to be determined.
Looking Glass
Braindump (Wishlist): Looking Glass – A 3D Desktop with much less requirements than Vista [WWW] LG3D Site.
Integrate the menu editor into the panel.
Braindump (Wishlist): Menu Editor Panel Integration – Integrate the menu editor into the gnome-panel (the menu itself), to let the user changing the menu directly (using the right-click, for instance), and the ability to sort the menu items arbitrary (now the items are sorted alphabetically, only).
Revising the GNOME menu layout , make it less cluttered, more usable.
Braindump (Wishlist): The Gnome menu system has not had a good review in quite some time. There is some issues that need to be addressed. Menus Revisited – Preferences menu – how to make it less cluttered. Putting system tools to pasture.
Helping users with migration to Ubuntu. ( Matthew Paul Thomas)
Braindump (Low): Getting people to migrate to Ubuntu is a three-stage process. First, make it easy for people experienced with other OSes to use Ubuntu by providing help and training. Second, make it easy to migrate by providing software to transfer documents and settings from existing OS installations. Third, once the path is ready, encourage people to walk it.
Fix misspelled launchpad URLs and default to correct URL based on string distance.
Braindump (Wishlist): This will save request time when someone misspecifies a launchapd URL and retries to access a fixed URL. Launchpad should default to a correct URL given the smallest string distance form the specified URL.
Multiple Selector Interfaces ( Brad Bollenbach)
Braindump (Medium): A standard way of implementing multiple selector UIs in Launchpad, e.g. for targeting several bugtasks to be fixed for a certain milestone, targeting several specs to be implemented for a specific milestone, etc.
NestedTreeSupport in bzr
Braindump (Medium): Bzr should provide out of the box support for operations on nested trees.
Make ubuntu authenticate against Network Authentication services ( Adam Conrad)
Braindump (Medium): There are many different kinds of network authentication in use today. Ubuntu should be easily configured to use any of these out of the box, without asking any questions for the default local configuration. In order to accomplish this, there should be a single utility, similar to Fedora's authconfig, that interfaces with package-specific configuration scripts. Specifically, OpenLDAP and Active Directory should be supported.
Network Configuration and Activation ( Scott James Remnant)
Braindump (Medium): Activation of network hardware is a complicated issue, we need to ensure that any hardware the user plugs in is automatically configured and used if possible and that devices such as modems and wireless cards just work; including choosing the appropriate default route for the system. The best tool for this job still seems to be network-manager, but it doesn't really play nice with the netbase/ifupdown system we currently use. This BOF will talk about making them both work together when the hardware is activated to get it running without bothering the user too much. Also the WEP Shared Key/Open Key/WPA mess should be addressed here.
Non Broadband Users needs
Braindump (Wishlist): Non-Broadband Users -In general have some thoughts at non-broadband users and what they need/miss.
Useraccount with no persistant environment and Home directory ( Reinhard Tartler)
Braindump (Low): NonpersistantUsers allow anonymous users safley to use a computer. They get a defined environment, where they can use ubuntu in exactly that way the administrator allows them. After a nonpersistant user logs out, her environment will be reset.
Autoconfigure GNOME keyboard notifier to be ready for input in your language.
Braindump (Wishlist): This specification will discuss how we can enhance language-selector such that upon a given set of lanugages chosen a user wish to be able to input it, GNOME keyboard notifier gets autoconfigured to include them, with a sane default for switching between them.
Fixes to dependency management system in dpkg, apt and higer
Braindump (Low): Two fixes to the dependency management system in dpkg, apt and higher layers: Implement Breaks, and implement the correct selection behaviour for Replaces.
Package Selection Snapshot ( Sivan Greenberg)
Braindump (Wishlist): This spec dicusses a way to take package selection snaphost on a users system and restore it back on demand.
PackageVersionConflicts between Debian and Ubuntu
Braindump (Medium): The question was, when we package new software which is not in Debian already, should we use -0ubuntu1 in our version, or should we use the normal Debian standard (-1). We have to discuss the impact for syncing and merging etc. Proposal was made by sabdfl.
Mark some names as reserved so people won't be able to use them
Braindump (Medium): Users have a 'name' attribute on their corresponding Person object. This is a short, unique ASCII name suitable for use in URLs and as a short identifier. It is also possible to login using this name. Ubuntites will also get email addresses. We want to stop users being able to change their names to known confusing or dangerous terms, such as 'root', 'administrator', 'ubuntu', 'canonical' etc. We also need to ensure that names do not conflict with any manually added email aliases in the domain or well known names required by RFCs such as 'abuse' or 'postmaster'.
PostgreSQL Transaction Isolation Levels
Braindump (Medium): All of our code currently uses the default transaction isolation level in psycopg, which is the highest. It may be possible to run many of our systems at less strict transaction isolation levels which will reduce locking issues.
Replacement Init System ( Scott James Remnant)
Braindump (Medium): Discuss replacing the tried, trusted and terrible sysvinit with something a little more flashy such as initng or launchd.
A MOTU assisting reviewing platform ( Reinhard Tartler)
Braindump (Low): Revu2 is a tool for assisting MOTUs to review packages. Packages are created mainly be contributors, but also by other tools.
Improving Gnome Screen Saver for use in Dapper
Braindump (Medium): ScreenSaver – Speccing gnome-screensaver communication with the desktop (handling of fullscreen running apps, access from processes like acpid). And making it wonderful to use, too.
Securing Rocketfuel
Braindump (High): Currently code committed to rocketfuel is signed by a GPG key stored on chinstrap and stored on chinstrap. Code is then pulled from rocketfuel to all of the database and production servers and run. This means that if chinstrap's pqm user is compromised all of our production systems may shortly follow and would be considered tainted, soon including the distribution itself, and from there the attack flows to our millions of users using automatic updates. Chinstrap is a general access box with lots of accounts and literally hundreds of attack vectors making it the most likely box to fall to attack.
SELinux Integration ( Andrew Mitchell)
Braindump (Medium): We wish to build on the work being done in Debian & Fedora to integrate SELinux functionality into Dapper Drake. The technology has received exposure & development in Fedora Core & is currently being integrated into Debian. This specification is to plan out how best to integrate with minimal impact into Ubuntu.
ShipIt Workflow
Braindump (Medium): Despite playing a major role in Ubuntu's popularily, the ShipIt CD distribution process is not documented causing misunderstandings. Parts of the process are documented in the form of the ShipIt code, and other parts in various peoples heads. We need to document the full process from an order coming in to confirming that the order has been sent.
Smaller Updates in the form of patches
Braindump (Wishlist): Smaller Updates – Updates in the form of patches, I think suse is doing something like this? (even great when only as a last resort for dialup users). The new Mandrake 2006 has support for delta rpms (contains the binary difference of two packages). Apparently this is how Mandrake does their online updates now.
Showing a splash screen while shutting down.
Braindump (Medium): Showing a splash screen while shutting down.
Streamlined Boot Sequence ( Scott James Remnant)
Braindump (Medium): Identify what we're actually doing during boot up, and decide what we actually need to be doing and drop (or move) anything we don't; regroup the boot sequence into clear targets (“hardware detection”, “console setup”, “filesystem checking and mounting”, etc.). All of the messages printed by the boot process should be clear, consistent and meaningful.
Email System for the Ticket Tracker ( Björn Tillenius)
Braindump (Medium): The next application in line to get an email interface is the Ticket tracker. At the moment it doesn't send any email notifications at all, and it's not possible to send email to it. So it needs both an outgoing and an incoming interface. This spec covers both interfaces in short to give an overview, more detailed specs for each interface will be created later.
Incoming Email Interface for the Ticket Tracker ( Björn Tillenius)
Braindump (Medium): An incoming email interface for the Ticket tracker, which allows adding comments, and editing tickets via email.
Outgoing Email Interface for the Ticket Tracker ( Björn Tillenius)
Braindump (Medium): Email notifications will be sent whenever a comment has been added, or a ticket has been changed, as well as when new tickets are opened.
Ubuntu in Cluster solutions/enviroments. ( Fabio Massimo Di Nitto)
Braindump (Medium): Breezy had the first real cluster love (HA oriented). This BOF target is to evaluate all possible combinations of clusters solutions we would like to offer to the community (more high availablity solutions, high performance solutions, thinclients reusage into cluster environment).
Braindump (Wishlist): .Mac Look at possibility of starting a .Mac-like service for use across multiple Ubuntu computers (using Launchpad??)
Improving the design of the Ubuntu web site.
Braindump (Wishlist): The Ubuntu Website is highly polished, but poorly designed, uninspiring, and poorly integrated with the wiki. A BoF would be enough time for a heuristic evaluation to compile a list of improvements.
Usability Review, reviewing usability issues in time.
Braindump (Wishlist): Make a focused effort to find and correct usability flaws and nitpicks before release. (I think someone has already started, and did quite a good job – UsabilityWishlist)
Usplash Until Desktop
Braindump (Low): Usplash currently bows out once gdm flips the vt, for users who are using gdm autologin, it would look sweet if it could wait until gnome-session has got their desktop ready for use.
Easy switching between/adding of ubuntu variants (ubuntu,kubuntu,edubuntu,etc…)
Braindump (Wishlist): Easy switching between/adding of ubuntu variants (ubuntu,kubuntu,edubuntu,etc…)
Provide a reasonable video playback capability in the default desktop
Braindump (High): Video playback in Ubuntu 5.10 is problematic: gstreamer seems to have problems with A/V synchronization, etc. We need a solution which works well out of the box for playing Theora+Vorbis streams
Translating canonical's and ubuntu's related web interfaces and pages.
Braindump (Medium): Webs Translation – Start the process of translating and localizing the Canonical/Ubuntu web services (Ubuntu web page, Launchpad…) into another languages.
ZeroConf Support with Avahi and friends ( Trent Lloyd)
Braindump (Wishlist): ZeroConf allows computers to communicate on a network without any kind of configuration, additionally it provides for discovery of services, so instead of specifying an IP you can select from a list of advertised servers on the network. This is usefull so that you can simply plug two laptops together an transfer a file or play a network game. It is also usefull in situations where you don't know about the other services, such as people to chat to or files to share.
Better support for CJK
Implemented (Low): This project (maybe a package) aims to support CJK better .

Copyright 2004-2005 Canonical Ltd. – Copyright terms – Help us improve


This page describes the process by which we define, discuss, schedule and implement new feature specifications in both Ubuntu and Launchpad.

Ubuntu and Launchpad are both complex software projects with community involvement to various degrees. We need to keep track of many different initiatives, upstream and in the distribution, and we need to be able to know exactly where we stand on the delivery of those during the release cycle. We use the [WWW] Launchpad Specification Tracker to do this.
The Specification Process

So, here's the process in a nutshell. Follow links to other pages for more detail on any particular topic.


Write your specification in the wiki. There are currently separate wiki's for Launchpad [WWW] here and Ubuntu (you are in it now ). Of course, take a look at the existing specifications to ensure that you are not duplicating an existing proposal. Most important is that you follow the specification template that is current for that wiki. When you create the page, you will have a set of Page Templates, look for one called SpecTemplate, and use that. The spec should be as detailed as you can make it. There are best practices documented on the SpecSpec. Use the sections provided as a guideline. Change it if you need to, for a good reason, and make a note of why you are following a different format if you do so.

Register your specification in Launchpad. This is crucial, as we keep track of specifications in Launchpad so that we have a rigorous structured list of them which we can prioritise. You can attach the specification to Ubuntu, the distribution, or to any of the upstream products registered in Launchpad, and of course Launchpad itself is registered in launchpad. Use the following quick URL's:

[WWW] (Ubuntu specs)

[WWW] (Rosetta specs)

[WWW] (Malone specs)

[WWW] (General launchpad specs)


Note that in each case the URL above will show you the list of specs already registered for that distro or product. Now, on the top right of the page you will see a link to “Register New Specification”. Click that to register your spec. If you will be coding this yourself, make yourself the Assignee. Don't make anybody else the assignee unless you have discussed it with them or pay their salary.

If you are the person responsible for drafting the specification and getting it to the point where it is approved, make yourself the Drafter. And if there is someone else who will need to sign off on the spec before implementation begins, or will have to sign off on the code before it lands, then you should make them the Approver.

You will have given it a name. Now you can update the wiki page of your spec with the URL straight to the Launchpad entry for the spec. This allows you to jump quickly between Launchpad and the wiki spec itself.

Please do not set a high priority for your own specification. Let the product team, or distro team, determine their own priorities. If it's really, really important to you, you should either start work on the code yourself, or reach for your chequebook and fund the development.


Propose the spec for discussion at a meeting. Launchpad keeps track of meetings held by the Launchpad and Ubuntu teams. Currently, the only meeting registered is UbuntuBelowZero. You can propose your spec for that meeting agenda using the “Add to Meeting Agenda” menu item (top right again) on the spec page in Launchpad.

Gather a community around your specification. Don't assume that people will find it. Announce your spec on [MAILTO] and on #ubuntu-devel. Get people to subscribe to the spec as interested parties. If you have someone who wants to implement it, make them the assignee of the spec. NB, see above, don't make someone the assignee unless they have agreed or you are funding them in some way. The better the community you can build around your idea, the greater the chances that it will be implemented soon, and well.

Work to get approval for the spec. When your spec is first registered it will be in the 'Brain dump' state. Over time, its status will change from 'brain dump' to 'draft' to 'approved'. There are a variety of states there. Please do not move a spec to 'approved' unless it really has been approved by the people who have to land the code. You can mark it 'Draft' when it has everything in it that you think it should have, including implementation strategy and discussion of any UI, with mockups, and an assessment of its impact on existing code. When you are really, really certain its good, you can move it to 'Pending Approval'. The approver can bump it back to draft or braindump. Don't mess around with the status, people will just start to ignore your specification. Really.

Make sure you register spec dependencies. The specification tracker has many features. It allows you to ask someone to review your spec, for example, and keeps track of that. It also allows you to point to any other specifications on which your spec depends. For example, if it only makes sense to implement B after A, you can capture that information. This is really, really useful to the development team in planning and prioritising their efforts. There are other spec tracker features that you might like too. Spend some time exploring it.

Start implementation of the feature. You should use Bazaar, and publish your branches, and register them in Launchpad. In due course we will support linking of the branches directly to the specifications, so that people can find your code very easily.


Features that are proposed, caucused, discussed and implemented openly and transparently have the best chance of making it into Ubuntu and into Launchpad. Use this process to steer an idea that you have all the way to delivery. Bear in mind that you can't set priorities or goals for anybody else unless they agree to it, or unless they report to you, or you are willing to fund it. To make something happen, START it and try to gather people around you to make it go faster. Be willing to do it yourself, all the way, if necessary.

last edited 2005-10-21 08:27:35 by MarkShuttleworth


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


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 bugsthat will inevitably be introduced by the sync.

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

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


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.

Hardware Certification


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.

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.

last edited 2005-10-21 19:06:20 by JeffWaugh2


The Dapper Drake (targeted for 2006/04) release of Ubuntu will be supported for 5 years on servers, and 3 years on desktops. This page gives a high-level overview of the goals of this release.

The actual bug tracking, translation, feature tracking and archive management of Dapper will be done on, the infrastructure we have created for Ubuntu and its derivatives as well as for upstream projects. Launchpad is under active development, see #launchpad on to speak with developers.
Feature Goals


Substantial polish and integration of the existing desktop environment is the primary desktop goal, for both Ubuntu (GNOME) and Kubuntu (KDE).

Dapper should come pre-configured to do the Right Thing, without asking questions, with all forms of content that the standard install is configured to handle. Double-click on a PDF, and you should see it in Evince (Ubuntu). Double click on a PNG, and you should see it in the Gnome image viewer.

The sound theme should be professional, and muted by default (other than startup and shutdown sounds).

Artwork will be an evolution of the Breezy artwork, with substantial work done to make an excellent overall visual impression on Ubuntu, Kubuntu and Edubuntu.

High priority will be given to specifications that require relatively little new code but improve the “smoothness” or polished feel of the final product.

Software discovery and installation will be a target of focused work. It should be even easier to find software that is either part of Ubuntu main, or universe/multiverse (recognising the issues of support and supportability involved), and even 3rd party software that is built and packaged for Ubuntu.

We will work hard to make network-wide enterprise updates easy to manage. So people who are deploying Dapper across a corporate network can ensure that they retain control over the distribution of updates to those desktops.

We will consider LSB and related certification standards. We have not yet determined the feasibility of aiming for compliance with such standards, but will take the decision at UBZ.

We will support the server administrators who want to deploy Dapper on mission-critical servers, with a flavour of kernel specifically tuned to meet their needs.

The actual detailed specifications for Ubuntu are being tracked at [WWW] and the set of specs targeted at Dapper will be linked separately after our developer conference.

last edited 2005-10-21 15:34:50 by HiddeBrugmans

No Response to “Development of Ubuntu 6.04 begins” »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Debian-News is not related to the Debian Project.
All logos and trademarks on this site are property of their respective owners.