This session is for reviewing the state of Distributed Development, and planning for the next cycle.

Several ideas for improving debhelper support for Python: * python-multibuild for python3 w/ dh integration * dh_auto_test Others?

An informational session to educate new UDD users that includes a short demo and informs more experienced users about new features.

At several points in the oneiric cycle, there were mismatched expectations regarding the handling of the toolchain. Despite discussions at last UDS that concluded with agreement that the kernel did not need to check the exact compiler version in use for building out of tree modules, the kernel team expected to use the same compiler version for building the kernel across all architectures for a given milestone, a requirement that the foundations team was not aware of. The outcome of this session is to be an understanding of any requirements for toolchain stabilization (gcc, binutils) from other parts of the team and a description of any freezes (timelines, scope, and rationale) that need to be applied to the toolchain for precise above and beyond the standard freezes.

When preparing milestone releases, we often need to turn around fixes quickly. The pipeline from a developer source upload to a full set of updated image builds on all architectures is currently somewhere in the region of nine hours. We would like to make this much quicker.

Discuss and implement in Ubuntu a framework for generating dkms packages from a driver source tarball. The framework makes it easier to create an maintain dkms packages by automating many of the mechanical tasks currently required by dkms.

= Problem Statement = At present, there are 101 SystemV services in the Precise main archive that have not yet been converted to Upstart jobs(*). This needs to be recified. = Important services that need conversion = This is a selected list, but the following are important services that we could start with: - rabbitmq - open-iscsi - bind9 - apache - postfix - puppet - postgresql - tomcat6 - memcached = Rationale for Change = - Upstart is our init system of choice (SystemV is considered legacy). - Although Upstart does handle SystemV jobs, undesirable behaviour can and does result when there exist relationships between SystemV and Upstart jobs. - Upstart jobs are easier to maintain than SystemV jobs. - Upstart jobs are simpler than SystemV jobs. - Upstart jobs place the burden of managing certain repeated tasks on Upstart, rather than requiring each SystemV service to re-invent the wheel (often badly). - We wish to segregate SystemV jobs from Upstart jobs to optimize system shutdown. - See http://upstart.ubuntu.com/cookbook/#critique-of-the-system-v-init-system - To allow Upstart to be fully integrated into Debian, SysV services scripts *and* Upstart job files need to exist for a package. = Proposal = - Muster Community interest in an effort to port the remaining SystemV jobs to Upstart: It's a great way to learn Upstart! - Consider having an online sprint to concentrate on this activity for a few days(?) - Identify individuals who can help out when questions arise (jamesodhunt, spamaps, vorlon, etc?) - Leverage the work done in Fedora to migrate away from SystemV. - Concentrate on the most popular services first. - Review all Upstart jobs. - Thorough testing required. = Questions = - Aside from time, what is slowing down the conversion activity?:   - lack of examples? (We can blog and provide wiki examples)   - lack of familiarity with upstart job syntax? (We can hold education sessions)   - lack of ability to test the Upstart job versus the SysV service? (QA may be able to help here?)   - concerns over migration to "alternative init systems"? (there are no plans to switch)   - other? = See Also = https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-upstart-convert-main-initd-to-jobs (*) - this number has fallen from the 122 SysV services in natty, so the number is falling slowly :)

Python plans for 12.04 LTS: Python 3.2 and 2.7 only. We dropped 3.1 in Oneiric and 2.6 in Precise. For 12.04 the goal is at least one desktop application destined for the default installation (i.e. CD images) to be ported to Python 3. Long term (14.04 LTS), we want Python 3.2 only on the CD, with 2.7 still available in main.

During Ubuntu installation or oem-config firstboot, if a network is present then add an additional step in the workflow to either enter Ubuntu One credentials or to sign up for a free account.

tpm-tools is an important feature in the enterprise from secure boot to 802.1x network authentication.

Build a crash database for Ubuntu. Quoting Matthew: Microsoft, Apple, and Mozilla have dedicated crash tracking systems, separate from their bug trackers. This has multiple benefits, when compared with Launchpad and apport: - people don't need a sign-on account, of any sort, to report crashes - developers aren't spammed with e-mail notifications about duplicate crashes - non-developers aren't spammed with e-mail they don't understand after reporting crashes - the error message, explaining that a window just disappeared because the application crashed, appears in release versions of the software -- not just alphas and betas - contributors can easily see which are the most common causes of crashes - contributors can easily see how reliable their software is compared with previous versions. For these reasons, Ubuntu should have an error tracker too. Overview of crash reporters: http://en.wikipedia.org/wiki/Crash_reporter Public statistics from Mozilla: https://crash-stats.mozilla.com/products/Firefox Previous blueprint: https://blueprints.launchpad.net/ubuntu/+spec/crash-tracker Previous blueprint: https://launchpad.net/ubuntu/+spec/crash-reporting

= Summary = We have lots of ideas for changes we'd like to make to Upstart this cycle. This blueprint will outline those features at a relatively high level. Ideas (highly incomplete list currently): - Fully segregated SystemV / Upstart system shutdown - Introduce "setuid" and "setgid" stanzas to allow jobs to run as a different user/group. - Enable user jobs (a simple change to a dbus config file). = Desired Outcome = - A better understanding of those Upstart features you'd like us to work on - A feel for the relative importance of each feature which we'll factor into our plans to allow us to prioritise the work.

There are two big topics to discuss in this session: - Fixing the way we handle /etc/resolv.conf to be consistent across the whole distro - Integrate a DNS resolver daemon in the default Ubuntu desktop installation == The notes below are about including a local resolver in the default Ubuntu Desktop installation == The idea is to have a local resolver like dnsmasq or unbound running on all Ubuntu desktop installations and controlled by Network Manager. All machines would then use "nameserver 127.0.0.1" in their /etc/resolv.conf search path/domain may be retained in resolv.conf or moved into dnsmasq/unbound's configuration too. The main benefit of doing this is to increase overall responsiveness of the desktop by having a local DNS cache and allow for better dispatching of DNS queries. For example in the following scenario: - Wired connection with DNS 1.1.1.1 and domain blah.com - Wireless connection with DNS 2001::2 and domain example.com - VPN connection with DNS 2.2.2.2 and domain ubuntu.com With current Network Manager, all DNS queries would be going to 2.2.2.2, making everything slow if the latency on that link is high. Also, any request to blah.com or example.com will be sent to 2.2.2.2 which doesn't necessarily know these domains (if they are internal domains for example). The resolver will fix all that by sending DNS queries to the right server depending on the domain, will cache the results and will properly handle timeouts and detection of broken server, thereby reducing delays and reliability of DNS on Ubuntu.

Despite current efforts Ubuntu still receives lots of bug reports without a package. These bugs are may be about serious issues in Ubuntu and are unlikely to be triaged. Using launchpadlib and text processing is it possible to determine what packages these bugs may be about? Are there other ways to determine the right package for them?

Present current state of OpenJDK on ARM for the p-series

Arkose has been entirely rewritten over the past 6 months and a lot of new features have been implemented. During this session, I'd like to talk about the next set of improvements for Arkose and where it can and should be integrated with the distro. Amongst changes I think are worth discussing in this session are:  - Supporting two different "backends", apparmor and LXC  - Offering a better run time experience for users of the wrapper  - Discussing how we want to ship the profiles  - Extend the profile format to include more fine grained options: cgroup options, firewalling rules, ...  - Use Arkose to start GUI packages from older version of Ubuntu - Allow spawning commands in an existing container, allowing to save some resources in some cases Other planned upstream changes:  - Improve the CLI tool to match the features supported by the python module  - Split the python module into plugins helping reduce the number of dependencies of arkose itself

As proposed in http://netsplit.com/2011/09/08/new-ubuntu-release-process/, we should create an unpublished release pocket that stands as the gateway to the regular development branch. From this branch unit tests will be run, code review and sign off will be checked, system integration tests will be run, and if any of these fail, the upload will not be copied to the development branch. We should unpack and run the unit tests for any reverse dependencies of the core libraries during package build in order to prevent breaking said dependencies with a dodgy upload. For example, an upload of GTK+ should trigger the unit tests for ubiquity and software-center to be run.

During 12.04 development we will strive to ensure that Ubuntu Desktop works each day so that everyone can reasonably make progress with their development goals, rather than being blocked by poor quality in different areas of the product. The flow as I envision it would go: 1. The ISO is testing in the morning for Europe 2. If the ISO is found to be acceptable, the QA reports such 3. If the ISO is found to be hard to use or test, the QA team reports as such 4. Ubuntu Engineering then investigates which package caused the breakage 5. The package that caused the ISO Is reverted 6. The ISO is rebuilt and step 1 starts again

Plan the enhancements we want in apt for precise

Prepare for the lucid -> precise LTS upgrade * testing * backporting apt from oneiric/precise to lucid for multiarch enabled upgrades * dpkg-maintscript-helper not available in lucid, used in preinst scripts: need some archive analysis to catch these issues and make sure they won't impact upgrades

Investigate whether we can work around the problems of not being able to retrace core dumps on the local system and ASLR making generating an accurate retrace without function names difficult. Being able to create a stack trace with just addresses would allow us to submit that small chunk of data to the crash database before sending the full data set. The crash database could then decide if this crash already exists or if it needs the full core dump so that it can create a new crash bucket with that retraced. Google's Breakpad is able to do this through Microsoft's Minidump format. We may be able to mimic this behavior in apport without having to link every application to Breakpad.

Discussion around Java related objectives for Precise:  - OpenJDK 7 and when to switch the default-jdk in Ubuntu  - General Java housekeeping - Maven 3 progress and transition

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS.  * What is the best way to distribute the updated X stack?  * Will this be an opt-in change for upgraders? If so, how will the upgrader need to be changed to properly guide the user in making a choice?  * For consistency, what version naming scheme should be used for these package updates?  * Should we limit it to just the serverside portion of the X stack? (I.e. omit libX11, etc. to avoid breakage to client apps) * For certain graphics cards, there is a possibility that driver support could be dropped in future kernel and X combinations; the upgrader will need to be aware of this and not suggest the upgrade if it won't work, or perhaps make them aware of the risks or known-regressions they'll endure if they wish to proceed anyway.  * Should a way be provided to enable the user to back out the changes? If so, how should that be implemented?  * How tightly should the kernel / X package versions be kept? I.e. should we discourage or permit old-kernel/new-X and/or new-kernel/old-X setups. (If we permit these combinations it gives user flexibility but imposes a larger testing impact).

Integration of DEP5 and SPDX into our packaging process for the generation of machine readable COPYING or LICENSE files for improved analysis of the licensing and copyright issues when releasing Ubuntu and derivative products.

A bit of work has been done late in the Oneiric cycle to improve friendly recovery to work better. Now with the LTS coming up, it's time to fix some of the bigger issues for good and make sure the recovery mode will be useful and working for everyone. Things to discuss include: - Dealing with udev so important devices are initialized in recovery mode - Properly initialize the network, either by using ifupdown or Network Manager - Update the plugins to work properly when network isn't available and give a clue to the user that they need to enable network

The QA tracker at http://iso.qa.ubuntu.com has been around for quite a while now. It's in desperate need of some small changes to better work with the amount of testing Ubuntu requires nowadays. This session is meant to discuss what are the most important changes we need to make the tracker work better for the LTS. These changes should ideally be implementable very quickly as the tracker starts being used for the first alpha.

It's expected this cycle that Multiarch will provide superior 32-bit compatibility for any packages that previously required ia32-libs, as well as a scalable way to add compatibility for other libraries going forward, removing one of the main pain points for running 64-bit by default. Adobe has just released a supported 64-bit version of flashplugin, removing one of the main causes for users to need 32-bit compatibility on Linux anyway. At the same time, the availability of UEFI only on our 64-bit images gives another compelling argument for running 64-bit instead of 32-bit, offering features like a fast UEFI boot instead of a slow BIOS POST and possibly secure boot capabilities (or possibly, the need to use UEFI to be bootable at all on certain secureboot-enabled hardware). Should we switch to promoting 64-bit ISOs by default for 12.04 (on the website, in pressings, etc)? What other blockers remain?

Care has been taken over the years to ensure that clicking a link to an executable on a website doesn't cause untrusted code to be run, and that all package downloads from the Ubuntu archive and from PPAs can be done securely. But lots of community and third-party documentation directs users to download unsigned .debs from websites and install them, and software center facilitates this. We need to examine the security around third-party packages.

In what ways can we improve Upstart from an administrators perspective? What would make sysadmin's lives easier? - custom actions [e.g. status, force-reload, try-restart] - programmatic enabling/disabling of services - improved logging - serialized/interactive boot - suggested new common events? (see `man upstart-events` for current examples) - ability to list "services which will start on boot" - fixing LP bug: 406397 would make writing/testing new jobs easier See last cycle's blueprint for reference: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-upstart-for-admins

Every LTS we're confronted with the Python upgrade story. This is made difficult because there is usually no overlap in Python versions from LTS to LTS. Not that we've ever come up with a very satisfactory solution before, but let's at least discuss it again since if there is anything we can do, 12.04 is probably a good time to do it. Just to remind us: since there will never be a 2.8, we only have to worry about Python 3. (Doubtful we'd remove Python 2.7 from main any time soon.) Python 3.3 is slated for after 12.04, and it will only be in alpha during this cycle, which is probably in too much flux to put it in this LTS. Extrapolating out, I think it's possible we'd see a Python 3.4 just before 14.04.

Similar to the IPv6 session we had in Budapest. Discuss what changed in Oneiric and what we want to focus on for Precise. Things to discuss at least include: - New ifupdown supporting dhcpv6 - Testing our most important server and client packages for IPv6 support - Status of IPv6 support for Ubuntu core services like archive.ubuntu.com, archive.canonical.com, ntp.ubuntu.com, geoip.ubuntu.com, ... so we can have a perfectly working install in an IPv6 only environment - Privacy extensions - Dual-stack DHCP server support