Review the state of the current collections, identified things that need to be fixed, expanded on or removed.

Roundtable sessions of the Community team.

Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Open roundtable to discuss any Ubuntu App Development topics that might or might not be in the schedule.

Kubuntu Active in Raring

Discussing the usage of HEXR for testing purposes Example use cases; Using your hardware profile inside the qatracker during reporting Ultimate goal; Targeted testcases for specific hardware configurations. Testing campaigns to push testcases and results back to developers

The FWTS Development Team's plans for Ubuntu 13.04 12.10 Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-fwts-improvements

[RATIONALE]: Currently the Cloud Images are built and released based on upstream tests. The idea is that if the upstream tests work, that the images will just work. However, due to bugs hit this past cycle, and with the proliferation of new clouds, the need to validate that the cloud images work where they should and characterisiticly are what we say they are, is becoming apparent. Also, with the proliferation of new cloud vendors, there is a need to automate the release process. Some in the community have asked for a more frequent release cadance for the cloud images. As a result, for the R-cycle, we will implement testing and automation that will be aimed at ensuring enhanced quality of the images. [GOAL]:   1) Implement deeper testing for the Ubuntu Cloud Images   2) Improve the quality of the Ubuntu Cloud Images by pro-actively looking for regressions and stress testing.   3) Implement Automatic releases to increase the release cadance for the Cloud Images The following Tests will be implemented: * Image Characteristic Tests:   - Define attributes of a Cloud Image, i.e. prescense of certain files, file formats, and package sets. For example:         - precences of /etc/cloud and files under it         - check boot loader configruation for grub and grub2         - deeper cloud-init testing         - check SSH configuration * Bug regression tests: look over the Cloud Image bugs related to the bulding of the images. For example:     - check that /var/log/{btmp,wtmp,lastlog} exist     - In order for a cloud image bug to be "fixed released" a test should be written to prevent future regressions. * Image boot tests    - Test that QCow images boot on KVM and OpenStack    - Test that outputed files are valid    - Validate boot loader and console configurations * Image proactive bug searching in Cloud instances    - Fully excersize disk, I/O and network looking for potential bugs    - Increase Amazon instance sizes tested    - Excercise -proposed updates to check for issues which may cause problems    - Use of Juju for testing Juju/Cloud Integration    - Mock workload tests * Image performance testing    - Measure I/O performance to identify problems with kernels or userland configurations caused by updates or build process * Explore implementation of UTAH testing framework * Integration and publication of results to Jenkins Instance    - Add the daily images to iso.qa.ubuntu.com    - Automatically update test results to iso.qa.ubuntu.com For Automation: * Integrate testing into image build process.    - Daily images for the development release must pass characteristic and regression tests.    - Daily images for the stable releases must pass all tests to be published    - Milestones for the development image are subjected to all tests suites    - Introduce automatic promotion of QA'd daily images when the daily has a new kernel or boot-criticial (i.e. reboot required to use) package.        - Automate email announcement generation - Implement Twitter Announcements - RSS Feeds Feedback Requests (via the two major Ubuntu Cloud Lists) https://lists.ubuntu.com/archives/ubuntu-cloud/2012-October/000839.html https://groups.google.com/forum/?fromgroups=#!topic/ec2ubuntu/HLjoxOgOJ10

In the last years a Common Printing Dialog was proposed as an OpenPrinting project and developemnt ha started, but the dream of having one unique printing dialog provided by the desktop environment (KDE or GNOME) never got turned reality due to lack of funding. The project did not only propose the one idea of a common dialog, but many small ideas of making print dialogs better and making available all the features of CUPS. As we are not able to finish the global project of a Common Print Dialog we could at least adopt some of the ideas which came up during the project. They can be implemented as independent patches to the dialogs/toolkits and submitted to the upstream projects. For some there are even PPD extensions defined and used by some driver developers, but the extensions do not get made use of in current dialogs. As this blueprint describes a lot of small ideas it does not require complete implementation in Raring, we could start with the most important ideas, or with the low-hanging fruits, or with which is already supported in existing drivers, ... To see the ideas and get some code to play around with here is the (now dead) project page of the Common Print Dialog on OpenPrinting: http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog Some of the interesting ideas: - Translated option/choice names for printer-specific options in the print dialog via "global" (multi-language) PPD files. such PPD files already come with HPLIP and Gutenprint - Tagging options, so one could for example show all paper-handling or all color-tweaking options - Widget hints: By adding hints to the PPD (AFAIK Gutenprint already has them) the driver developer could make the dialog represent options with his choice of widget (radio buttons vs. dropdown, input field with spinner vs. slider, input field with "phone book" button for fax numbers, ...) - Icons delivered by the PPD: Printer manufacturer/model logos, icons for options and choices. Widget hints could then even make certain options shown as icons only. - Color management: Choose server-side ICC profiles, rendering intents, ... - Preview embedded in print dialog (LibreOffice has this already) - All dialogs should provide the CUPS filter (non-printer-specific) options: N-up, reverse order, ... - ... Let us discuss what is urgently missing, what are papercuts, what are great improvements, ... and let printing dialogs get better.

This blueprint summarizes ongoing efforts to remove Python 2 from all Ubuntu installation media (formerly known as CD images :). While fantastic progress was made in 12.10, the job is not yet complete. We will be continuing the efforts for 13.04. Here is the new spreadsheet for packages which need porting for 13.04: http://tinyurl.com/8zcmr2w

A lot of our users do full dist-upgrades rather than reinstalling for every single release. It's a good thing that we support it and a very important feature, unfortunately it's a rather fragile feature, especially when doing LTS-to-LTS upgrades. This session is here to discuss ways to allow for faster, more reliable dist-upgrades. Some ideas: - Split download from upgrade - Run upgrade in a minimal failsafe environment - Use snapshotting features, overlayfs, ... when available to "test" the upgrade - Detect known issues prior to upgrade and warn the user about them

This session is for discussing an infrastructure and common tooling for data mining the Ubuntu project (archive, packages,bugs,blueprints, etc.) in order to determine information that will help with trend analysis and insights into improving automation and turning facts to knowledge ;)

We should discuss our plans for the Packaging Guide for the R cycle. The most important topic is going to be to merge the old and the new Packaging Guide.

Discussions on the likely mainline kernel version and appropriate kernel flavors for 13.04.

LibreOffice has an extensive testing infra. To make our testing valuable for them we need to integrate with existing solutions: http://tinderbox.libreoffice.org/MASTER/status.html http://ostrovsky.org/how-gerrit-fits-in-libreoffice-ci-infrastructure/ http://cgit.freedesktop.org/libreoffice/contrib/buildbot/tree/ http://conference.libreoffice.org/program/wednesday-third-track/gerrit-for-libreoffice This session is to evaluate: - what we can do - what upstream plans to do - how this all is scheduled - what can be achieved for this cycle - what we can do in the long term In the discussion we should involve from upstream: David Ostrovsky and Norbert Thiebaud early on. They did a lot already to push this forward upstream. I will hope they might join via IRC.

How do I know my code is not consuming too much power

Figure out the road to start doing UI testing with Autopilot in Ubuntu Engineering.

Define the deployment and maintenance process, instructions, and scripts for the Ubuntu Accomplishments verification service and Web Gallery

libvirt is the preferred virtualization management solution in Ubuntu.

NOTE: This has no relation to the current Weather Report :-) Create a realtime report that will convene the 'quality' of the ubuntu archive at any point during the development cycle. Summaries from manual and automated testing should be included, as well as pending releases and manually targetted ares to focus.

To support the appdev initiative, a new declarative format is wanted, representing the subset of capabilities that third-party apps are allowed to opt into. These declarative files should be converted to apparmor profiles at package build time. Specify a new tool that implements this in idiomatic debhelper fashion.

LibreOffice upstream is now almost fully migrated to gbuild. This would allow us to do real partial builds of LibreOffice, with split source packages. There are advantages and disadvantages to such an approach. Disadvantages: - More source packages mean more package handling as with an upstream release more source packages need to be build and tested - testing: most tests require a full libreoffice installation, thus a partial source package cant be tested completely during its build, thus these packages need to be staged in -proposed. Advantages: - Bugfixes would be possible without full rebuilds - Updates can be done without pushing a all libreoffice packages again to all users - Faster build times as some parts of libreoffice can be build on multiple builds in parallel - Filesystem limitations on e.g. PPA builders would not hurt us that hard anymore (as the biggest part of the fs-use is objects and dependencies) And initial proposal would be to have the following eight source packages: - libreoffice-dev-internal: libreoffice headers - libreoffice-core: ure and core libraries - libreoffice-writer, libreoffice-calc, libreoffice-base, libreoffice-impress: applications (impress includes draw, writer includes math) -- these could then build in parallel - libreoffice-l10n: localization - libreoffice-common: all the misc. bits and pieces. And yes, this would require a rewrite of the LibreOffice packaging from scratch -- but that might also simplify things a lot.

The Design Theatre is a format by which the Design Team collaborates with community members to make their app/software shine! The Design Theatre is for everybody: developers who come to the Theatre seeking design input for their software and who are ready and willing to present the design issues they have encountered; and spectators who just want to watch and learn about design thinking and problem solving. Participants will present their work for 5 minutes and together with the design team we'll walk through the steps of design thinking and problem solving to come up with interesting directions or next steps for the software.

Charm Schools and so on.

In this session we will discuss: * New features for MAAS this cycle. * Bug fixing.

Finding ways to speed up the review process for patches submitted to paper cuts. Slow review of patches that new contributors have submitted can be demoralizing and put them off further contributions. We need to speed up this process, both in Ubuntu and upstream in Gnome and Debian.

Have a python package that needs ported from Python2 to Python3? Come to this session to learn how

The Ubuntu archive is full of exciting GL games. Many of these games are likely runnning fine on arm if they are built with the right flags to enable GLES support. We are looking for community members to assemble a list of possible candiates for this, submit package fixes and get them sponsored into the archive by an Ubuntu dev. During the session a plan should be assembled on how to handle this task in detail (blog posts to generate interest, some kind of leadership to coordinate the effort etc)

Review ARB activity, and plan for the next cycle. Introducing new members.

General packaging blueprint for LibreOffice 3.7 on Ubuntu R

Things to fix for 13.04 in lp:charmworld, including addition of charm ratings to the UI. -Discuss adding any possible usage statistics -Discuss adding provider testing status Rationale: Goal:

Discuss state of Juju charms for deploying OpenStack. TODOs: - Quantum - SSL everywhere - HAproxy support for API server scale out and HA - HA rabbitmq and mysql - Nova compute live migration

Specific discussions surrounding kernel flavour selection and maintenance on ARM reference hardware for the Raring cycle

We started discussing proxy support in Ubuntu last cycle [1]. Keeping in line and expanding on that discussion (and really, taking back some of the work items from there), we should spend some time working with upstream NetworkManager to properly fold in proxy into NetworkManager connections for the desktop. Per-connection proxy support has been in TODO/roadmap for NetworkManager for a little while now; I think we'd benefit from seeing this to completion. Basically, this would mean: - Adding the necessary sections in NM config files for connections to describe proxy settings. - Moving/reworking proxy code elsewhere in GNOME to a "proxy manager" in NetworkManager. - Adding the necessary UI bits to nm-applet, as an extra tab for connections. - Testing, testing, testing. Proxy settings tend to be highly location-dependant, which is why it makes sense to tie them to connections, which also change depending on where a computer is located. This would make the life of mobile workers easier, since they could use a proxy automatically when logged in to their "work" wifi connections, and disabling it automatically when they go home... We should also more generally discuss the current state of proxy support in Ubuntu and what has improved from last cycle, the next steps. etc. In line with testing and with the documentation I started [2], we may also want to spend time setting up the necessary infrastructure for testing proxy support automatically. [1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-full-proxy-support [2] https://wiki.ubuntu.com/Testing/Proxy

How do I write a test and get the test into the test suite

UEFI fastboot is so fast that there's no opportunity for the user to interrupt it to get to the firmware (nee BIOS) configuration; the only way to get to the firmware configuration is for the OS or bootloader to set a flag in nvram and then reboot. We need to sort out what the UI for doing this should be. We probably want to support doing this from the bootloader menu (so that if the OS fails to boot you can still recover). We may also want to support doing this from the shutdown menu, in case the bootloader menu is inaccessible (e.g., on a touchscreen-only device?) and/or for a better UI experience.

We reviewed the patches in some of ours packages during the session and took action items on what to do to reduce that stack

Discuss design change proposals, evaluate WebKit vs. low-level Gtk, additional trophy images and more

lxc is the chosen lightweight (linux-guest-only) virtualization platform on Ubuntu.

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.

Organize a contest to increase the number of high-quality tutorials present on the app developer site

Secure your Ubuntu SSO account with 2-factor authentication! Get help setting up and using your *new* YubiKey (or Android/iOS smartphone!) to add an extra layer of security to your Ubuntu SSO account. Come to the workshop sessions and help us out making Ubuntu SSO more secure for you and everybody else.

Did you always want to get involved with Ubuntu Development but don't know where to start? Perfect! We want you to help us test our documentation. No experience necessary, you just need to have a working (not too old) Ubuntu installation.

We're going to use the hour to introduce people to the error tracker codebase. We'll help you set up a private instance of the error tracker using juju, then trigger a crash and walk through each part of the system as its processed and displayed on errors.ubuntu.com. An explanation of how the Cassandra database works will be given, as well as for d3.js and each of the libraries we use to build the site. The process for deploying changes to production will be discussed. We'll cover what work is going to be done in 13.04 and divy it up at the end. We'll also take general questions about the error tracker and solicit suggestions for improvement.

At this point, only yaboot and grub2-ieee1275 are supported as Power Architecture boot-loaders. Many new, non-IBM systems do not have any sort of OpenFirmware (ieee1275) component and so the boot-loaders are more bare (u-boot). One known system has actually built-in a grub into the BIOS and reads directly from /boot/grub/grub.cfg. Discussion is needed on best practices for hardware vendors and possible work on a more generic grub2 for PowerPC, which wont rely on OpenFirmware hooks being present.

Discuss existing smoke testing and agree on what needs to be added as a matter of priority during the cycle.

As Ubuntu members (and contributors), we understand Ubuntu (culture, community, technology, project, etc). How can we communicate Ubuntu to others outside the project (especially journalists/media) in a way that makes things easy to understand and reduces the tendency on the non-Ubuntu-community to "get the story wrong" or to "spin" stories with a default negative bias. Let's discuss opportunities and strategies to improve how we reach the non-Ubuntu crowd.

The current Ubuntu Server Certified Hardware programme is a programme intended to ensure that a particular release of Ubuntu works, up to a certain level, with a specific hardware configuration. All tests in the Ubuntu Server Certified Hardware programme are hardware related, with no specific software stack tests. Some customers have been asking to create an extension of that programme that will specifically test a version of OpenStack, with a specific version of Ubuntu, running in a hardware configuration. This new programme will include new Open Stack tests and some hardware related ones for functionality that helps creating and managing a private cloud. These tests would be run on top of the Ubuntu Server Certified Hardware test suite and therefore, every server that is Ubuntu Cloud Infrastructure Ready will automatically appear in the list of Ubuntu Server Certified Hardware, specifying that the system is ready to be part of an Ubuntu Cloud Infrastructure deployment.

If you have any questions about or issues with the nexus7 image, feel free to drop by to get answers

The regular Debian Health Check. https://blueprints.launchpad.net/ubuntu/+spec/community-q-debian https://blueprints.launchpad.net/ubuntu/+spec/community-p-debian

Ideal for web site developers. Learn about Ubuntu WebApps: how we add the new Javascript APIs in to the browser, what those APIs can do, what Unity features you get access, and most importantly of all HOW to do it. Complete with working examples.

Hadoop Moving apport and whoopsie to upstart inotify watches, if it's ready Team views -proposed view server-side hooks "What makes this problem interesting?" section Package installation failures, kernel oopses, application hangs, and debconf dialogs Using TPUT to speed up our most common problems calculation JMX to Graphite Staging server Nagios checks Retracer stability What do we consider a regression? Should we email/text/etc if a published binary is showing errors that it purports to fix? ... Other Error Tracker blueprints for Raring: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-updates-from-crash-reports https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-fix-ddebs https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-metrics https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-bucketing-improvements https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-phased-updates

vmbuilder was once the supported method for creating virtualization images under Ubuntu. It has now been deprecated in favor of use of cloud images and other image creation tools. 'oz' is favored as a replacement as it essentially wraps the (fully supported and tested) ubuntu installer.

For the past few months, Canonical designers have been working on recommendations to improve the way Ubuntu uses fonts. These recommendations cover things like the default font size, a family of sizes for different purposes, use of bold and italics, hinting of the Ubuntu font, spacing in controls, line length and layout of common window types, and changes to default components in Ubuntu. Implementing these recommendations would involve code in many components, including GTK, the default themes, Unity, the file manager, and other default applications. We will also provide guidelines for application developers on how to use fonts to fit in with Ubuntu typographically. At UDS we would like to present a draft of these recommendations and guidelines, and invite feedback both from Ubuntu developers and application developers.

Pedro Perez Grande is writing his masters dissertation on Canonical community and developers culture. He will present some of his findings and research hypothesis.

Discussion of the juju gui. Solicitation of feedback of current implementation and brainstorm discussion on new features and integrations for raring.

Gridcentric Virtual Memory Streaming (VMS) is a technology to start VMs from already-running snapshots (saving time, I/O and allowing a greater density of VMs). This is principally used in OpenStack deployments. We maintain a small collection of patches for various versions of qemu that enables VMS with KVM (some are already upstream). We would like to include these patches in Ubuntu qemu. This would allow users of our technology to use standard Ubuntu packages (benefiting from security updates, etc.) and make Ubuntu a very easy platform to deploy our technology.

OAuth is such a simple protocol (v1 at least) and there are many packages available in the wider Python community and in Debian/Ubuntu. Sadly, there seems to be few options for Python 3 compatible, *upstream maintained* OAuth libraries. How can we encourage, fork, group-maintain, or otherwise improve the story for a Python 3 compatible OAuth library in Ubuntu?

Discuss the features to be implemented during the R-cycle

MidoNet is an advanced Software Defined Networking (SDN) solution, which provides network virtualization for public and private cloud environments. Adding MidoNet dependencies is the first step towards including MidoNet into ubuntu repositories for Ubuntu (possibly partner).

Create a new section on the App Developer site for authors to easily submit and share their code snippets

Checkbox is a tool that is used by a number of parties in their day to day work, and so they depend upon it to be somewhat reliable and not break often. For this to be the case, Checkbox requires a release processs (to indicate when and how it is being released) and a test plan which indicates which functionality is going to be tested to try and ensure that it's working. At the moment it has neither. == Release Cadence == One of the most important aspects of a release process is to have a regular, predictable schedule. This allows users of the software to plan for forthcoming changes and for arrangements to be made to have resources available for proper testing. Also, for testing to be effective there must be a period of stabalisation where critical bugs which were found during testing can be fixed. The following is the proposal for the initial cadence of two weeks: Days 1-8: All merges may be accepted into trunk, no restrictions Days 9-12: Only bug fixes may be accepted into trunk and manual testing begins at this point Days 13-14: Only fixes for critical bugs identified by testing may be accepted into trunk. Manual testing is rerun to confirm bug fixes are effective and that no further regressions occur. In addition on day 13, there will be a release meeting involving the release co-ordinator and a representative from each stakeholder to go over the major issues found so that everyone can be aware of them. Checkbox will be released on the 14th day of the cadence. In order for work to continue on developing new features and fixing bugs during this freeze period, a scheme will be worked out to branch the code from which we will release Checkbox at a particular point. This will prevent potentially important work from being delayed while maintaining stability. Going forward into the next cycle, the plan is to shorten the cadence down to as little as one week. This can only be achieved by increasing automated testing and making sure that there is good confidence in the effectiveness of that testing. In this way 'freeze' periods (which slow development) can be kept to a minimum and improvements brought to the users faster. The ultimate goal would be for everyone involved to have strong enough confidence in the automated testing that they are willing to accept this as assurance that a version of Checkbox is sound enough to use. == Routine Automated Regression Testing == In order to provide a solid foundation on which to perform more thorough testing prior to release, it is important to have a strong automated test suite in place that can make sure the fundamental functions and features of Checkbox are working properly. Since Checkbox is a fairly complex piece of software and also heavily geared around user interaction in most cases (although it does support running 'headless') it will take some effort to fully automate everything. More to the point, in terms of time resources 'routine automated regression testing' must be kept distinct from automated testing in general. These tests are intended to run pre-merge, on every merge. There must therefore be a limit on the amount of time they take to run. More than a few minutes and it may be necessary to start splitting the tests out. At the moment Checkbox does have something in the way of a test suite that fits this description, but it is still in its infancy and requires more effort. At the moment the strategy for expanding it is to add tests on a case-by-case basis whenever there is a 'test escape' which looks easily automatable. This is a decent strategy, but going forward some measure of coverage and a more structured approach would be desirable. Checkbox being a (mainly) Python based application, there are several tools which will aid in measuring coverage (http://pypi.python.org/pypi/coverage/) == Pre-release Manual Testing/Extensive Automated Testing == The final line of defence before release needs to be thorough and cover as many of the most important use-cases as possible.Since Checkbox is based to a large extend around manual testing and is primarily used through its graphical user interface, most of the more extensive testing will have to be geared around real or mock 'manual' testing - i.e. manipulation of the graphical user interface. The most important thing to get right here is to properly prioritise the tests that will be run so that the test cases which, if they were to fail it would be considered critical, are introduced and run first. A list of potential use-cases can be seen here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhbvF3mVZ2BadG9GRXcwdmdZVTFiOW9JT21wbEY1S1E Initially this testing will have to be manual, but there are tools available which allow for automation of UI interaction (http://xpresser.com/). Still this type of testing would need to be kept distinct from automated regression testing, as it would potentially still take a long time to run. A further point to be considered is; where to keep the test case definitions? Even if the test cases are automated with a tool such as Xpresser, it is important to store some kind of formal definition for maintenance purposes so that if an automated test breaks then its intent can be kept. Some liason should be made with the Platform QA team to see what they recommend, but it would be possible to fall back on a simple spreadsheet. During this cycle the goal will be to implement all of the use cases mentioned in the spreadsheet above (except where a use case is dropped by consensus), initially as manual test cases and at least half of the test cases should be automated. == Versioning/Branch management == Not directly related to quality, but still and important aspect of releasing software, is versioning.

This workshop should give you a quick introduction to Ubuntu development. You don't need any prior experience, just a working Ubuntu installation.

binfmt_misc (miscelaneous binary formats) is a kernel module which supports the specification of userspace interpreters for binaries executed by userspace. By specifying an invalid binfmt for ELF, it is possible for a confused chroot or package to destroy the ability of the host to execute any binaries. By introducing a namespace for binfmts, a chroot could be preventd from changing the binary formats usable on the host.

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.

A workshop to orient developers on contributing to upstart, covering the basics of the libnih and upstart design

We will transition from gstreamer 0.10 to 1.2 and demote 0.10 to universe if possible

Discussion for the upcoming development cycle.