We would like to have a discussion about providing better integration between Xen and Ubuntu.

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.

Our current SRU process is perhaps slightly over-engineered as a reaction to the fact that out previous SRU process was almost certainly far too lightweight. While there's (I hope obvious to all) value in documentation, audit trails, regression testing, and "bake-in" periods, our current process makes it somewhat difficult to get urgent fixes out quickly, while also discouraging the casual observer with an "obviously-correct" 2-character patch from making contributions to stable releases. We don't want to throw the babies out with the bathwater here, but we need to discuss ways we can make the process more agile while still keeping it robust enough to avoid making serious mistakes along the way.

The biannual catch-all X discussion session. If you are involved in a project that directly depends on the X stack, or needs a particular feature from the stack, come along.

The Ubuntu archive administration team has always required direct privileged shell access to the ftpmaster system in order to perform many of its routine tasks. This is a security problem, it prevents us from opening some tasks up to those who are not Canonical employees, and it makes it hard for us to improve our own tools. Improve the Launchpad API to handle all our requirements and write suitable API clients. We will know we have succeeded when archive admins no longer require shell access to do their jobs.

Rationale: We have lots and lots of bugs filed on a daily basis, bugs that could, given a set of heuristics, be automatically triaged. By triaged we mean flagged as important/unimportant. We want to do that with some level of certainty, to avoid missing important reports but removing the need of manually triaging every single bug filed against Ubuntu packages. Goal: Have a script or a set of scripts that automatically do the first round of triage, removing useless or not likely to be useful bug reports, and raising the priority of the potential issues whenever they happen. Remove the need of worrying about triaging all bugs and let us focus on fixing the important ones.

Growing the amount of charms in the charm store

Discussion during UDS-Q on the further plans and development for summit.ubuntu.com

During the Q cycle, the certification team will have a number of routine duties to perform - Weekly testing to check that tools are working correctly (while also aiming to discover some hardware related bugs in Ubuntu) - Milestone testing, which should be more thorough than weekly testing, in order to catch more bugs and raise them with the appropriate parties as soon as possible. - Certification testing, at the end of the cycle to determine whether systems can be certified or not. The purpose of this blueprint is to think about what changes can be made to these processes, in order to do better certification. = Functional coverage = Some new hardware is becoming commonplace and we should be including it in our certification coverage, at least to the extent that we test it and if it fails we report that about the system: Functional coverage usually takes a good hour, so this will be discussed in a separate session. - Accelerometers should be included as a greylist item - USB 3.0 should be included as a greylist item (meaning that USB 3.0 devices need to be tested against the USB 3.0 port) - 3G/WWAN modems should be included as a greylist item - Touchscreens multitouch should be considered for inclusion as a greylist item - HDMI audio should be included as a greylist item - Considering adding Super-key testing (i.e. launcher shortcut) to spec and backport to 12.04.1 = Process = == 12.10 kernel in 12.04 LTS testing == From 12.10 onwards, changes to the kernel and some other closely linked packages such as X will be tested to work on the LTS (12.04) during the development cycle. This means that systems scheduled to be certified with 12.10 will be also tested on 12.04 LTS with the 12.10 backport, to ensure that nothing breaks. Also, this means that we will need to make changes to the certification site (both public and internal) to be able to distinguish a system certified with 12.04 kernel, or with 12.04 with a backported kernel. Strictly speaking this would double the testing effort required by the certification team, since each system would have to be tested with each kernel in combination with the 12.04 userspace and 12.10 userspace. One method of doing this would be to change the test infrastructure so that a 12.04 test run is done immediately after the 12.10 one is completed. == Weekly testing == At the moment weekly testing is performed on a subset of about 25 systems available in the certification labs. A tool is used to try and get the best hardware coverage possible on this small set of systems (by not including multiple systems with the same GPU or Wireless card for example). The main purpose is to identify when the testing tools break, but issues with Ubuntu itself may be uncovered as well. For this reason an automated run is done (no manual testing), which means that some issues may not be detected. This mostly works well, but improvements may be made to better detect regressions in the tools (there were one or two cases in the last cycle where problems went unnoticed for some time). For example, the status of some tests changed from passing, to being skipped due to changes in the internal working of Checkbox. Since they weren't appearing as failures this wasn't picked up. This could be achieved by having a method that compares two subsequent week results, and reports on things that might have changed. Testing of the 12.10 kernel in 12.04 will also have to be included in the weekly testing process. It might be necessary to test them bi-weekly if a good method for integrating them with the normal test run cannot be found. == Milestone testing == Testing at release milestones is performed on the same systems as weekly testing, but instead of only doing a fully automated run, manual testing is performed as well. This means that any issues which would block certification will be detected, assuming they exist on the systems in the test pool. Last cycle it was found that some systems which weren't included in the test pool had very critical failures caused by a driver for a component not covered by certification (IR reciever). We would not like to have to test on every system at every milestone, but at the same time we'd like to be able to detect issues like this earlier, which can only really be achieved by a full test run. Some sort of comprimise may be possible. Because systems will need to be tested manually at milestones, the technique described above for handling the 12.10 kernel in 12.04 LTS described above will probably not be suitable. == ARM Certification == It is already known that the Certification testing tools (mainly Checkbox) are mostly not working on ARM devices. Since some ARM certification testing may be necessary during the Q cycle we need to achieve a baseline of usability so that Checkbox can be adapted to testing a specific ARM based product. This will be defined as the ability for Checkbox to submit hardware information and a basic set of test results.

We want to make the Ubuntu LoCo portal a hub for social LoCo activities. This blueprint proposes the redesign of the portal's homepage to more effectively showcase LoCo team activity and to inspire community members.

Currently, dpkg is aware of which files in a package are conffiles, the conffiles checksums and where those conffiles live on the system once the package is installed. However, there are problems: (1) What if the user modifies a conffile incorrectly such that the service no longer starts or behaves erratically? (2) What if the user modifies an Upstart job conffile such that the system no longer boots?       (This is the same problem as (1) but results in a significantly worse outcome!) (3) What if the user cannot remember what changes they made to invalidate the conffile (and forgot to backup the unmodified conffile)? There are many facilities available to help with (3) including version-control systems and configuration management systems. However, the default Ubuntu system should have a *simple* way to mitigate some of the problem scenarios. The proposal is to modify dpkg either directly or by way of triggers such that every conffile is installed as normal but an additional copy of the conffile is placed in /etc/pristine/ (or some sub-directory). The files will all be given the same owner+group as the corresponding original conffile but permissions will be set to 0440 to discourage inadvertent modification. This gives the following benefits: (a) Problem (1) can be solved easily since the user can use diff(1) to compare their modified conffile with the pristine version      in /etc/pristine/. (b) Problem (2) can be solved in the same way as Problem (1), but there is some extra magic available to help the user: If they have modified /etc/init/*.conf directly, or even created /etc/init/*.override files to modify the .conf file indirectly, we could add a new boot option that would invoke Upstart like this: init --confdir /etc/pristine/init/ --startup-event=emergency-boot --no-log --no-sessions --debug Doing this would ensure that the system will boot *using the pristine conffiles* installed in /etc/pristine/init/ rather than the potentially corrupted /etc/init/*.conf files. We could then start a job based on the 'emergency-boot' event that would guide the user to restoring their system to a normally booting one. We could just show the user which job files/override files they have changed by date and offer to revert the changes but there are a few possibilities. We could even warn the user if they leave /etc/init/ in a condition different from /etc/pristine/init/ but the expectation is that at the end of the recovery process, all future boots will behave as expected. (c) By having a pristine copy of each conffile of the system, it would also be possible to provide 3-way merge facilities in the future when dpkg could show the user the following on package upgrade: - the locally modified conffile - the local pristine version of the conffile - the new about-to-be-installed pristine conffile The costs of creating /etc/pristine/: - Extra disk space consumed Taking two 12.04 systems as examples: package count: 1751 size of conffiles: 11M package count: 4041 size of conffiles: 16M A basic desktop install would show slightly lower figures, but these numbers are significant enough that we might want to audit the conffiles in a default install to consider a strategy. For example, for the first system above, of the top 15 largest conffiles, 8 come from the 'brltty' package and those 8 files account for 20% of the total conffile size (2.2M). Additional information/thoughts: - FreeBSD already retains pristine copies of key system configuration files in /etc/defaults/. Using this name though could be confusing to Ubuntu users where /etc/default/ is used to store files that are *intended* to be modified. - What about the 'ucf' ("Update Configuration File") and 'etckeeper' packages? - Might be helpful to create /etc/pristine/README with a couple of lines of description?

The Canonical upstream teams did some good progresses on testing and quality this cycle, that's a good step for the Ubuntu Desktop quality, we still rely on quite some components from other upstreams though that didn't engage into a such process yet though (those who looked at gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably know what I mean there). I would like to see if we can work on our side and with upstream to get those automated tested in some ways. It would be also nice to see regular run and report of the testsuits for other components which already have one (i.e glib, gtk) and some testing of their rdepends before upload.

This is not the DMB Meeting (that'll be a private meeting). Topics: * Setting reasonable expectations to applicants   - Some sort of self test?   - Documentation on our requirements from endorsers? * Disentangling membership from PPU. * Expiring PPU rights. * Periodic upload rights review? * Meeting length. How can we get through applicants faster.

We'll talk about amateur radio, and promoting Ubuntu-hams. In particular, there is interest in using gnuradio with some of the TV receiver USB dongles which are supported.

Mark Shuttleworth announced (a while ago for 11.04) that Canonical would leverage Qt more, and subs equently Qt is found in important parts of Ubuntu like Ubuntu One. Being a relatively new kid on the block, Unity has its work cut out for outreach to existing developers of both Qt and Gnome/Gtk+ interfaces. Without coordination and documentation the advantages of this delicate balance of legacy interface development and ermerging Unity technology are lost. In simple terms, this blueprint serves to consider and unify developers' goals and ideas concerning Unity and legacy Qt and Gnome/Gtk+ bindings. Deliverables could include a wiki page for easy to understand development information applicable to both APIs.

Including tests within each charm

In this session, we'll discuss eCryptfs in Ubuntu 12.10. Both of the upstream eCryptfs maintainers will be present to discuss the future of eCryptfs, upstream and in Ubuntu. Topics include:  - Stabilization and testing with the new unit test framework  - AES-NI acceleration improvements  - Longstanding issues or bugs that need to be revisited  - Steps to removing the "experimental" label in the upstream Linux kernel tree  - Remote key retrieval in the ecryptfs-utils userspace packages  - Introduction of ecryptfs.org  - Migration of questions/answers from Launchpad Answers to StackExchange sites - Problems around the ecryptfs-utils prerm check of if ecryptfs is in use  - ...

Our usual LXC discussion at UDS so we get back home with plenty of container related action items.

Feedback on the results of the experiments we tried in precise. What worked, didn't, what we want to keep going forward.