taking the successes on juju to use the hud to search and find computing tasks. users could open the hub, and using natural language, type a question or describe a problem and an appropriate juju "charmling" will help the user solve the problem without the need for appreciable computer knowledge. this would use heuristics to determine possible solutions, choose the most likely correct "charmling", and assist the user. use cases could extend to any desktop usage, including very complex tasks requiring multiple steps and settings. examples might include: * fix a broken wireless connection * install packages * add a printer * connect to a print server for example, a user needs to add a printer. the user would open the hud and type, "how do i add a printer?". heuristics would determine the most probably answer, and start the "charmling" which would open an informational dialogue box telling the user, "The printer dialogue box is being opened. You probably want to select the "+ Add" button" and then opens the printer dialogue box. another example might be a user wanting to create a pdf. user opens the hud, types the question, heuristics are employed, and "charmling" is deployed which opens up a sane tutorial with examples.

OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined "forwarding instruction set". -http://www.openflow.org/ There are several FOSS implementations of openflow controllers. This session is intended to review the list and choose one for packaging in universe. Our criteria will be based on language choice, quality, development community health, and OpenStack Quantum support. The current list for review are: 1) NOX[1] - Created by Nicira, supporting C++. No quantum plugin. Not to be confused with "NOX classic" an older implementation supporting both C++/Python. 2) POX[2] - Same as NOX, but younger of the two projects and supports Python. No quantum plugin. 3) Beacon[3] - Research project written in Java by David Erickson, a PhD candidate at Stanford. No quantum plugin. 4) Floodlight[5] - Written in Java and recently opensourced by Big Switch Networks as "the foundation of a commercial controller product". In terms of Quantum plugins, Big Switch Networks stated on the project mailing list[6] that it wasn't in *their* roadmap, but encouraged the community to do it, e.g.: "...Big Switch also has a quantum plugin but its based on functionality not present in Floodlight on this point." 5) Trema[7] - Supports Ruby and C. Developed out of Japan according to their twitter feed[8]. NEC has created a Quantum plugin[9] that works with Trema, as well as their commercial OpenFlow controller. 6) RYU[10] - Written in Python by NTT, who have also directly contributed a Quantum plugin[11]. [1] http://www.noxrepo.org/nox/about-nox/ [2] http://www.noxrepo.org/pox/about-pox/ [3] https://openflow.stanford.edu/display/Beacon/Home [4] http://www.linkedin.com/pub/david-erickson/3/89b/166 [5] http://floodlight.openflowhub.org/ [6] http://bit.ly/K1w69p [7] http://trema.github.com/trema/ [8] http://twitter.com/#!/trema_news [9] https://github.com/nec-openstack/quantum-openflow-plugin [10] http://www.osrg.net/ryu/ [11] https://github.com/openstack/quantum/tree/master/quantum/plugins/ryu

Improve finger print authentication in Ubuntu

Java 7 was released last year and is now the primary development/support focus for both OpenJDK and Oracle. Java 6 has limited support lifetime left. We should transition all Java packages in the archive to OpenJDK 7 and endeavour to drop OpenJDK 6 from the archive.

Start building a comprehensive regression testing suite, this blueprint is a discussion to decide where to start adding test cases, so basically choose the most important missing tests and have a clear list of priorities.

System management and service orchestration for ARM Server, including MAAS and juju enablement.

Tasks from daily community roundtable sessions

Discussion of plans for improvements to the Gwibber service in 12.10 The Gwibber backend needs some re-factoring to make it more testable, robust and faster.

SPDX and DEP5 Generation

Archive reorganization has been stalled in a halfway state. Discuss what needs to happen for 12.10 to make the main/universe distinction obsolete for community and Canonical stakeholders.

We have had Jockey for quite a while now to perform the installation of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. fglrx-updates), third-party (e. g. from openprinting.org) drivers. However, I feel that this needs some refreshing: * The code base of Jockey is quite complex, it was meant for a lot more stuff than we are actually using it for. We also came up with simpler ways of mapping hardware to packages, mostly with additional tags in the apt package lists. We also have a more upstream friendly API in PackageKit/aptdaemon now to do this kind of thing. We can simplify the jockey code base and backend logic a lot (up to the extend of completely dropping it) by making full use of above new technologies and dropping the extra features we don't use. The exception is the openprinting.org detection, but that could go into system-config-printer or python-cups directly. * We install some drivers (like Broadcom wifi) straight from Ubiquity now, which certainly makes sense for devices where there is no free alternative. For the others (e. g. NVidia) we pop up a notification and offer to install them. I'd like to walk through the current UI and discuss how this could be made more steamlined and less confusing (e. g. for NVidia it can potentially offer 6 different drivers for you!) * We might consider merging the jockey UI functionality, which is mostly a shallow GUI around "install that package" now) into software-center, control-center, or something similar to the codec installer. I'd again appreciate if someone from the design team could participate in that (hello Matthew!).

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

https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-apt-improvements

Discuss what demand there is to make a GNOME flavor of Ubuntu, what it would contain and if it would have patches over upstream GNOME and what work needs to be done to make it happen.

There's more work we can do to make Quickly better and keep pace with the platform. Specifically this cycle, a big focus will be porting to Python 3 for both managed projects and Quickly itself.

The x32 ABI (http://sites.google.com/site/x32abi/) provides a compromise between IA32 and x86-64: it has a 32-bit pointer size, which is more memory-efficient and may often be faster, but has 64-bit registers and a larger register file. Support for it is gradually trickling into various relevant upstreams (kernel, glibc, gcc, etc.). Although the pieces are unlikely to be in place in time for 12.10, we should think ahead for how we might deploy this in Ubuntu.

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 release notes and technical overview could use a bit of tuning. Part of this is to be clear on the goals they are serving. Session is for discussion of the goals, and ways we can approach better, more automated generation of the content for them. (Leveraging blueprints completion notes, etc.)

Some devices that it's interesting to run Ubuntu on cannot do package-by-package updates for various reasons. Discuss what a solution looks like for implementing this with updating by way of swapping full OS images, various pitfalls associated with not running package maintainer scripts on upgrade, etc.

UDS Q Desktop Recap

Session to discuss and collect community wishlist for kvm and related packages

In the interest of better parallelization, as well as better use of idle machine time, we'd like to move livefs building from an out-of-band affair to a launchpad-buildd-driven build job type. This has been architected a couple of times in the past and repeatedly not made it to implementation due to lack of time, but it really should be done soon, even if the work spans a couple of cycles.

Discussing expanding the isotracker to perform testcase management and reporting for all kinds of testing, not just iso.

Review the current process and identify which parts of the documentation need to be improved. Also figure out what specifically we expect from upstreams and which help the ARB can provide.

During Ubuntu precise, packages for hadoop, hbase, hive, zookeeper and pig where delivered via PPA for use in associated charms which are now avaliable in the charm store for Ubuntu 12.04. The packaging is based on Apache Bigtop with relevant patches to support building on Ubuntu precise and for ARM. This session will discuss where we take this work next.

Here we go again!

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.

Building upon the foundations of the initial Ubuntu App Developer site, we'd like to expand it on a second design phase. Depending on the resource allocation from design, the scope might be reduced, so this blueprint is also to discuss the incremental improvements that can make a substantial impact and that we can work on next cycle.

Have a comprehensive smoke testing suite that is reliable by the end of the cycle

We reach out to potential new Ubuntu Developers in a number of ways. We have the weekly Developer update, public Hangouts, Ubuntu Developer Week, announcement of initiatives, interviews and other bits. Let's plan how we approach new contributors this cycle.

== Degraded Hardware Notifications == There are multiple ways hardware can degrade on the machine you are using. * degraded RAID * 100% disk space usage * 100% inode usage * S.M.A.R.T. - failing hardware * etc (?!) == Current notifications == * are sometimes annoying (endless popups on desktop for SMART) * non-existent AFAIK (inodes) * not configured out the box (degraded RAID http://pad.lv/535417) == Proposed notifications == Sometimes a user may not have the permissions to rectify the problem. The notification should stay persistent, until fixed. These notifications are important across all installation types. This notifications should not replicate Nagios/Check_Mk monitoring. * system indicators (Ubuntu Desktop) * byobu plugin (Ubuntu Server) * MOTD (Ubuntu Core) * landscape notifications * others ?! (Virtual Machines, cloud instance, etc) == UDS session == * Discuss what notifications we would like to implement * How/where/who will implement them

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

Come break stuff!

A lot of our development processes involve a review or approval step. Let's review how we've done in the P release and see what we can improve for Q.

Planning what the Accessibility Community Team is going to do for the next cycle. We were over ambitious last cycle, so it's time to pare down and look at what's realistic for this next cycle.

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

Tooling to promote/encourage upstart usage in charms

a new approach to users?

Review of the Precise cycle and brainstorming on how to improve.

The Ubuntu Youth team has been dead for a few years. It was a place where youth people can find others from their ages, and discuss about Ubuntu and what can they do about it. My intention with this session would be to find ways to revive this group, and also to define this group purpose and main vision for now on. Also, discussing how to promote it, how its leadership is going to be taken (Point for Philip Ballew, current Team leader) and how to give it an useful position in the community are points that are important to be taken care of during this session.

Ubuntu 12.10 should be fully proxy compatible, what means that every app should work with proxies for http, https, ftp, etc. So please add proxy support for: add-apt-repository, see bug #994569 gpg, see bug #443404 bzr, still searching for bug report

Discuss cleaning old kernels for the user

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.

This blueprint is to keep track of the roadmap of UATH and the features that will land on it during Q.

Etherpad Lite is the future of etherpad, it has a neat integration API, lets look at how tightly we can integrate it wiht summit for single sign on, pad creation and pad content management

Zentyal Server is able to provide configuration deployment and management for typical services on a Edubuntu server: HTTP proxy with content-filtering, LDAP and Kerberos or LTSP thin clients. Zentyal Desktop allows to configure these services on the terminals including authentication and session profiles. Explore how can Edubuntu and Zentyal developers can work together to provide an out of the box solution for school servers. Approved blueprints that would be implemented or related with this: https://blueprints.launchpad.net/ubuntu/+spec/student-control-panel-completion (zentyal desktop will integrate epoptes) https://blueprints.launchpad.net/ubuntu/+spec/edubuntu-profile-and-network-session-management (zentyal desktop will integrate Pessulus/Sabayon with LDAP backend) https://blueprints.launchpad.net/ubuntu/+spec/edubuntu-network-auth-client (zentyal desktop provides LDAP and Kerberos authentication) https://blueprints.launchpad.net/ubuntu/+spec/edubuntu-network-auth-server (zentyal provides LDAP and Kerberos server) https://blueprints.launchpad.net/ubuntu/+spec/edubuntu-user-management (zentyal has a LDAP users and groups management interface) https://blueprints.launchpad.net/ubuntu/+spec/edubuntu-ad-integration (zentyal provides ad-sync tool and samba4 integration) https://blueprints.launchpad.net/ubuntu/+spec/school-server-in-a-box (zentyal provides configuration of all needed services in one interface) https://blueprints.launchpad.net/ubuntu/+spec/zero-conf-server (zentyal is a simple interface to configure all services)

From the specification (https://wiki.ubuntu.com/ErrorTracker): "If a software update is known to fix the problem, replace the primary alert with the software update alert (or progress window, depending on the update policy), with customized primary text. Or point them at a web page (not a wiki page!) with details if a workaround exists, but no fix is available yet." Should we show the crashes the user has received that are now fixed by a software update in the description of that update? Should we provide a flag to automatically install updates that fix problems which left the system in an unusable state?

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