Today, testing a package may be slow because of the waiting period that compensate the lack of rigorous test suites to regression-test changes, lack of hardware for QA’ing, we are mainly relying on community for testing, the amount of patches that get rolled can be important,... All of this can lead to a bug with a known fix going unaddressed in Ubuntu for several months. We need to shorten the delay of validation for SRUs and being able to provide adequate resolution on an ETA for a fix being included in Ubuntu. The goal of this session is to discuss and decide how to improve Standard SRU testing (everything but kernel), make it more efficient, increase the coverage of the QRT and build a test harness to run daily.

There's more work we can do to make Quickly better and keep pace with the platform.

Private

When preparing milestone releases, we often need to turn around fixes quickly. The pipeline from a developer source upload to a full set of updated image builds on all architectures is currently somewhere in the region of nine hours. We would like to make this much quicker.

currently every ubuntu install requires an initrd, this is caused by the fact that we: a) use UUID for finding the rootfs b) some packages have a requirement to process bits before the rootfs is mounted this spec is supposed to span across multiple releases, we first need make the kernel recognize UUIDs for partitions and second there needs to be something like a database that knows when a package is installed that needs an initrd. This spec is considered implemented if initrds are only generated once a package is installed that require them or the user explicitly choose to use an initrd.

Tuesday roundtable

Tuesday's security roundtable

How to increase theming consistency and how to properly style widgets and user interfaces

which ibus applet to use?

This session will discsuss the current issues we're facing with the toolchain CI builds, looking for different solutions and discuss with the TWG how frequent the builds should be to be valid. This will also cover the validation plans for both native and cross Linaro GCC. More info at https://linaro-public.papyrs.com/public/4120/LINUX2011-TOOLCHAIN-CI

Discussion of ARM SOC upstream process, what's working, what's not, what needs to be changed. Etherpad @ http://summit.linaro.org/uds-p/meeting/19256/linaro-kernel-arm-soc-process/

Discuss development of HW enablement tests and how we get them into Lava. Etherpad @ http://summit.linaro.org/uds-p/meeting/19261/linaro-kernel-platform-testing/

This Summit brings together the different players with the aim of helping ensure that Linux based ARM servers can be brought to market as soon as the hardware is available.

This Summit brings together the different players with the aim of helping ensure that Linux based ARM servers can be brought to market as soon as the hardware is available.

Meet with the Ubuntu desktop designers, hear what they love about Ubuntu, what they'd like to do better, and what they dream about.

Builds: start tracking the quality of the builds, define what a broken build is and track how long it takes to engineering teams to fix the problems they introduce that impact testing. By doing this, the aim is to raise awareness of impact of untested submissions and to be able to determine how many times we are held by bad submissions. Add a dashboard to have a consolidated view of unit testing status. Collect initiatives from different engineering teams and either add it to Jenkins or consolidate it to make them easy to read and triage in case of failures.

We would like to look into the possibility of asking people running -proposed to run a set of tests for each new SRU that will submit the results to launchpad. We would be doing most of the work, but I am not sure if the work required in the update manager is in your team or foundations

Private

Linaro STE meeting

The Ubuntu Engineering team in Canonical is committing a rotation of developers to work solely on development release maintenance for a month or two at a time, with the goal of keeping the development release buildable, installable, and upgradeable at all times in order to allow other developers to work with fewer interruptions. What should our priorities be? How should we organise ourselves? Given the alignment between this and e.g. the historical activities of MOTU, how can we build community participation or link into existing activities?

Discuss and implement in Ubuntu a framework for generating dkms packages from a driver source tarball. The framework makes it easier to create an maintain dkms packages by automating many of the mechanical tasks currently required by dkms.

Several items should be worked on during this cycle:    provide a default bridge and lxc.conf    proper reboot    containerized syslog    userns vfs    apparmor support    ARM support    tests in qa-regression-tests    allow mknod in the container by default (and potential udev problems) Update mountall to not require our current /lib/init/fstab hack Community requests?

* Nepomuk by default? * KMail2/Akonadi * Akonadi off by default (calendar integration)? * QT_ACCESSIBILITY * LightDM?

We want to discuss the plans to start growing an Ubuntu app developer community

Supporting large scale testing of kernel trees and defconfig in the LAVA lab is a high priority engineering effort across all Linaro engineering and Landing Teams for Q4.10. This organization wide effort imposes a growing list of requirements that LAVA team has started to work on during Q3 and will focus on driving forward during the Q4.2011. This effort involves improvements to the lava dashboard to ensure that the build and test results data can be efficiently consumed by kernel engineers improvements to the lava dashboard to make it easy to follow every step of a submitted job from the scheduler to the job submissions step. increase of capacity for all LEB board types deployed in the lava-lab to a level suitable to continuously track 20+ kernel branches with multiple defconfigs each. improvements to lava job submissions tools that make it easy for services like the kernel CI service to hook link from their build page to the scheduler job and the results. The goal of this session is to discuss user stories around LAVA components for driving continuous integration testing and results tracking through LAVA. Session Notes: Currently the kernel is cross built in ec2 by jenkins -- build results are submitted to the dashboard and if successful a test is run in LAVA. http://validation.linaro.org/lava-server/kernel-ci-views/index attempts to convey a summary of the results. Current process of getting your own tree is manual - talk to Deepti to get your tree included. Wishlist: Want to able to use the set up topic trees for temporary testing. Maybe need to make it easier for KWG devs to set up trees for themselves We might want to use per-user configs so that users can select the trees/configs they care about Per-user reports and a web form so they can submit git tree, branch and config for a one-time or regular testing of their tree per-tree specification of tests to run Determine which tests to run with the new kernel: ACTION: mwhudson to submit mp to change this ltp hw enablement tests PM functional tests Store the kernel version (uname) so that we can cross-reference this Build results notification (by email, RSS feed) Can just do this in Jenkins for now Want to do this in LAVA RSS ok for now Weekly build-status digest email for the community? Deepak to do this manually for now John's builds don't appear on the tree view Waterfall view perhaps not appropriate for one-time builds Should use tags for grouping results (now that tags exists) deepti to change jenkins jobs to use tags Add tagging support to dispatcher so the results get tagged similarly View for test/build combination Easy way to see last successful build for a test/build Waterfall-ish view of test suite vs test/build history Also improve bundle view Anti-wishlist: Builds of out of tree configs Basically, developer should commit the Kconfig changes to the tree ACTION: start tagging build and test results (with LAVA tags) Figure out how our read-only tags look like (since tags cannot be changed afterwards). Mouse-over git-describe: show the shortlog

In this session we will talk about device tree on Android. Description ------------------ Linaro has a goal of creating a single runtime image that can run across SoC hardware. The Android team is supporting this effort by using a common Linaro Android tree as a base for all our trees and working to unify all the SoC trees into one. Once unification is done, device tree will allow us to re-factor basic support that was once compile time configurable into runtime configurable options. Having this support on Android early will help us towards this goal and ensure that our kernels can boot as device tree becomes more widespread. Linaro Kernel WG and OCTO have worked on getting Device Tree support accepted into the mainline kernel, and initial support for all recent member SoCs is available. Ubuntu images are already using Device Tree; the next logical step is to make Device Tree be used by default in Linaro's Android LEBs. This feature requires improvements to the Linaro Android builds to enable production of binary flattened device trees as part of the platform build. Also required is updating installation tools and u-boot to ensure that the FDT is used during the boot process as needed. Additional fixes in Android-specific kernel and driver code may be required. Acceptance Criteria ------------------------------- 1. LEB Android builds come with u-boot and kernel that have device tree support enabled 2. LEB Android builds include appropriate flattened device tree in the 'boot' artifact 3. Installing LEB images using linaro-android-media-create will yield an image with device tree being used by u-boot and kernel See https://linaro.papyrs.com/page/4112/ANDROID2011-FDT-LEB for the original description. Agenda ------------ TBD Goal of this Session ----------------------------- To brainstorm and generate concrete work items for landing device tree in all LEBs.

Planning for upstream merges of OpenGL ES 2.0 support for the compiz window manager, the Unity plugin to compiz and the nux library upon which Unity depends. Additional consideration will also be given to any issues specific to integration of these features into the "P" release.

Linaro STE meeting

Review of the kernel configuration for P. This will concentrate on confirming the policy for various option types, as well as new options. For major new options, discussion and confirmation of the selection of each.

Discuss improvement for users experience, what can be done (default applications, patches, ideas ...) Initial draft of work items is available on https://wiki.ubuntu.com/Lubuntu/Developers/P-Plan#Spec_User_experience

With the proliferation of new clouds vendors, there is substantial risk of inconsistent user experience on different clouds. Trusting vendors to pull images may not be a reliable assumption. For example, vendors may not see the value in publishing a new release day, refreshed cloud images, and/or a standard user experience assumes that cloud vendors will pull the images. I propose that owing and controlling the publishing of the cloud images provides substantial value to both customers and partners. Leaving vendors or the community to handle populating images on the "greater Cloud" could result in Amazon being the gold standard for the customer experience, with lesser, incomplete or missing experiences on other cloud vendors. If we choose to maintain official ownership over our images on major vendors, we either need to build a publishing systems, provide pull scripts that our partners will run, provide a public glance server or some combination. This meeting it to discuss the strategy and come up with a basic plan of action.

Private

= Problem Statement = At present, there are 101 SystemV services in the Precise main archive that have not yet been converted to Upstart jobs(*). This needs to be recified. = Important services that need conversion = This is a selected list, but the following are important services that we could start with: - rabbitmq - open-iscsi - bind9 - apache - postfix - puppet - postgresql - tomcat6 - memcached = Rationale for Change = - Upstart is our init system of choice (SystemV is considered legacy). - Although Upstart does handle SystemV jobs, undesirable behaviour can and does result when there exist relationships between SystemV and Upstart jobs. - Upstart jobs are easier to maintain than SystemV jobs. - Upstart jobs are simpler than SystemV jobs. - Upstart jobs place the burden of managing certain repeated tasks on Upstart, rather than requiring each SystemV service to re-invent the wheel (often badly). - We wish to segregate SystemV jobs from Upstart jobs to optimize system shutdown. - See http://upstart.ubuntu.com/cookbook/#critique-of-the-system-v-init-system - To allow Upstart to be fully integrated into Debian, SysV services scripts *and* Upstart job files need to exist for a package. = Proposal = - Muster Community interest in an effort to port the remaining SystemV jobs to Upstart: It's a great way to learn Upstart! - Consider having an online sprint to concentrate on this activity for a few days(?) - Identify individuals who can help out when questions arise (jamesodhunt, spamaps, vorlon, etc?) - Leverage the work done in Fedora to migrate away from SystemV. - Concentrate on the most popular services first. - Review all Upstart jobs. - Thorough testing required. = Questions = - Aside from time, what is slowing down the conversion activity?:   - lack of examples? (We can blog and provide wiki examples)   - lack of familiarity with upstart job syntax? (We can hold education sessions)   - lack of ability to test the Upstart job versus the SysV service? (QA may be able to help here?)   - concerns over migration to "alternative init systems"? (there are no plans to switch)   - other? = See Also = https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-upstart-convert-main-initd-to-jobs (*) - this number has fallen from the 122 SysV services in natty, so the number is falling slowly :)

In ubuntu ARM mostly developer boards are supported. Target of this programme is to: a) involve more community across the board in the ubuntu arm world b) have the community select a device for adoption in the next cycle c) help the community with the implementation for this device (image building etc) d) have the community take over the maintenance of the resulting image

Ask Ubuntu is an up-and-coming source of for Q&A in the Ubuntu Community - lets figure out how to integrate it into the community at large!

We'll be presenting new features planned for 12.04 and hopefully we will be looking for support to implement the scrollbars on different toolkits.

It'd be worth to discuss the list of open issues of our developer documentation and review the results of the recent survey.

How can we leverage and easier Unity testing from the community? How make them reporting high quality bugs? How can we make the barrier lower to contribute?

In this session we will talk about the Linaro Android QA process. Description ------------------ The Android QA process tests high-level functionality, characterizes failures and files bugs against likely subsystems. The current set of tests are listed here: ADB ADB over USB ADB over Ethernet All ADB commands Boot and Basics u-boot serial support android console output over serial android console shell over serial android boots to console shell android boots to UI Audio HDMI audio Audio output on jacks Audio input on jacks Video Out - HDMI All resolutions work Monitor recognized Best resolution automatically chosen Monitor hot-plug Video Out - DVI All resolutions work Monitor recognized Best resolution automatically chosen Monitor hot-plug Graphics Not-Accellerated Accellerated 2D Accellerated 3D Ethernet Ethernet configurable from command line Ethernet auto-configured at boot Ethernet integrated into Android connection manager Wireless Onboard wireless configurable from the command line Onboard wireless auto-configured at boot Onboard wireless integrated into Android connection manager Bluetooth Bluetooth available from command line Bluetooth integrated into Android Bluetooth framework Scanning devices in UI works Pairing with headset in UI works Modem USB modem works for the command line USB modem works with the connection manager SD SD-card mounted through fstab SD-card can be accessed through gallery Camera Capture works Save works Gallery display Video Playback Software Playback Hardware accellerated playback Playback all supported formats Powermanagement Suspend and resume Wakelock works clock tree in debugfs P-states (cpufreq driver) C-states (cpuidle driver) powertop App Support Can install apps Browser Calculator Calendar Camera Clock Contacts Email Gallery Messaging Phone USB Host USB Keyboard USB Mouse USB Device Gadget driver loaded Mass storage function (sdcard export) Ethernet function (tethering) Agenda ------------ 1. Introduce the current QA process 2. Brainstorm Goal of this Session ----------------------------- To share the current QA practice and get input on how to make it better.

Tests of client/server and distributed systems via LAVA requires the ability to launch and coordinate actions on multiple target machines. We should discuss the ways people would like to use this, how to specify something like this sensibly in the test jobs, and the interaction with other LAVA components such as the dispatcher. Session Notes: use cases * client/server functionality * performance - nuttcp over network topologies * stress - use client systems to generate load on a server - requires feedback from both sides Testing systems that have shared resources like a san Changes proposed for lava * Target specification (for more than one target) * result reporting separated by target * inter-client concurrency, synchronization, client actions, data sharing and config defines client groups with a name for the group, and specific targets specified * what if want a number of devices of a certain type rather than individual clients? * scheduler would need to somehow make sure *all* systems in a client group for a job are available before running ^^^ Or, alternatively, provide a way to request and script jobs for classes/types of machines rather than specific machines * make actions something that can be installed from out-of-tree source * extend results to allow hw/sw context for additional machines? * Which existing actions, such as deploy, would need to be modified to work on groups of machines? Steps to implementing this: Defining multiple targets * specified or by type * scheduler allocation Dispatcher handling of multi client/context * does this work with new client/connection split in trunk * synchronization action Test actions * pluggable actions * defining generic ones? * API for defining test results? Results aggregation * would see all the results pre-submit, and be able to modify or add to them

Howto

This Summit brings together the different players with the aim of helping ensure that Linux based ARM servers can be brought to market as soon as the hardware is available.

Linaro STE meeting

Grow this site

SRU testing is about validating that package updates don't introduce problems on stable releases. The testing includes regression testing performed by the QA team, security testing by the Security team, certification testing by the Certification team and verification by the Kernel team. There is also some testing performed by the Ubuntu community coordinated by the QA team, but this is mostly achieved on a best effort basis. The purpose of this blueprint is to increase community participation and include their successful testing rather than just bug reports. The current process for getting community participation is by commenting on the bugs fixed by the SRU when the package is building for the proposed archive. The comment describes how to enable this archive where the package will be ready in a few hours and then asks the subscribers to please test with feedback. Another process specific for kernel packages is for development releases to be announced on voices.canonical.com and proposed kernels may also be announced eventually. As can be seen from the pending SRU reports, this has not resulted in much participation and the responsibility then falls upon the QA team. The first objective is to increase community participation for proposed kernels. The most significant value is to increase the probability that verification testing is performed by someone in the community within a reasonable delay. As a side effect, another value is to relieve the QA team from some testing which can otherwise result in additional delays. The SRU release team would benefit from having more people testing with minimal delays to push a new kernel from proposed to updates. The second objective is to include successful testing from the community rather than just bug reports. This will enable the SRU release team to also consider the number of people having tested the proposed kernels in addition to their existing reports. This should result in greater confidence before pushing a new kernel from proposed to updates. This is the story to achieve both these objectives: 1. A kernel is added to the proposed archive, so the user is notified that a new kernel is available; 2. The user opens Update Manager where she is informed that the kernel can be tested after rebooting; 3. After booting for the first time with a proposed kernel, Checkbox prompts the user to run the SRU suite; 4. If a test fails, Apport is invoked and tags the bug with "regression-proposed" for the current reports; 5. After testing, all test results are submitted to Launchpad where additional reports can be generated.

We should start creating Ubuntu API specification and documentation. At the moment if someone wants to write an application for Ubuntu, he has to search the web to know how to do common things. For example: how do I empty the Trash? How do I add my application to the notify area? How do I create a Control Panel window setting? More information on the wiki: https://wiki.ubuntu.com/UbuntuDevelopmentAPI

Printing out of desktop applications is done/managed by very many different dialogs, mostly depending on which GUI toolkit is used for an application. Some applications like OpenOffice.org have even their own dialogs. This is confusing the users a lot, having them to do the printing operation in many different ways. In addition, many dialogs are missing important features. Finally we got the project of implementing the Common Print Dialog funded and so it will be turned reality in Ubuntu Precise. See also: https://launchpad.net/common-print-dialog-gtk https://wiki.ubuntu.com/CommonPrintingDialog http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog

NDA discussion between Linaro and ARM

We have many reports that help us keep track of automatically-detectable problems in the development release (FTBFS, NBS, component-mismatches, the conflict checker, the transition tracker, etc.). These are all well and good, but they are rather disconnected from each other and in many cases do not provide very good facilities for distributing work among developers. If we want to drive these reports consistently to zero, some time spent on infrastructure would be worthwhile. What can we do to improve matters?

Automated ISO testing runs daily during the current development cycle; we need to re-align to cover more types of install testing including better LVM, RAID and iSCSI root testing and cover new aspects of Ubuntu Server such as Orchestra.

FreeRDP and Remmina to replace rdesktop, vinagre and tsclient

We want to build upon the current resources section of the app developer site and develop it to become a point of reference for anyone developing applications for Ubuntu. Some ideas for discussion: - Review of the current IA - Compare how other developer sites structure their resources/reference sections - Feedback on the current content and structure of the current section

 * LTS?  * How to maintain quality * KDE papercuts? * starship troopers - whit?

It's been a year since we switched to Banshee and Totem has landed some major updates in Oneiric. The purpose of this session is to gather feedback from users about their experience with both apps.

The current USN database is a python pickle, which is less than an ideal database format for importing into other projects. This session will discuss what alternative database format the security team could offer.

Topics: - How to go beyond ubuntu core and linaro nano even more - Bootstrap x multstrap - How to replace the basic core package set

Discuss and planify the One Hundred Scopes project : bringing *a lot* of scopes/lenses into USC for Precise.

Right now, we're just using a single server, and deploying packages that line up with our monthly releases. As LAVA is quickly growing and becoming more and more important in Linaro, we should explore how to make it more scalable and how we can support a more agile cycle of development, testing, and deployment of lava components. Session Notes: Current performance is "decent" * LMC uses flock to serialize runs - ACTION: investigate doing this on a ramdisk - Offloading this to another machine that is not handling other dispatcher activities would be better - offload jenkins too - main host should just be for interactive things Celery needed to help us spawn workers - maybe can Using the cloud - some worker tasks with low transfer requirements could be used right away if we have anything like that - eventually, deploying web server nodes, database, etc to cloud would be possible, and keeping dispatcher local - use juju for easy deployment Measurements - collectd is running, but not terribly useful - database transactions/min would be useful - google analytics type hit rate counter - ACTION: investigate graphite and statsd - sentry monitoring for django apps - should we run in canonical datacenter for things other than the dispatcher? - deployment might be an issue there - submitting RTs for changes - could we experiment with running some secondary staging server there ACTION: Launchpad has a script that measures how long transactions run for. This should help us avoid making db transactions that take too long Postgres schema migrations are disruptive, distributed postgres might have issues with this many processes have to talk to the database (scheduler, dashboard,..) could they talk through the queue web server performance (responsiveness) database performance System load (with a notification) - investigate using nagios or new relic for this Memory/swap usage uwsgi has a feature to let you know and/or take action if a request takes longer than a given threshold ACTION: Make sure we're making use of this when we do the new deployment ACTION: Does postgres have a slow queries log? Caching * global enablement is not going to work * enable globally for anon users and dropping timeout to a few minutes would be better - measurements first * cache reports at api level * tests are cache aware because they will see the stale data - need to figure out how to turn off by testing * wall clock time is ok to check if this is improving * is there a way to measure cache hit/miss rate? - memcached could probably help measure this Sentry could be used to track lots of different kinds of errors, including deploy failures ACTION: Investigate sentry Zyga: look at getting caching enabled, celery, sentry Michael: statsd/graphite Dave/Paul: other monitoring things

Live meeting of the Infrastructure Stakeholders.

Discuss support for UEFI in the arm-linux kernel. Etherpad @ http://summit.linaro.org/uds-p/meeting/19258/linaro-kernel-uefi/

Session 1: Distributed QA in the OpenStack Project Session2: Easy Cloud Software Development with OpenStack

Linaro — Michael Hope

Steve George

freelance - Michael Edwards

Steve Bannister, ARM

This session is about turning DNSSec support on out-of-the-box in the bind9 package. One of the issues in doing this is setting up the initial key, which could get changed during the life of the LTS release. How do we deal with key rotation in new installs?

Find an appropriate test case management tool and install it, find a way to integrate it with http://testcases.qa.ubuntu.com/. 1 cycle should be enough to install the tool and get the existing test cases that is worth keeping in there, we can also pilot the usage of it within QA before we move to the community using it.

Synchronising data from machine to machine and onto your own servers or cloud providers like Ubuntu One is a very useful idea. The Ubuntu One team have started work on u1db, a project codename for an easy-to-use database API layer which can work on any platform (Ubuntu, web servers, Windows, smartphone platforms) with the existing native databases (SQLite, MySQL, API layers, everything). Here we'll present the current ideas around u1db and how it will be used.

Project Unify is a new tool designed to help integrate the Unity design bug workflows with internal and external upstreams and downstreams. If you are interested solving Unity user interface bugs, or just finding out more about how the different teams involved in developing the Unity user interface work together, come to this session.

Community Leadership Summit

Python plans for 12.04 LTS: Python 3.2 and 2.7 only. We dropped 3.1 in Oneiric and 2.6 in Precise. For 12.04 the goal is at least one desktop application destined for the default installation (i.e. CD images) to be ported to Python 3. Long term (14.04 LTS), we want Python 3.2 only on the CD, with 2.7 still available in main.

The design team is planning to run design "theater" sessions at UDS. As a general rule, the design works on Canonical projects. It is our opportunity and pleasure during UDS to dedicate some time to help with other free open source software. What is Design Theater? During these sessions, we explore a design issue that you submit to us and take it through our design process. Why should you come? We hope to take you through the design process with real life examples, so we can share our design thinking and problem solving with you and propose any solution you might like. How can you participate? You have a choice: As an observer: come an look over our shoulders as we discuss applications design issues and join in the discussion. As a participant: bring us your free software application for which you need design guidance or user experience input. We'll try to fix it for you and show you how to approach this particular problem the design way. If you are thinking of joining us as a participant, please, send us your design question in advance, if you can, so we can get the ball rolling. Send it to: charline.poirier@canonical .com Who will be there from the Design team? At each session, you will find a user researcher, a brand designer, a user experience specialist, an interaction designer and a visual designer, Come find about our process and challenge us!

As we enter the second cycle of Ubuntu Server on ARM, we must work towards addition tuning and performance options that make sense on ARM including comparing against the x86 server kernel, and changing any relevant confirmation options.

We have a prototype STM driver for the ARM Inc. System Trace Macrocell. This needs to be upstreamed and productised. Most of the initial work is in the kernel. Compatibility with TI's existing toolset is a concern.

This session is to gather feedback from stakeholders and community members regarding the custom bug listing feature.

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking sessions for Graphics and Multimedia Working Groups

Linaro now has around 40 sub-domains, all of which are perceived as individual sites by search engines. Only 5 of these are linked to from the linaro.org home page and many will not be getting significant levels of traffic. We need to bring these together into a logical structure to not only help accessibility, but also to boost our ranking in search results. We want to discuss this structure and if there is a reason to keep any of our online services as sub-domains.

Afternoon engineering and hacking session for Kernel and Power Mgt Working Groups

Afternoon engineering and hacking session for Validation and Infrastructure Working Groups

Afternoon engineering and hacking session for Platform Working Group

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Linaro Roadmap Review - Agenda TBD

This spec is to come up with ideas and methods for running automation testing on bare metal hardware (i.e. no VM). While it is geared mainly for armel platforms, there are enough x86 systems on the market that could also benefit from this. Testing should focus on server first, as it should be the easiest to implement across the widest software base.

Project Kronos is an initiative to port the XenAPI toolstack to Debian and Ubuntu in order to deliver all packages that are needed to run the Xen Cloud Platform (XCP), via Debian and Ubuntu package managers. In a nutshell, all you will need to do get the latest version of Xen, the XenAPI toolstack and other components delivered in XCP is to execute "apt-get install xapi". This blueprint involves the necessary work to ensure Kronos is installable from the Ubuntu Universe archive for 12.04LTS.

Optimizations that could be done during Precise cycle Initial draft of work items is here : https://wiki.ubuntu.com/Lubuntu/Developers/P-Plan#Spec_Clean_house

Having playlists shared between music players and between machines would be a great idea; make a playlist on Banshee on one Ubuntu machine and it also shows up in Rhythmbox, and Banshee on your netbook, and Ubuntu One music streaming. A standard format for playlists should be defined (m3u? pls? Something else?) and details of where those playlists should be stored, how they should be synced, and how music players can automatically read and write them seamlessly.

Community Leadership Summit

Topics: - Discuss what would be interesting to support at u-boot - Extend PXE support? - USB booting? - Splash/display support? - What might help the Ubuntu server team?

General session to discuss how and when new X.org bits will be integrated into Precise, and requirements from stakeholders. Starting with this LTS, we will be doing official X stack and/or driver backports going forward. We can work out some plans to coordinate this effort. Since this is an LTS, and since we can do post-release upgrades, we will likely want to be very conservative in selecting versions for specific packages. We anticipate spending most of our time during P on multi-monitor support and hybrid graphics (both covered separately), but if you have ideas for additional things to include in the X planning, please come and share your thoughts.

Thomas Senyk, Johanness Zellner, and Adam Weinrich from the Nokia Qt team will be at UDS to answer any questions and discuss topics such as the Qt roadmap. Thomas and Johannes come from the Professional Services area and are paricularly knowledgeable on on how Qt is used in embedded space.

Discuss the future of PowerNap based on the feedback received on conferences where it was presented lately as well as discuss previous defined features.

Action items to plan a smooth integration of elementary apps with the unity experience

Roundtable to talk about anything software-center releated

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking sessions for Graphics and Multimedia Working Groups

Discuss support for EMM4.5 specification Etherpad @ http://summit.linaro.org/uds-p/meeting/19259/linaro-kernel-emmc4.5/

Afternoon engineering and hacking session for Kernel and Power Mgt Working Groups

Afternoon engineering and hacking session for Validation and Infrastructure Working Groups

Afternoon engineering and hacking session for Platform Working Group

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Linaro Roadmap Review - Agenda TBD

Community Leadership Summit

Linaro Roadmap Review - Agenda TBD

The Nokia Qt team would like to showcase how Qt is used in the embedded space. They'll be bringing a board running Qt on Ubuntu Core and talk about various open source and commercial/consumer products using Qt in non-desktop space. They will discuss how Qt roadmap is OpenGLES 2 centric with Qt3D, Qt5 Scenegraph, Shader effect enablement and other efforts. These efforts also have important implications for empowering the desktop.

Some features were rolled out during Oneiric to make the weekly release meetings more efficient for tracking features and bugs of interest to the release team, but more improvement is needed.     Features via Topics in: http://status.ubuntu.com/ubuntu-oneiric/     Bugs of interest to release team in: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html Would like to discuss elements of what is useful for each team to share, and how the round table can be made more effective for the participants.

During Ubuntu installation or oem-config firstboot, if a network is present then add an additional step in the workflow to either enter Ubuntu One credentials or to sign up for a free account.

We've had useful discussions about refactoring flash-kernel in the past, but they've not not (yet) come to fruition. Where are we up to, and when can we get things done? Other packages and image builds should be depending on this work, but cannot yet.

A session to go over the new acceptance criteria in more depth.

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking sessions for Graphics and Multimedia Working Groups

Continue discussion of EMMC 4.5 and UFS

Afternoon engineering and hacking session for Kernel and Power Mgt Working Groups

Afternoon engineering and hacking session for Validation and Infrastructure Working Groups

Afternoon engineering and hacking session for Platform Working Group

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services