Review the current state of hybrid graphics and what's feasible for 12.10. - base prime/dma_buf -support is now in 3.4rc - prime sharing support for ttm/nouveau/i915 is queued for 3.5 - preliminary work towards a new driver api in the xserver has been submitted for review on 2012-05-05 (scrn->screen), 'drvmodelv3' staged in git - randr api still being worked out, preliminary work in git http://airlied.livejournal.com/75555.html old blueprint for reference: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-hybrid-graphics

Are there any infrastructure changes would help the Ubuntu Flavors and their communities with development and test?

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

Giving an entirely new version of any widely used software program to our entire user base all at once is unnecessarily fraught with peril. Instead, let's employ a phased update strategy wherein we provide the updated software to an ever-expanding set of random users. This pool of users will be grown as our confidence of that software update grows, fed by realtime information from the crash database and other potential sources. We should discuss the tradeoffs of doing this just post-release or during development, when we're also trying to land large changes to the operating system. We should build this at a level that still affords power users the ability to forcibly install all updates. Update-manager is one such option. It might be worth also discussing the possibility of using feature flags.

Fedora has decided that they are going to merge {/bin,/lib,/sbin} into /usr. https://fedoraproject.org/wiki/Features/UsrMove This means that upstream support for distinguishing between / and /usr for early boot services will atrophy more than it already has, and there will be extra work involved for Ubuntu to maintain this capability. Furthermore, if we can rely on /usr to be mounted when upstart starts, we can simplify a number of system jobs. Explore whether we should change initramfs-tools in Ubuntu as well for 12.10 to provide this guarantee.

Tasks from daily community roundtable sessions

Outline the next steps we need to take with the maas project for 12.10.

Server vendors, like HP, provide additional tooling for analysis of system crashes. This session is to discuss how these vendors can best integrate their tools into apport.

Specification for a set of policies and settings important for desktop lockdown.

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.

U1DB is in beta as of today, and we want to show and tell and guide you through how to use it in your apps.

Things to package for Q

In Precise Beta 2, we were able to use -proposed as a staging archive for the first time. This blue print is to gather examples and use cases, as they occur during the remainder of the cycle, of what worked well, and what caused problems. Thinking is we can then get together at UDS, review the use cases, and figure out some polices to use it effecively going forward.

This session is intended to gather feedback from current users of the ubuntu-qa-tools code, including vm-tools and dl-ubuntu-test-iso. We would like to get the tools packaged for wider use, and ensure their continued maintenance.

In this session we will be discussing the improvements planned for the Ubuntu multi-monitor user experience. The design specification can be found here: https://docs.google.com/a/canonical.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit Come along to share your feedback and ideas.

A change I'd like to make for 12.10 is to use a compositor to control video from boot to shutdown. This gives us the following benefits: - We can have smooth transitions from the splash screen to the greeter to the session and back again - We don't use VT switching anymore which has been shown to be problematic - We use one consistent monitor layout for all stages of the boot - We can use the greeter as the lock screen (couldn't get it to work this cycle for the above reasons) - We can ensure that you can never accidentally switch to a locked session - We can show the greeter while the session loads The technology used will probably be Wayland, and in some ways this change is to implement the Wayland Tech Preview that was proposed for Precise [1]. Note that not all video drivers will support this, and we will continue to support the current system for those that do not support it (primarily the nvidia driver). [1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-wayland-tech-preview

Catch up with significant btrfs consumers (particularly the server team) on their requirements for btrfs in Quantal, in light of upstream activity. Figure out areas where we might be able to help.

With the inclusion of Samba4, Ubuntu still lacks of a graphical interface to manage a domain directory, including LDAP, Samba, DHCP, DNS, etc. For administrators coming from the Windows world a graphical interface is a must. In the past some tools like SWAT did this job but they have become obsolete with the release of Samba4 that needs a more complex setup. Zentyal is currently the only interface on Ubuntu that can manage and maintain synchronised Samba4 and OpenLDAP. We will discuss further improvements on this and integration with Ubuntu default components.

Hda-emu is a way to test kernel code for Intel HDA sound cards, without having the hardware at hand. Discuss how to evolve this code into a regression test suite, that we could run before e g releasing proposed kernels, and how to integrate it into existing QA efforts (jenkins etc).

Review of Quantal schedule and Interlock schedule to 12.04.1 needs. Primary page is:     https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule Need to synch with:     https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule (for 12.04.1)    https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock

Pad - http://summit.ubuntu.com/uds-q/meeting/20344/ubuntu-manual-schedule-for-p-manual-and-beyond/

Review the buildd resources available for the distro builds and various test builds, discuss buildd uses outside the core distro team (like daily Go builds, and unity test builds).

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

Corporations deploying Ubuntu Desktop instances face a number of issues in adopting it in their environment. The major pain is Microsoft tools that mostly dominated the backend infrastructure - Active Directory, Exchange, LiveMeeting, Office and other.

This blueprint is created to as a way of tracking the work the Platform QA team is doing on the lab during the Q cycle.

What ISO images to release with Quantal?

The ubuntu server team have been using the current bug triage process for a full release now. We should review the current process and reports to ensure that the current process is working and to identify any improvements that can/should be made during the quantal release cycle.

Come and calibrate your monitor using the Colorhug open source hardware and Ubuntu 12.04

Kernel Stable Release Updates (SRUs) are tested by the certification team in search of possible regressions or bugs that may affect certified systems. These tests have to be performed in sync with the SRU release cadence, and in order not to hold up the SRU's release, they need to be done within a tight schedule, so they entirely consist of automated tests, to provide the response times and scalability the SRU process requires. Due to its nature, SRU testing would benefit from as many tests as possible, but always with the constraint that they be automated or, at most, require a human to review collected data in bulk. Tests that require interactive verification or human action are to be avoided. To enhance the value provided by SRU testing, we need to both add new tests, and improve the existing ones, based on input from the Kernel team about the areas that traditionally give the most trouble, and possible ways to test for bugs or regressions. == Improving the test development process == From inception to actual implementation in real SRU runs, tests may take up to 4 months to actually start being run. This diminishes the value and means that the number of tests that can be implemented per cycle is very small. The test development process needs to be described, analyzed and reengineered with the goal of reducing the turnaround time for new tests as much as possible. == Improving coverage in existing areas == Coverage has been improved in e.g. wireless testing, but some other areas, such as graphics and audio, can still use some improvement. Consulting with experts on these areas as to which tests would be useful to have, and implementing them (ideally with the new process so we can start seeing results as soon as possible). == Automating plugging/unplugging of devices == Coming up with a solution that can automate traditionally manual actions (such as USB, memory card, external video and FireWire insertion or removal). This would enable automation of these high-interest tests, and open up new areas for SRU testing. == Benefits from this blueprint == The certification team will benefit from an ability to develop reliable tests more quickly, by being able to respond to requests from other teams, as well as having techniques for automating physical interaction which will allow fully automatic and more comprehensive testing while maintaining scalability. The kernel team will benefit from wider testing, able to catch more bugs and regressions in sync with the SRU cadence, and an increase in the number of test results the certification team will provide. List of possible tests: https://docs.google.com/spreadsheet/pub?key=0AhMEQ8F2hKQOdC1Vd0RGWllLa3R1ZXNkbldsaDJvaWc&output=html

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.

Items include:   finishing MIR of netcf, and linking libvirt against netcf Get community input

The third Open Compute Project (OCP) Summit is the week before UDS, in San Antonio. This bluerprint/session is to serve to inform others about the current and future hardware specifications for the OCP (v2 and v3) as well as; List any known software components of the OCPv1 and v2 spec, Document future up-and-coming requirements , Classify any pieces that would need to be solved by an OEM/ODM (such as providing a bios flash tool / sensors module), Take note of any pieces that could be solved in Ubuntu such as using standard ipmi calls, etc, or tools to convery "OCP config files" that might be written for a CentOS SNMP server, to ones that would work on Ubuntu, hardware enablement, BMC, etc).

Discuss where to focus Ubuntu-specific AppArmor packaging and integration efforts.

Identify and engage targetted upstreams to submit their apps to the Ubuntu Software Centre

Discuss what went well and what didn't go so well in terms of QA - Release team communication during P and try to put in place the actions for smoother milestones during Q.

We would like automated integration testing of our bootloader for 12.10. Foundations will probably need to write these tests, with QA team providing guidance on the kind of tests to run.

Present current design of user namespace, and discuss likely upstreaming dates and possible early inclusion in our kernel.

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.

This blueprint is about analysing the damage that is done by the spliting of LibreOffice into separate packages, which never was a goal at the upstream project. Because of that, in some cornercases LibreOffice crashes or fails to perform because of missing parts, when not installed completely. This is more severe than in other distros because we ship only a partial installaltion with the default install. Examples include: - document wizards not working in the default install (need java components) - mailmerge not working in writer in the default install (needs libreoffice-base) - some HTML-imports not working in writer in the default install (needs libreoffice-base) - formfields/checkboxes not working in writer in the default install (needs libreoffice-base) Fixing all these upstream is an uphill battle as new dependencies might be added under the radar by new features. So while a full libreoffice install on Ubuntu is doing fine, the default installation on Ubuntu is casting a shadow on both Ubuntu and LibreOffice.

This session is designed to discuss which accomplishments we want to focus on for the forthcoming cycle to expand the Ubuntu Community Accomplishments collection.

We want to increase the reporting ability of the test suites in the Indicators by switching to Google Test.

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.

This blueprint captures all the ongoing tasks that the Platform QA team is going to be doing during Q, set the focus for the coming 6 months in terms of QA ongoing activities, such as keep running test cases, triaging problems, etc.

With the release of Essex on Precise we wish to regularily provide timely updates to our users who are still using Essex. The purpose of this blueprint is to figure out the process and track work that needs to be done.

Discussing improvements as to how, when, and why we iso test. Additionally defining and understanding the communities enhanced role in iso testing

Planned updates including Greeter as the Lock Screen, flicker free transitions, confirmation dialogue, morphing login box, drop-down menus and back button.

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.

Discussion of improvmenet and enhancements to the Cloud Images and Cloud-Init * Addition of an SSH recovery Shell: Depending on the virtualization solution (i.e. EC2 EBS versus EC2 Instance-store versus OpenStack), the ability to recover from file system corruption is limited or non-existent. In order to support users across different virtualization solutions, it is proposed to introduce a SSH recovery method to assist users in recovering from file-system corruption or missing disks. Proposal: 1. On failure of mount-all or on cloud-init failure to mount all disks, SSH would be launched 2. Users would be forced into a screen session with an error message. 3. Users would need to reboot. * Dynamic multiple LOCALE support: While English is the language of Ubuntu development, the use of Ubuntu is global. Further many Ubuntu users have default locale settings that are different. When SSH'ing into a Ubuntu Cloud Image, some software may fail to work properly with invalid locale settings set by SSH. Proposal: Develop a method of compiling new locales based on SSH LC_* and LANG settings sent by SSH client. * Improving methods for users to find official EC2 AMI ids: Over the last couple of months we have made significant progress in developing new ways for users to discover the official EC2 AMI ids. Between the AWS Quickstart, AWS Marketplace (free tier and paid support), cloud-utils (which provides ubuntu-cloudimg-query), cloud-images.ubuntu.com (/query and /query2) and cloud.ubuntu.com/ami, there are several official ways to find the images. Discussion: What are the deficiencies in the current methods of finding images and how could we make finding the official AMI's easier?

As actual ARM server hardware begins to enter the marketplace, a standardized way to test and benchmark performance must be developed and run on all active platforms we support for ARM server.

Bugs should be assigned to the teams in order to get them considered for fixing as part of a release (stable,development). However our current infrastructure gives us no effective way of telling the difference between bugs that the development team is not committing to fix, and ones they haven't looked at yet. This causes inefficiencies, and doesn't scale well for teams (release, support, etc.) that have to look at wide range of bugs and issues across multiple development teams. This session is to discuss and agree on some conventions/policies/and possibly additional tooling to make this effective for all the stakeholder, for q development release, and p lts supported release.

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.

Review the processes & how the ARB team is doing.

Training session for the DX team.

Discuss how to get users with the kernel backports transitioned into the latest backport so they remain secure with proper security updates.

A roundtable to discuss any issues, improvements, ideas around the Ubuntu Translations community

The purpose of blueprint will keep track of the work needed to be done for integrating the Folsom release into Quantal.

Hand over and implement the Linaro GLES 2 branches.

As we move towards new markets and challenges to satisfy those markets, its time to re-examine how we've been doing things, and start planning for the longer term infrastructure goals we want to have in place for the next LTS and beyond. The build infrastructure has evolved since it was started 8 years ago, and several things work very well, while others could benefit from some brainstorming about what we'd do if we had a clean slate.

Discussing how to better organize the diverse set of teams within ubuntu and it's flavors dealing with QA.

Several countries have "special apps", that are very useful to that country. E g applications needed to log in to government sites, for declaring taxes etc. Could we get these apps into the Software Center, the partner archive, debian...so that it is extremely easy for users to install them? ==== Note ==== As this session did not get enough traction (and I didn't go and drag people in...), no action items were decided upon. :-( // David

Review of the kernel configuration for Q 12.10. This will concentrate on confirming the policy for various option types as well as new options. For major new options, we will discuss and confirm the selection of each.

Things to accomplish for this cycle

http://design.canonical.com/2012/04/status-menus/ Discussion and tasks for changes in the indicators.