As Ubuntu Server depends more and more heavily on automated usage of apt, we're seeing more and more failures of tests, installs, Juju, MaaS that result from apt mirror or proxy issues or general issues in apt's behavior. Here we will address ways we can make Apt more reliable.

Python 3.3 will be released by August 2012, theoretically in time for 12.10. Should we make it available in Quantal, and if so, do we keep Python 3.2 or only support Python 3.3. Long term, if history is any guide, Python 3.4 could be released by February 2014, which is probably too late for 14.04 LTS, although we make the alphas/betas available early in that cycle and switch to the final release by 14.04 final. Some arguments for supporting 3.3 in 12.10 include proper support for namespace packages (likely, PEP 420) and built-in virtualenv, among lots of other improvements. Arguments against supporting 3.3 include not being sure that all our packages build against it (especially since it's still in alpha as we speak). Arguments against supporting both 3.2 and 3.3 include the additional disk image space necessary to support both. Arguments for supporting both include a longer and better transition period to a presumably 14.04 LTS world where only Python 3.3 is supported. We also need to consider how this will work with Debian, with their planned freeze in June, after which we can't switch the default Python 3 version.

This blueprint is for scheduling purporses only. Please read the full description at: https://blueprints.launchpad.net/certify-planning/+spec/cert-q-12.10testing

Planning the design of a distributed testing toolkit for Desktop and Laptop hardware. This new toolkit will allow users to access both local and remote resources. Tests can be executed across networks, providing both SUT status and test result reporting. Reasoning: The current tools available for hardware testing are complex and difficult to maintain. This makes feature enhancement slow. There is a need to replace existing tools with a more powerful suite. The largest change to the current set of suites required by the teams involved is remote execution and reporting. The flexibility to execute tests on systems from a centralized location is valuable in both time and resources. In addition, the support for differing workflows is desirable. By making the new suite a library, any number of interfaces can be written to exercise those options. This provides the teams using the library to easily build an interface that exactly meets their needs and process. Work so far: A team of engineers from Canonical has begun work on a python library with the capabilites to execute tests across private networks just as easily as you would on a local system. Prototyping of the basic features is complete and a demo of this prototype will be presented in this session.

Identify tutorials and documentation needed by upstream developers to port and integrate their applications with Ubuntu and Unity

Discussion of changes that would help: - release team with managing and publishing images, understanding the quality/shipability - qa teams (ubuntu and flavors) for understanding quality of images and issues for developers - testers ease of using system, logging results, automated logging, knowing bugs

Plans for the software-center client

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.

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?

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

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

Track progress and be able to determine how long will take us to get to 100% coverage and help us prioritize the work

Add Ubuntu packages for more AWS tool sets like Auto Scaling, ELB, EMR, CloudSearch, ElastiCache, etc.. Make sure that the ec2-api-tools and ec2-ami-tools packages are kept up to date with new releases from Amazon so that they support the latest EC2 features.

This is a starting point for discussion of ARM Server topics. We will need at least one session at UDS for this area. We should probably get more specific, like systems management, network fabric, etc.

With lots of work put into https://myapps.developer.ubuntu.com/ it should be interesting to review MyApps from the ARB perspective and see if there are small tweaks which would speed up the review of free apps.

We’re aiming to make Ubuntu more resilient against hardware failures, with a focus on OEM-preinstalled Ubuntu. For example, an invalid CMOS time/date value can cause the system to fail in various unexpected ways. The purpose of this session is to define which problems may arise due to: * "Sitting on the shelf" problems, eg RTC battery going flat * General mass-production issues * Missing drivers due to subtle SKU alterations * Low-memory situations * Corruption during factory pre-load - or any other areas that we can identify during the session. We'll be aiming to outline potential solutions to these issues, and carry out that development work in the Q timeframe.

Hand over and implement the Linaro GLES 2 branches.

Determine the various technologies to be applied in the design of Checkbox Core. Checkbox Core is a distributed testing toolkit. It will allow users to execute tests and receive status and results across private networks. Strategies must be developed to handle the complexities of this type of transaction across unsecurred networks. Reasoning: The current Checkbox framework is complex and difficult to enhance. There is also the added difficulty of split usage. Hardware Certification requires one type of suite, Ubuntu Friendly another, and QA a third. Checkbox Core is being designed to resolve these issues in a few ways. The first is by simplifying the design. The core is a Python library that supports the existing features of the Checkbox application, but as simple calls rather than integrated actions. Teams adopting the core can use as much or as little of this library as they need. Secondly, the core supported remote execution and results reporting, including the ability to execute across private networks. Security is, therefore, paramount to this effort. Lastly, Checkbox Core has no GUI. As a library is allows the users to determine what features they need and provides an easy SDK for developing an interface most useful to that team. Status: The Checkbox Core team is in the process of identifying the technology required to fully implement the spec as it is currently written. Some details require further discussion. Security is a major area not fully defined. A prototype is available to guide future discussions and planning.

In 12.04, Byobu moved to Tmux as its default backend. Thoughts? What's working well? What's not?  - on tty, tmux is a little wonky  - on smaller sized terminals, tmux status is blanked out  - anyone still using screen backend? maintain support for screen?  - issues with byobu/tmux causing too much load?  - issues on micro machines? - new byobu.co website -- looking for a volunteer web developer to create the site and content...

Rationale: This is a revival of https://blueprints.launchpad.net/ubuntu/+spec/other-p-bug-dashboard. We have lots of sources of information about our packages and bugs, and issues potentially unreported (with whoopsie-daisy). We need to consolidate this information and make it available in a palatable way, so we can worry about what to do to fix and avoid bugs, instead of worrying about how to figure out where to look to check for issues. Goal: Have a centralized place to do a health check of Ubuntu. We want, in a glance, to be able to know packages that have spikes in bugs, bugs that should be fixed but aren't getting the proper attention, problems that are happening but no bugs were reported yet, and the like.

I think it's necessary for Ubuntu to take documentation to another level. When I first started with Ubuntu, I really wanted to learn how it all fit together. I have used computers most of my life so I'm accustomed to reading documentation and I was perfectly willing to dive right in. But it just wasn't that easy, not necessarily because of the information itself, but because of how it was organized and presented. There were no clear starting point and no trails to follow. There were broken links on wikis, and outdated information lying around. Much of the documentation would only use version numbers, and have no easy way to see when it was last updated, or if it had been superseeded. Confusion reduces peoples ability to learn. To me, this is The Issue with Ubuntu. If we're really going to succeed in taking Ubuntu «across the chasm», then we must make it easy for the curious to become users and for the enthusiasts to become power-users. For this to happen, we need to do something drastic about the way documentation is presented. I think Ubuntu Documentation must: * Have an obvious starting point * Lead to the next step * Be instantly recognizable as valid or invalid * Be grouped when applicable * Primarily focused on LTS * Reviewed for each release (hence the point above) * Easy to contribute to by reporting issues * Be not only API docs, but contain readable text. developer.u-c and help.u-c has improved a lot in this regard, but not enough. Look at this page first: http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader, I can come across issues that I'm not able to read, but will help improve the documentation. I should have a very easy way to report it. There's no way at all on that site, though at the very bottom, I can submit a tutorial. Another example, look at this page: http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html. Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still valid? There's no way to know. We shouldn't rely on people to trust that if not stated otherwise, it is valid. This is the web. There are millions of old and unmaintained documents out there. It must be obvious that it is valid. This also helps anyone recognize invalid documentation, enabling them to report it or fix it. And what if my primary focus is developing an application for LXDE and I want to use only an indicator? In this specific case, I'd use a separate version for the API docs and call it Unity Specification 1.0 for 12.04. Then if there are any changes between now and 14.04, I'd call that 2.0. For versions in between I'd add 1, 2 or 3. So, if there are API changes i 13.04, I'd expect to find a Unity Specification 1.2 and that it would clearly show the differences between 1.2 and 1.0, considering the newest LTS the In the case of Unity-5.0 for Python above, I'm not sure I'd call that Documentation. That is the convention, but I'm not sure that's what people expects. I'd call that document a Specification. For Documentation, I would expect more readable text, explaining what it's for and how it is used. Enum: Unity.FilterRenderer CHECK_OPTIONS_COMPACT 4 Right. How do I use it? .)

In 12.04 chef and ohai were removed from the Ubuntu archives at the request of the maintainer due to being outdated and unsupported. This session is about how we can get both chef and ohai back into the Ubuntu archives at supported levels.

Improve finger print authentication in Ubuntu

Promote the availability of new apps in the Software Center, both in USC itself and through other channels, to raise awareness of apps targeting Ubuntu

We currently only generate ddebs for the most recent versions of packages in the archive. With the new crash database, we receive a lot of core dumps which we cannot completely retrace because of this issue (https://errors.ubuntu.com/api/retracer/results). For the Launchpad-reporting side of things, this results in an ugly "cannot report this problem" dialog. IS is also not happy with the manner in which this is currently implemented. Let's get ddebs support into soyuz.

General discussion on improving LTSP's integration in Ubuntu and our overall thin client experience. Ideas that have been mentioned and should be discussed: - How to deal with chroot upgrades (currently not supported) - Making maintenance easier - Split ltsp-live out of the main ltsp package - Rebase on Debian's packaging for ltsp itself (only package we don't simply sync at the moment) - Generating a .img image from an LTSP chroot that can be used to make a standalone thin client image

In the past we have had great interest from new contributors in getting involved through organised initiatives. Both clarity in instructions and a clear set of targets have helped a lot here. In the session we should discuss possible targets for bug fixing initiatives, who can help and set up an initial schedule.