The $XDG_RUNTIME_DIR fd.o spec has received criticism on the FHS mailing list due to implementation bugs that allow non-root users to DoS the /run directory. Discuss what's required for a solution in Ubuntu.

Testing strategies for user-space testing of the network stack (network manager, etc).

Plans for the software-center client

Talk about backports, including joining the backports team.

A discussion of the use of GStreamer in Ubuntu TV taking into account any existing third-party GStreamer sources and sinks.

We need to start thinking about (and working on) the aarch64/arm64 port in Debian and Ubuntu, this spec should ultimately list what we know, what we need to know, what we need to be working on, how, and when.

A round table discussion around MySQL in Ubuntu.

Rationale: Multiple teams are working on reports using .json files obtained from Arsenal. We're looking for a better way to maintain a stateful, historical bug database without stressing the launchpad server. Goal: Agree in a way of persisting launchpad data "locally", being that the source of data for reports. Implement that.

Tasks from daily community roundtable sessions

Things needing changed to keep everyone happy and friendly in the future for kubuntu

A round table discussion around MySQL in Ubuntu.

List of features and improvements for the Firmware Test Suite for Ubuntu 12.10

This session is to discuss providing object storage in OpenStack deployments with ceph. The blueprint is used for tracking work needed to be done in order to accomplish this. This includes charms, relevant packaging, and testing needed.

Hey, Not sure how much we need to discuss but it's always good to have a GNOME checkpoint session. It's likely that this cycle we will not "hold back" on things we kept behind until now, which means we need to bring clutter on the CD and see how we do that and what it means (do we need extra testing on some platforms during the cycle, how will it work for people not having 3d working, etc). Some other desktopish topics I would like to discuss, not sure if that's the right session but since we will probably have time in that one: - our delta with upstream and Debian and how we could lower it? mpt suggested that "launchpad-integration" items are quite "geeky", they also create most of our diff over Debian and extra work and don't really "scale" since they require sources patching, maybe it's time to discussion dropping that? - tools, though UDD didn't change a lot so I don't think the consensus will be any different from what it was other cycles - whatever other topics you guys come with ;-)

This specification is to plan the work of the Ubuntu Accomplishments releases over the coming release cycle. Goals discussed so far include: * Maturing our API. you can see a list of these goals at https://wiki.ubuntu.com/Accomplishments/NewAPI * Getting Local Accomplishments support to a level of quality that matches Global Accomplishments. * Expanding our help and guidance for how to get started using the system. Please join the session, particularly if you are interested in contributing to the project.

The Packaging Guide has seen a lot of changes and improvements of the past few cycles. Let's keep this momentum going and discuss next steps.

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.

Running LibreOffice 3.6 testsuites on Ubuntu Q for continuous integration.

We want to increase the visibility and awareness of Ubuntu app development outside of the regular Ubuntu channels. This blueprint will serve to discuss initiatives and plan an external outreach campaign. One of the first initiatives will be a series of articles published to a set of targetted media sites or print publications not directly associated with Ubuntu.

Robbie Williamson

External testing, that is, the testing performed outside of Canonical certification labs, is a significant part of all the testing activities around Ubuntu that is growing on every cycle. It is becoming more common that people outside the certification team want to run our certification tools and tests, to either submit results to Friendly, test their systems, or check if a system would pass certification. As part of the continuous improvement practices currently in place, the certification team will focus on enhancing the user experience for external testers for both desktop and server, so that they can run test cases with the maximum coverage (both for hardware and software) and report problems effectively. The areas that have been identified to work on during the next cycle are the following ones: == Test case usability improvement == Some test cases executed internally in the laboratory assume the presence of devices and configurations needed to run them smoothly. Unfortunately, when these test cases are executed in a different environment, they fail and cannot be used unless all the prerequisites are properly fulfilled. * We need to take into account that for the external whitelist is going to be run outside the lab, so we cannot make assumptions on configuration * Automate as much as possible to get rid of any assumption and also run the test cases on any system that matches a minimal set of requirements. * Provide guidelines either in the documentation or the test case description to configure the environment properly when full automation isn't attainable. * Improve general usability of the testcases, to allow people less familiar with the tools, to run the test suite without having to ask questions. == Documentation == Documentation is intended to solve any doubt that could prevent a testing session from finishing properly with the submission of results and the reporting of the problems found. * Create a document that describes the procedure to run test cases using the external whitelist in a desktop. * Update the document for the server that was created in the previous cycle. This includes, for example, adding a section about how to troubleshoot problems. For instance, what to do if a test case doesn't work as expected, the test results cannot be submitted, etc. * Create training material for TAMs and customers, so that they can get some hands-on experience before certifying a device for a given release for the first time. * Provide guidelines either in the documentation or the test case description to configure the environment properly when full automation isn't attainable. == Whitelist coverage == The different set of test cases between the internal and the external whitelist, causes that the coverage achieved depends on the whitelist executed when it shouldn't be the case. * Review both whitelists and make sure that they provide the same amount of coverage. * When the improvements on test case automation aren't enough to get the desired coverage, create alternative and easy to configure test cases that can be used to test the same capability/feature in a different environment. == User interface usability == The new Qt interface is a step forward in terms of having a modern interface that looks appealing to users. However, we have to make sure that it lives up to the expectations of testers. * Review the interactions required to run test cases and solve any issue that prevents the tester from having a good experience that encourages collaboration and makes reporting problems easy. For example, look at the consistency of buttons when marking a test cases as passed/failed/skipped.

How often does the installation fail? How do we know which language packs to include on the CDs? What hardware is suspend and resume still not working on?

Hands on help with Launchpad bugs and getting involved in contributing to Launchpad

All development work items for Lubuntu 12.10

GlusterFS 3.3 brings significant improvements in the cloud area, with better support for VM image storage, as well as object storage and an HDFS compatibility library. We think this release will be useful for OpenStack deployments, and we'd like to create an integrated stack that utilizes GlusterFS - both for object storage (Swift interface) and VM image storage.

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.

We had tried to get some shortcut changes during the Precise cycle. Some successfully, some were not (like changing the "change worspace " keybindings). I propose a healthy check session/discussion with the design team to see what changes will be done for 12.10, what we need to expose on gnome-control-center, reviewing what we already expose there. Also, what changes are needed on the window manager side to propose more than one (configurable) keybinding to not break past conventions with new proposed ones.

= Summary = The Desktop Team have a requirement for Multiseat support. Currently, ConsoleKit is used to handle sessions but has issues: - it's apparently unmaintained - requires $XDG_SESSION_COOKIE. Fedora now uses a facility called 'logind' which replaces ConsoleKit and uses cgroups and PAM to provide X session and terminal session and seat management. This session is to: (1) Discuss the plan regarding either making use of logind, updating ConsoleKit or writing our own tool. (2) Identify a list of requirements on a ConsoleKit successor. = References = - http://www.x.org/wiki/Development/Documentation/Multiseat - http://www.freedesktop.org/wiki/Software/ConsoleKit

This thread proposes a release process for Juju: https://lists.ubuntu.com/archives/juju/2012-April/001431.html The basics: * Keep it simple * 6 weeks of open trunk * 1 week of stabilization * 1 week of testing/critical fixing reserved * Aim to drop releases before FeatureFreeze in Ubuntu * Release series minor version bumped if backward incompatible changes are made * Semantic versions adopted (starting at 0.5.0 which is the version of juju in lp:juju when release process starts)

Identify which APIs need to be documented for application developers and ways in which we can provide these APIs in a developer friendly way

There are currently some issues changing password in Ubuntu using a simple one. On the other end, we are introducing devices with a different type of security and input. The purpose of this session is to discuss the current issue in Ubuntu Desktop and brainstorm solution for new form factors and if and how these can be linked.

This blueprint is to discuss the work need to add MySQL Utilities package to Debian and Ubuntu.

The installer slideshows for *buntu 12.04 worked out great, and with an LTS behind us now is a great opportunity to take a breath and look around. It's time to think back to what has gone well over the last few releases, and what we can improve. There are lots of different slideshow projects built in to one, so it would be great if we can all put our heads together and get a feel for the effort as a whole — where this is working and where it isn't. So, if you happen to be reponsible for one of the many installer slideshows, please drop by! With this session, we're going to plan for the next few releases and, hopefully, we can build a sturdier project structure than we have had for the past few releases. This is also an opportunity to think about more elaborate, project-wide features such as screenshot localization, and better localization in general.

Plans for the software-center server

Discussing options for improving manual testing, metrics, and user feedback for those running the development version of ubuntu

USB video devices (DisplayLink, among others) are technically supported by the Ubuntu X stack, but in practice are difficult to set up and finicky. What are the important use-cases for USB video, and can we make them less painful?

Mozilla SUMO is the product that powers support.mozilla.org and we are aiming to transition help.ubuntu.com in its entirety to SUMO in the Q-Cycle or at the very least get excellent work done towards that goal.

Déjà Dup Backup Tool has some ambitious long-term changes. This is a discussion of what we can do this cycle, what people can do to help, and feedback about both the current state and planned changes.

It was originally planned to have a plenary session at UDS to show some of the improvements that happened to LXC and containers in general over the past cycle. Unfortunately, the schedule being already full, this plenary won't happen. I'd appreciate if this session could be scheduled early in the week and before the actual LXC session. Here's the agenda for this session: - Quick introduction to LXC and containers - Presentation of the current features and what was added during the 12.04 cycle - Some use cases for containers for developers and in a production environment - A demo of Ubuntu 12.04's LXC - Q&A and open discussion This session is aimed at anyone with an interest in LXC and containers. During the session you should learn enough to start using LXC in your everyday work. Ideas resulting from the Q&A and open discussion part of this session will be added to the other LXC session later in the week where we'll define the final roadmap for 12.10.

We should review all our charm processes and make sure they are low-barrier. We also need to figure out github integration.

Accomplishing an awesome app developer community

QML/Qt5 in use, example discussion, graphical effects, etc.

The charm store has only been around for one release, so we're still learning how it relates to releases of Ubuntu. Also the LTS is likely a desired target for the next 2 years for conservative users. Topics: * When do we advance the charms dev focus to each new release of Ubuntu * Should we auto backport and forward port charms, if so, how?

OpenLDAP's new MDB library provides basically unlimited scaling for reads, high speed writes, and extremely efficient memory use. It has already been ported into a full OpenLDAP backend, a Cyrus SASL sasldb backend, a Heimdal hdb backend, and an SQLite backend with dramatic resource savings and performance gains yielded in each case. Work is also underway to provide a perl DB module, and other projects such as OpenDKIM are now adopting it. With the prevalence of apps dependent on SQLite in Android and other mobile platforms, and the order of magnitude efficiency gains from MDB, the potential for battery savings and extended runtimes on mobile devices is significant. What other apps/tools should we explore for MDB adoption?

Discussing ways to integrate the ubuntu friendly database for testing needs. -Creating a testing hardware database for targeted testing -Identifying and communicating with people with specific hardware for iso testing, feature testing, and hardware enablement and/or bug fixing -Make available the testing pool/results to developers (upstreams?)

Review of the current Ubuntu Kernel patch delta from upstream. This session will look at the current delta comprised of both patches to the core and the ubuntu specific drivers. The aim is to record what we are carrying, review the reasons for that component(s) to be carried, and recommend replacements, updates, cleanups, upstreaming etc of those components.

Continuation of Monday's session. Solving design problems together.

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.

Started during the P cycle, the Developer Advisory Team has been reaching to development contributors and while things have worked out quite well, there are surely things we can improve. https://wiki.ubuntu.com/DeveloperAdvisoryTeam Agenda: - team meetings - outreach - improve feedback collection process - get notified about contributor status changes (active→inactive, new→experienced) - following up with contributors who don't reply - avoiding trello craziness

= Summary = General discussion on the direction Upstart is heading in. = Ideas = - interactive boot. - full Upstart and SysV segregation (+ Upstart controlled shutdown). - event log for problem determination. - 'initctl kill <signal> <job>' - enabling user jobs. - introducing user job logging. - mountall plans. - custom actions. - cron replacement. - conditional start/stop on condition, based on whether a particular job is available for. Examples being:   - dovecot+postfix   - nis+autofs - ...? = References = - https://wiki.ubuntu.com/Upstart/Ideas - https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033402.html - https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html = Blueprints = - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-service-readiness - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-for-admins - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-convert-main-initd-to-jobs - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-roadmap

Sound settings redesign review and discussion around further improvements and limitations of current implementation.

Get more app developers talking about Ubuntu and targeting Ubuntu. Promote Ubuntu as a platform in the places independent app developers socialize.

Upstart currently considers a service "ready" (fully initialised) once: - [Services] The process has forked the expected number of times (0-2) - [Tasks] The process has been exec'd successfully For daemons therefore, "service readiness" is inextricably linked to the overloaded 'expect' stanza which is also used for PID tracking. The problem is that some services (such as cups) are _not_ ready once they have forked 'n' times. The proposal is to introduce a new 'ready on' stanza coupled with a 'ready' event that would allow explicit control over when Upstart deems a service to be in a usable state: http://people.canonical.com/~jhunt/blueprints/upstart-service-readiness-table.html Summary: - No change to existing 'expect' behaviour. - If no 'ready on' condition specified, 'ready' event emitted immediately   after 'started'. - If 'ready on' condition specified, 'ready' event emitted if and when   condition becomes true. - 'ready' event can optionally be used by other services as a more   reliable way to know when a service is fully initialized and thus usable. Observations: - possible to specify multiple values in 'ready on' condition such as:   "ready on (dbus NAME=org.bar.foo and file FPATH=/var/log/myapp.log and socket PROTO=inet PORT=80"   "ready on stopped myjob and started myjob2" - upstart-socket-bridge will be retained but with advent of (C), no   longer necessary to modify any daemons as is required by systemd for   "socket activation". Advantages: - No change to existing 'expect' behaviour. - Solves the readiness problem since .conf files would have a rich   palette of sources of readiness to choose from which should cover 99%   of all cases (udev, dbus, file, socket). - More reliable behaviour. - Would allow for simplification for jobs that currently fail to work   solely via ptrace (for example, see gross hacks in /etc/init/cups.conf). Work required: - Finish (C). - Implement (D) and (E). - Modify upstart-udev-bridge to look at "ready on" job stanzas to allow   "ready on <udev-event>". Concerns: - (D) would need to be accepted into the upstream kernel. - (D) would not currently work in LXC containers since netlink is effectively disabled (as it is not namespace-aware). Correct fix would presumably be to make netlink ns-aware? - (D) ties this feature to Linux rather heavily   (*could* provide a very crude /proc/net/{tcp,udp} implementation but   performance would be poor as file must be continually re-read!) - (C) would need to use inotify (or fsnotify to avoid complexities to overcome racy behaviour for inotify recursive watches) but could be ported to other architectures   (such as FreeBSD using kqueue). ---------------------------------- Alternative idea (from apw): put the onus on the daemons to inform Upstart when they are ready. This is in fact already possible using 'expect stop' where Upstart waits for the application to send SIGSTOP before considering it ready. It could be extended to obtain the PID directly via sigaction(2) to avoid the need to obtain it via ptrace(2). Could go a stage further and provide some sort of formal API rather than a signal to allow a daemon to indicate readiness (coupled with a utility command to do the same). Advantages: + simple. + puts onus on daemons rather than Upstart. + potentially removes the need to use ptrace for PID tracking. + if the API idea were selected, this could be used with SysV jobs too (by providing a NOP implementation for the traditional SysV init). + no kernel support required (so would map across to other systems (BSD/Hurd if desirable). + could be standardized as part of the LSB since it would be init-system-agnostic. Disadvantages: - daemons may ignore the standard behaviour. - we would need to modify every daemon in the archive to work with this model. - highly unlikely that commercial vendors would modify their products unless it were an approved standard. - putting control in the hands of the daemons is not necessarily desirable: consider if they go haywire - Upstart would not be able to control the problem as it may not yet know the PID.

(maintaining and reviewing charms)

This blueprint is just a placeholder for scheduling purporses. For the description please go to: https://blueprints.launchpad.net/certify-planning/+spec/cert-q-external-testing

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.

Figure out the most important use-cases for using Upstart in the desktop session and what requirements this puts on Upstart to verify whether it can start to be used for the desktop session in 12.10.

To use their evaluation builds on different ARM architectures Linaro creates so called hardware packs which contain board specific bits like kernel, bootloader and drivers. The Ubuntu infrastructure currently uses debian-cd in the backend to make images bootable on ARM boards. In 12.10 we want to remove this duplicated effort and teach debian-cd about hwpacks from linaro so that it can make use of them for certain (if not all) ARM targeted images in the future. In the session going along with this spec we will have to discuss the necessary changes to debian-cd but also possibly required changes to the hwpacks (we might want to use a long term supported kernel for example or can not distribute drivers legally in a community distro which linaro includes in their builds with approval from the vendor etc.)

Application startup time is unnecessarily slow in a large number of instances. Can we see some improvement in that area in the Q cycle? The price of RAM has dropped dramatically, and usage has not increased all that much. Can't we use it for something when it's available? We now have Zeitgeist. This means we can know what users will do after login. It's possible to tell not only what applications will be started, but also what files will be used. In many cases, there's only a single human user in the system. I would really like it if I could set my work desktop to boot automatically in the morning, and it'd load my stuff into RAM while waiting for me to log in. There's also a few websites I always check first thing while I have my first cup of coffee. Load them too so I don't have to wait for it. I'm the only human user on my desktop, so why not log me in automatically, but in the background, keeping the login screen as it is? To my mind, these are all attainable goals: * Sub-second login * Instant loading of frequently used applications * Zero-delay access to most frequently used websites. Everyone is telling me to go buy a fast SSD. But that's expensive and in my case, it doesn't provide any benefits that can't be achieved by software. RAM is extremely cheap, and much faster than any SSD on the market. What currently happens is that the login screen sits there idling, waiting for me to pay attention to the computer before it starts doing work it knows I'm going to want it to do. That's rude, isn't it? In networked environments of diskless desktops, such as schools and offices, the effects can be even greater. It might not be possible to do background logins for the user, but a lot of things can still be loaded in advance, providing a significantly improved experience. And of course, the older the computers are, the greater the effect will be.

Port indicators to GMenu

mdadm currently has a gaggle of open bugs, and every cycle the RAID ISO tests produce new and interesting bugs. It seems like we're doing something a bit wrong with Software RAID. There are some valid solutions here: https://wiki.ubuntu.com/ReliableRaid which should be discussed and either refuted or implemented.

Growing the amount of charms in the charm store

The App Review Board and its processes were put in place 1.5 years ago. It's time to review how policies and requirements have been working out for us. Daniel H put together some discussion about a key point of these policise, the /opt requirement, at https://wiki.ubuntu.com/OptRequirement which can provide a basis for the discussion

Using more than one computer, often it would be useful to have a way to synchronize settings among multiple computers. For example you change the desktop wallpaper on your office PC and you want to find the same wallpaper when you go back home on your personal PC or on your laptop. Language settings, online accounts, privacy settings ecc... are only few examples of settings you could want to have synchronized. More specs in my blog page: http://www.andreagrandi.it/2012/02/21/ubuntu-syncronizing-settings-among-multiple-pc-using-ubuntu-one/

Kubuntu Active in Quantal

Notify OSD has been around for a while. In the main time our competitors introduced solutions using quite different approaches. Come to this session to discuss current issues and brainstorm eventual improvements.