General discussion session about all topics related to LibreOffice packaging and goals for Precise.

Plans for the software center server side improvements

Currently all certification testing of kernel SRUs is performed in the Certification labs on systems connected to the labs 'satellite' servers. This allows systems to be configured to netboot and then be setup to perform SRU testing via preseed commands. This is a very efficient and flexible configuration for the Hardware Certification team to perform its duties and allows well over a hundred systems to be tested in the space of a few days. The major drawback with this method is that because the infrastructure is so complicated (not just software but servers and network equipment are required) it is next to impossible for just anyone to perform SRU testing in the same way that the Hardware Certification team does. There is also the sometimes encountered problem of systems that do not like to PxE boot (an essential part of the current process) thus stopping them from being SRU tested, even by the Hardware Certification team. The solution to these problems and the goal of this blueprint, is to have built automatically a CD image which contains all of the elements necessary to test each SRU for each release. This will obviously include the -proposed packages, but also the tools and settings normally used by the Hardware Certification team to do the testing. Creation of this image will have several benefits, the most obvious ones being that other parties can perform the testing as and when they wish and that systems which cannot PxE boot can be tested instead using the custom image. The other benefit is that the update phase of testing doesn't need to be done for each machine on demand as it is at the moment, but can be done just once when the SRU becomes available. The Offspring (https://launchpad.net/offspring) build system will be investigated for use as the tool to create these images and control access to them.

Private

Linaro and Renesas meeting

ST-E

The current install experience for Ubuntu Cloud Infrastructure is less than optimal: - lack of discoverability - many steps - lack of clean documentation We need to identify what, when and how to improve this, specifically for Ubuntu Cloud Infrastructure and in general for products delivers via orchestra + juju

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.

Thursday

Thursday's security roundtable

As proposed in http://netsplit.com/2011/09/08/new-ubuntu-release-process/, we should create an unpublished release pocket that stands as the gateway to the regular development branch. From this branch unit tests will be run, code review and sign off will be checked, system integration tests will be run, and if any of these fail, the upload will not be copied to the development branch. We should unpack and run the unit tests for any reverse dependencies of the core libraries during package build in order to prevent breaking said dependencies with a dodgy upload. For example, an upload of GTK+ should trigger the unit tests for ubiquity and software-center to be run.

QA Requirements for submitting automated tests into the QA lab - Test outputs - Resources - Jenkins

Multiarch cross-dependency satisfaction (as currently implented in apt) needs -dev packages as well as plain lib packages to be make multiarch-ready and thus co-installable. This process is not yet well-specified like the library conversions, and it needs to be for package maintainers to be able to do this work. A related issue is changing whether the default of apt-get build-dep -a is to install for HOST or BUILD arch. The latter requires making library and -dev packages Multi-arch: same, the former requires marking all other build-deps Multi-arch: foreign. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646288 for discussion, along with the table at the bottom of: https://wiki.ubuntu.com/MultiarchCross Things to cover: Change apt build-dep -a behaviour? Guidelines for -dev conversion:  header moving  binaries (foo-config)  what else?

We want to provide Monthly Engineering Views on status.linaro.org. Alexander can provide information about this. Initial Requirements for Discussion are here: https://wiki.linaro.org/Platform/Infrastructure/Specs/MonthlyViews

In this session we will talk about adding standard Linux developer tools to Android. Description ------------------ To improve the tools available for embedded developers that care about the core platform, kernel and user space code, the Linaro Android Platform team considers it important to provide tools commonly used by low level GNU/Linux developers. We continuously monitor and identify areas where porting and integrating those tools with Android will benefit the overall Android community. Discussion and reviews lead us to believe that focusing on the binary debugging front would be the most useful next step. The first part of this effort will be a research project that reviews debugging tools commonly used by embedded Linux developers, checking for applicability of those use cases to Android. We will also identify equivalent tools or gaps in the offering of the stock AOSP NDK and SDK. Potential candidates taken from pre-discussion that this research project will pay special attention to are: oprofile perf valgrind powerdebug Based on the findings from the effort above, a priority ordered list of tools will be defined and the engineering plan expanded accordingly. Acceptance Criteria ------------------------------- 1. Results of the research project with a significant list of tools for porting are published 2. Debugging tools identified are integrated and available in Linaro Android Images or the NDK See https://linaro.papyrs.com/page/4115/ANDROID2011-DEVTOOLS-1/# for the original description. Agenda ------------ Give a quick overview of what is already there (and what theoretically should be there) Discuss what other tools we need (and what tools are realistic to port) Best way to get there [see rsalveti comment on the BP whiteboard] Goal of this Session ----------------------------- To identify the tools Android needs and brainstorm and generate concrete work items to integrate those tools into Linaro's LEBs.

What kinds of things could we add for enabling more tests and better testing? Some ideas are things like: * Jtag * wifi APs * audio connections * USB devices (would something like a usb stick in every board be useful? enough? too much? not enough?) * hdmi capture Session notes: Andy Green said that he doesn't want to commit regressions to public git did casual testing adhoc testing on his own, has tried to formalize when these things worked, which branch was tested, making an html table of these testable things as a text file sounds like a use for lava-qatracker as these are mostly manual tests Are there improvements we could make that would make it possible to automate these things? Tests we would like to be doing: audio capture can do this on the same board even hdmi capture, even video there is a card (black magic design) for roughly US$175 do these capture EDID? can you fake EDID? bootloader testing power management testing Anticipate to have first samples from Dave Anders in December for these devices a crappy ammeter will still be useful for catching regressions varous things involving JTAGs usb gadgets simulate attaching and detaching keyboards and mice? want to test both modes of OTG port on panda, ethernet is a host usb asset, and this is true of many other boards as well, so it's more important to test the musb WIFI AP connect/disconnect/traffic zyga concerned that it might be flakey Andy said that in his experience it's not so bad with wifi/bluetooth Bluetooth? Have something it can pair with and do something bluetooth access point and do obex push may be limited to 7-21 devices or so per AP device that converts serial to keyboard input ~$50 Add back scheduler ability to support tags on devices so that we can describe the capabilities needed Can we provide a framework for allowing others to do some of the work? Can we coordinate with Canonical's HW testing teams? Andy's opinion of priorities here: hdmi - this seems to break frequently audio wifi to a much lesser degree, because his patches don't risk breaking this so much ACTION: Talk to ricardo, deepak about the testsuites they are working on and their sense of priorities also 199$ HDMI + analog + audio capture card with linux support: http://www.blackmagic-design.com/products/intensity/ bootloader testing - implement soft solution now, evaluate HW solutions to see if we can do this universally

Purpose: IVI and ARM - discuss the Ubuntu Core IVI remix release Day - Friday 04 November, 09:00-10:00 Preliminary Agenda - the state of the art around Ubuntu Core IVI remix - how does the remix stand with regards to ARM based platforms, how can the ARM support can be improved further - draft a course of action related to possible future activities - indicate a possible communication plan to discuss IVI further, perhaps even a future event meeting

We have a weekly development update already, so it can serve as a good piece of news infrastructure. We need to put the project on broader feet and figure out submissions processes, etc. Also are we going to talk about new interesting news bits we might want to include.

How will we build the list of desktop bugs that we think we should work on the during the LTS cycle? The current list from Pedro and Qa are a nice but they only cover selected set, how do we get visibility on i.e foundation issues, kernel bugs, plymouth issues, etc that impact on what we are doing?

There is a good codebase of test cases already automated or suitable for automation in the QA Regression Testing project. With additional specifications created and implemented, the tests could be a valuable automated regression testing tool.

Private

Private

We need to identify areas where the Ubuntu documentation is lacking, improve our own documentation of how to get involved, and advertise to recruit contributors to help fill in the missing documentation.

Just a brain dump of some of the ideas we discussed so far:  - LTS release  - Improve LTSP live  - Re-base installer step on current LTSP live  - Fix package selection to work with all locales  - Add directory integration step  - Refresh artwork  - Switch away from iTalc  - Get Wubi working  - Upgrade website to Drupal 7 - Migrating to dh_python2 for everything on the DVD

With 11.10 we released a localized image for China. This image contained many customizations to make Ubuntu more appealing to users in China. This included significantly improving support in CJK languages, adding gwibber plugins for services popular in China etc. There are still some improvements that can be done to cary this work forward for our Chinese community.

In Ubuntu we made a lot of effort to get Orchestra. The purpose of blueprint will keep track of the work needed to be done in Precise for orchestra.

Currently, the teams are separate for en_AU Ubuntu packages and Launchpad-hosted packages. Due to the nature of en_AU not differing a lot from en_US, it may be beneficial to merge the two groups to consolidate efforts and membership.

Executive Summary: The main idea is to make discovery of Ubuntu community automatic, and not an accident. Community is meant in the whole and general sense of "anyone who uses or contributes to Ubuntu." Problem Statement: "Houston we have a problem." Most people who have discovered Ubuntu community have done so accidentally. Most people (who are on the other side of the chasm) have no idea that community is central to the growth and development of Ubuntu. Most people have no idea whether others in their town/city are using Ubuntu. We need to make community obvious and make community formation easy. Proposal: One possible solution is to create a "Community Lens" or (similarly obvious desktop element). Make it prominent. Connect it to one's local community, beginning with those who use and enjoy Ubuntu in our town/city. Over time, expand it to include additional nearby non-Ubuntu social connections: family, friends, neighbourhood, city...

Currently, installing images on Versatile Express is a weird procedure with many manual steps. This impairs testability and makes life difficult for users. Kernel package upgrading also does not work smoothly. The aim of this session is to explore options for a less weird, more convenient and more robust deployment mechanism. Topics include: * Getting closer to full SD-based boot * Firmware-based image reflashing

Planning for a Linaro graphics working group project to do a webkit port that leverages prior work on the OpenGL ES 2.0 backend for cairo. Link to requirement: https://linaro-public.papyrs.com/public/4146/GWG2011-WEBKIT-CAIRO-GLES/#

This will be the second training session on how to use the new Rypple tool for Linaro employees, secondees, and assignees. Everyone in Linaro must attend one of the sessions

Planning session for integrating UCM support into PulseAudio.

This session will give an overview of how Linaro's Android platform is developed. It will talk about Gerrit, LAVA, pre-merge, QA, opportunities for development, goals of the platform and give a run down of PoCs.

ARM Fast Models and QEMU can be used to simulate ARM based computers at speeds high enough to perform some builds and testing. The Infrastructure team would like to discuss how we can use models to supplement real ARM hardware.

This session is about discussing the current status and issues with eCryptfs, and making a decision what needs to be done in order for it to be an appropriate install-time option in the LTS release.

From Oneiric on we are using GNOME 3.x and from this GNOME version on there is a printer setup tool in the Control Center. This tool is new and has much less features than system-config-printer and especially does not contain all the functionality for selecting best drivers, identifying network printers, HPLIP integration and so on. So dropping system-config-printer in favor of GNOME's new tool will be a major step back. Discussion has already started on the OpenPrinting Summit in April this year (see link below) and on the UDS for Oneiric. Here we will continue discussing the situation. https://www.linuxfoundation.org/sites/main/files/system-config-printer-status.pdf In Oneiric we have continued to use system-config-printer, patching and configuring gnome-control-center and the system menu so that system-config-printer is started in its own window instead of the capplet of the control center, at least for Unity desktops. For Precise we want to use the original GNOME tool but an improved version. For this Tim Waugh, upstream author of system-config-printer has already put all algorithmic parts of system-config-printer (identifying CUPS' printer auto-detection results and finding out which are from the same physical printer, finding best driver, prioritizing drivers, HPLIP integrations, ...) into a D-Bus service which any other printer setup tool, independent of the programming language in which it is written, can use. This way the GNOME tool can be improved to have the needed capabilities to make printer setup easy for everyone. No the printer setup tool needs to be modified to make use of this new D-Bus service. Depending on how far the tool gets developed, we will make it the standard tool in Precise and this way have one standard printer setup tool with perfect integration in the System Settings in both Unity and gnome-shell environments. See also: https://bugzilla.gnome.org/buglist.cgi?component=Printers https://bugzilla.gnome.org/show_bug.cgi?id=654742

Private

Private

Linaro and Canonical meeting

How are we going to manage community submitted charms? Peer review? etc.

Meeting of release team to do some brainstorming on things to be improved in next cycle.

This will detail the plan for the Council for loco teams, approval, any new guidance pages to be written, goals to help get locoteams more involved in the community

Fregl tells us how to make it not crash

This session is a demo and requirements review of the new tool Test Manager

Topics: - Describe what is currently supported at the cross-buildd - Go over the issues, discuss about how to improve it, and what kind of features do we want to improve/develop More info at: https://wiki.linaro.org/Platform/DevPlatform/CrossBuildd

Session for getting camera header installed for pandaboard - solder experience required, or maybe a experienced volunteer can do it?

Session jointly led remotely by Vincent Guittot and locally arbitrated by Tony Mansson. In this session we will talk about how Android can exploit the benefits of full Idle Support.

The Linaro Wiki can be both a great source of information and a great source of frustration. We'd like to have a discussion about improving some of the big issues. We have a preliminary set of topics on the etherpad for this session.

All the open issues that need to be fixed lo-menubar integration into main.

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

During 12.04 development we will strive to ensure that Ubuntu Desktop works each day so that everyone can reasonably make progress with their development goals, rather than being blocked by poor quality in different areas of the product. The flow as I envision it would go: 1. The ISO is testing in the morning for Europe 2. If the ISO is found to be acceptable, the QA reports such 3. If the ISO is found to be hard to use or test, the QA team reports as such 4. Ubuntu Engineering then investigates which package caused the breakage 5. The package that caused the ISO Is reverted 6. The ISO is rebuilt and step 1 starts again

Discuss ways to sync ebook user data (bookmarks, notes, reading position) between ebook readers using Ubuntu One.

Addressing concerns from community members about (lack of) involvement in user experience and design, and concern from designers that they only have time to work on a tiny fraction of the Ubuntu user experience (in the shell). Exploring practical steps we can take, so interests get paired to tasks, and the whole user experience of the distro is improved.

Plan the enhancements we want in apt for precise

The QA CoP would like to see the following data points available for reporting on the default interface for the Lauchpad Results site. Requirements for Test Results Dashboard Testrun: Regressions (previously passed now failed) https://dev.launchpad.net/Testing#Iterating%20with%20testrepository Fixes (previously failed now passed) e.g. http://qa-reports.meego.com/1.3/Core/Auto/Netbook Tag test runs Show test Results by categories/suite if applicable (see http://qa-reports.meego.com/1.3/Core/Sanity/Netbook/3173#detailed_results) Plotting of results (benchmark, performance, trend reporting), based on query parameters Hardware target information (structured, like devices, and unstructured, like log files as attachments) Software versions (packages, distro, bios) TestResult Test case Status (Pass, Fail, Skip, Blocked, Unknown, Untested, Unsupported, Error, Bug) Test case run time (Elapsed(Min), Time Stamp(Milisecond)) Test case output (stdout, stderr, status code, log files) Test case result(s)/data/measurement(s) Add comments/bugs from the interface Offline submission from local file (default protocol with result2launchpad) (DONE) Generation of regression test files (whitelists for checkbox) Advanced search of cases (Elapsed time, recently failed, hardware used, tags)

Presentation and discussion of the features and fixes the Juju team intends to deliver for the Ubuntu 12.04LTS release

Topics: - Go over the issues we had during the Oneiric cycle - 1 month x 6 months cycle - Feature planning (present how Linaro plans the engineering work) - How to manage SRU and FFe - Package upload (should we create a Linaro upload group for Linaro packages?)

Discussion of how we map upstream-oriented kernel development to the Linaro process Etherpad @ http://summit.linaro.org/uds-p/meeting/19264/linaro-general-upstream-process/ Problem definition, scenarios and proposals https://docs.google.com/a/linaro.org/document/d/1Inj3Esvk4Lbqe5PN7NHnK1WKRaM_5e9B6htKN6hDBqk/edit?hl=en_US

This will be the second training session on how to use the new Rypple tool for Linaro employees, secondees, and assignees. Everyone in Linaro must attend one of the sessions

The Toolchain WG currently runs an extensive test suite hosted in Michael Hope's personal laboratory. The LAVA team will work with the TCWG team to ensure this setup is migrated, as-is, into the LAVA lab. We will also work to ensure that all the resulting toolchain build and test data gets properly submitted to LAVA, the dashboard providing the facilities needed to allow the Toolchain WG to analyze this data. It is expected that the reporting facilities in the LAVA dashboard will be driven and partly implemented by the Toolchain WG itself using the available extension mechanisms. == Validation lab next steps == We now have the toolchain build system running on boards hosted by validation. What do we do next, such as:  * Start capturing test results using LAVA  * Start regular benchmarks  * Capture benchmarks results using LAVA  * Shift components to Jenkins or LAVA  * Shift the x86 builds first? Every time we have a merge request, we want to test and make sure there are no regressions - They are doing this today on seabright Many tests will fail, they are interested in the delta, not the total failures This runs a test of every commit to the branch 1 test on v7 1 test on v5 (but they don't have v5 hardware so they test on v7 x86, x64 1. create scripts for the test suites that run right now 2. create results parser that will let us get those into lava dashboard - or at least make sure the existing one works 3. poll launchpad, find the merge request we need to pull, create tarball, create job in lava with that tarball location as a parameter (template for this testing that gets filled in) (This could be part of the extension listed below) - For the merge request, we have multiple templates that kick off tests on the different hardware types needed (v7, v5, x86, x86_64) 4. create lava extension for visualizing results and comparing tests to the baseline (merge request should be able to figure out what was HEAD, and we can compare against that) ACTION: mockup needed for visualization ACTION: investigate using the ssh client to run this test in a chroot, they do the 32bit testing on a 64bit machine in a 32bit personality chroot ACTION: zygmunt to see what we can reuse from tarmac - email notification of jobs startig could be done with tarmac also - there should be 2 comments, when starting and when finishing this part and the job is about to be created - also send link to the scheduler job so they can cancel if they see something wrong Hardware considerations: USB Sticks and scheduler support for tagging those machines Do we need swap enabled on those machines? Benchmarking =========== Needs a customized rootfs that is consistant and stripped down - make sure there are no extraneous services running project for building, keeping attachements of the binaries that we built, etc They can submit a branch for pulling a branch they have, pulling it, and building it The resulting artifact can be used in the benchmarking run IMPORTANT: for private tests, we also need to have private scheduler jobs so that the raw output is not public also B we benchmark on a8, a9, and a15 eventually They can build it and point us at the toolchain, or we can build it as part of the run - if we bould it, it should be built and feed into this Next we want to run the benchmark with build parameters some of their benchmarks need to be private because of licensing - and results need to be kept private

Evolution of ARM ABI

Monty Taylor

RedHat — Matthew Garrett

Ara Pulido

RedHat — Matthew Garrett

Jeremy Kerr

Linaro — Grant Likely

Linaro — Deepak Saxena

Prepare for the lucid -> precise LTS upgrade * testing * backporting apt from oneiric/precise to lucid for multiarch enabled upgrades * dpkg-maintscript-helper not available in lucid, used in preinst scripts: need some archive analysis to catch these issues and make sure they won't impact upgrades

Since Unity has been introduced, many strides have been made with accessibility. Unity 3D is approximately 80% accessible, so far as official oneiric packages go, and unity-2d is 99% accessible, thanks to the great work from the QT a11y folks, and the unity-2d developers. Both are likely to be 100% accessible for the LTS, which is great. However, they are not the only areas of accessibility that need improving. I have already started making a work item list of issues to address, to give the desktop more pollish when it comes to accessibility. Such issues include: * Making sure all indicators have accessible descriptions/labels. * Making sure any icons in indicator menus that need accessible descriptions/labels have them, a prime use case is network manager, to indicate wireless network strength. * Further pollish on Ubiquity's accessibility, particularly selecting a timezone. * Connecting up the rest of the accessibility profiles in the ubiquity a11y indicator. * Further pollish of the unity greeter accessibility experience. * Make sure the accessibility experience between unity 2d and 3d is the same. The list I have is slightly more technical and goes into more detail, but what is listed above is the gist of what I have. Whether this needs a session at UDS I don't know, but a blueprint will likely be needed for work items tracking.

There are a wide and ever growing variety of html5/web-based apps out there already and by that measure a large untapped community of developers we are not talking to. Given the issues around html5 right now, what are the things we can do now to encourage them to participate and what are the things that are stopping us/slowing us down? Why would this be good for Ubuntu anyway? What’s in it for the developers? and why ' the web standards community'?

We need to implement performance testing for ARM server supported workloads. The focus is performance compared to the amount of power consumed.

Ubuntu Leadership Summit

Discuss what works and what doesn't in our processes for new developers

There has been some very interesting ideas on improving the release process brought up by Scott James Remnant in his blog post, http://netsplit.com/2011/09/08/new-ubuntu-release-process/ Some of these we are looking at implementing for Precise (in other blueprints), other points need discussions as future options. This session is targetted to brainstorming what would be the impact of some of the more radical changes we're not going to fit into precise, since it is an LTS. Also what planning/blueprinting work should be done to assess if the process changes will improve the developer and user experience before the next cycle.

It would be nice to be able to optionally run Wayland in 12.04 to try out the technology. This will involve: - Modifying LightDM to support Wayland - Writing a Wayland compositor - Running an X server that writes to the compositor - Making it easy to enable this - Disclaiming all responsibility This would be a low priority task.

Unity is regularly tested with targets users. Results of the latest benchmark testing will be presented in this session

This session is to clarify what is a test case and what everyone means by saying test case. We will also be discussing what constitutes a good test case.

Plans:    * Merge 0.9.8? (Start with 0.9.6 now)    * should removing libvirt-bin shut down its vms and remove bridges?    * netcf    * bash completion Community requests?

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking session for Graphics and Multimedia Working Group

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

Linaro Management Rypple Training

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Technical Steering Committee meeting, agenda TBD

Provide a flexible way to filter for specific device capabilities like e.g. hardware opengl to avoid people downloading apps that will not run on their system.

Include OpenSC in Ubuntu for smartcard authentication

Juju is great at adding relationships to workloads but has no idea how to automatically scale based on compute requirements. This meeting would discuss adding intelligence and the different approaches we could use to achieve this functionality.

The process of mentoring new Bug Squad members will be reviewed as will feedback from people being mentored. A redesign of the mentorship program will be discussed.

Community Leadership Summit

  * Improvements to Muon?   * Samba install?   * Amarok etc codec install   * Distro Upgrade? 11.10 upgrade notification and 12.04 to 14.04 LTS notification upgrade

Discuss the next steps for cobbler to provide improvements, define level of maintainship, to make sure its continuum with Orchestra.

There is a huge interest in getting involved in Ubuntu development. We want to better reach out to everybody who is interested. The recent survey data will probably help with the discussion of this.

For two release cycles, gnome-session has deliberately not done session restoring on login. This is a huge stumbling block for power users, who have to spend a lot of time on each login re-setting up their work environment. This should be solved for 12.04.

Investigate whether we can work around the problems of not being able to retrace core dumps on the local system and ASLR making generating an accurate retrace without function names difficult. Being able to create a stack trace with just addresses would allow us to submit that small chunk of data to the crash database before sending the full data set. The crash database could then decide if this crash already exists or if it needs the full core dump so that it can create a new crash bucket with that retraced. Google's Breakpad is able to do this through Microsoft's Minidump format. We may be able to mimic this behavior in apport without having to link every application to Breakpad.

Discussion around Java related objectives for Precise:  - OpenJDK 7 and when to switch the default-jdk in Ubuntu  - General Java housekeeping - Maven 3 progress and transition

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking session for Graphics and Multimedia Working Group

Feedback on the LT performance

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

This session will cover all the aspects of the Ubuntu Linaro Evaluation Build development, showing how we integrate the Linaro components, how we're doing CI, testing with LAVA and also how we're working with Ubuntu upstream. The goal is to help people and other teams on how to work together with the developer team to have their own components available at the Ubuntu LEBs.

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

This is the per-cycle discussion on what should be improved in the cloud images or in cloud-init.

The Hardware Enablement Team's plans for Firmware Test Suite in the 12.04 cycle.

- using the vala rewrite for p? - no full text search - datasource to consider? - privacy concerns - gnome-activity-journal in control center.

On release day, users are offered to upgrade their computer to the latest release. However, there are a number of ways in which upgrades don't complete successfully. What can we do to make upgrades safer, more reliable and more pleasant? See bug http://pad.lv/876146

Charms need to be tested by an automated test runner on each commit to the charm store. There is a need to test each charm's use of each interface with any charms which implement the other side of the interface.

In the real world there are always going to be failures, triggered by things like software bugs, hardware failures and misconfiguration. Ubuntu should where possible handle common failures and provide predictable feedback to the user that the system is broken.

Launchpad can currently target bugs either at the distro (or sourcepackage) without any series associated, or associate it to a particular release. This model has several drawbacks as it causes confusion (bug 314432) as well as performance problems. The Launchpad team is investigating the possibility of associating all bugs with a series. This session is to discuss the user impact of such a change, and make sure it's compatible with the distribution workflows.

We'll review the activities about LoCo Testing, with the results from the Italian Team, and the Laptop testing project. We'll also discuss about the an idea in the Italian LoCo about a Triage Team with mentoring in native language and team's adoption.

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS.  * What is the best way to distribute the updated X stack?  * Will this be an opt-in change for upgraders? If so, how will the upgrader need to be changed to properly guide the user in making a choice?  * For consistency, what version naming scheme should be used for these package updates?  * Should we limit it to just the serverside portion of the X stack? (I.e. omit libX11, etc. to avoid breakage to client apps) * For certain graphics cards, there is a possibility that driver support could be dropped in future kernel and X combinations; the upgrader will need to be aware of this and not suggest the upgrade if it won't work, or perhaps make them aware of the risks or known-regressions they'll endure if they wish to proceed anyway.  * Should a way be provided to enable the user to back out the changes? If so, how should that be implemented?  * How tightly should the kernel / X package versions be kept? I.e. should we discourage or permit old-kernel/new-X and/or new-kernel/old-X setups. (If we permit these combinations it gives user flexibility but imposes a larger testing impact).

Topics:  - What is necessary to have a working multitouch demo with Ubuntu LEB?  - What kind of demo do we want/need?  - What hardware should be used, and which board should we try to support? More details at https://linaro-public.papyrs.com/public/4121/LINUX2011-MULTITOUCH-DEMO

Afternoon engineering and hacking session for Toolchain and OCTO Working Groups

Afternoon engineering and hacking session for Graphics and Multimedia Working Group

RedHat — Matthew Garrett

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

After the release of the latest version of the Linux kernel, several people have been generating presentation slides to show how Linaro is contributing to the development of Linux on ARM. Andrea Gallo has done some very good slides showing this and I would like to discuss what data is meaningful and what can be generated automatically.

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services