Ubuntu logo

Summit

Hardware

Monday 10:00 - 10:45 CET
Not Attending Kernel Round Table (Monday)
Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Participants:
attending apw (Andy Whitcroft)
attending brouer (Jesper Dangaard Brouer)
attending christopherarges (Chris J Arges)
attending david-duffey (David Duffey)
attending herton (Herton R. Krzesinski)
attending hzliu123 (Hao-Ran Liu)
attending ikepanhc (Ike Panhc)
attending narindergupta (Narinder Gupta)
attending r-herring (Rob Herring)
attending rsalveti (Ricardo Salveti)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M3 (Audio Feed) (IRC Logs)
Monday 12:00 - 13:00 CET
Not Attending Kernel Configuration Review
Review of the kernel configuration for 13.04. 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.

Participants:
attending apw (Andy Whitcroft)
attending brouer (Jesper Dangaard Brouer)
attending christopherarges (Chris J Arges)
attending ikepanhc (Ike Panhc)
attending ivan.hu (Ivan Hu)
attending javier.collado (Javier Collado)
attending joetalbott (Joe Talbott)
attending leannogasawara (Leann Ogasawara)
attending narindergupta (Narinder Gupta)
attending r-herring (Rob Herring)
attending rsalveti (Ricardo Salveti)
attending sforshee (Seth Forshee)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M6 (Audio Feed) (IRC Logs) Go to Blueprint
Monday 15:00 - 16:00 CET
Not Attending Investigation of expanding ubuntu-drivers-common to be aware of drivers provided in l-b-m packages
Often times a driver from a specific linux-backport-modules package is made available which is required for enablement (eg: a new driver from compat-wireless). It would be of great benefit to expand ubuntu-drivers-common to be aware of these updates where appropriate == TODO == This applies to Precise and Raring * [rtg] to deal with modaliases in the control files * [tseliot] Code to handle the logic when multiple driver versions are available * [tseliot] Add an entry for the default drivers so that users can go back to the default drivers once they've tried lbm * Recommend the default driver when multiple versions are available * How do we notify users that new drivers are available and what updates do we show * Input drivers : config files to pass module parameters * Should we pop up a notification even when the driver already works? We don't want to break things that work * Modify the description of the packages in the driver manager * Consider backporting this work to quantal

Participants:
attending ajenbo (AJenbo)
attending albertomilone (Alberto Milone)
attending anthonywong (Anthony Wong)
attending apulido (Ara Pulido)
attending ayrton (Ayrton Araujo)
attending ballock (Bolesław Tokarski)
attending brendan-donegan (Brendan Donegan)
attending fabiomarconi (Fabio Marconi)
attending ikepanhc (Ike Panhc)
attending josephjamesmills (Joseph Mills)
attending lexical (Keng-Yü Lin)
attending narindergupta (Narinder Gupta)
attending pitti (Martin Pitt)
attending raof (Chris Halse Rogers)
attending smagoun (Steve Magoun)
attending timg-tpi (Tim Gardner)
attending vanhoof (Chris Van Hoof)

Tracks:
  • Hardware
B3-M1 (Audio Feed) (IRC Logs) Go to Blueprint
Monday 17:05 - 18:00 CET
Not Attending Simplification of Checkbox with standalone scripts and test plans
Checkbox is too complicated. It has a plugable architecture that is flexible in some ways at the cost of being difficult to maintain. We want to simplify the architecture so that it is flexible in ways that matter to users while coping more easily changes. First, we should move the flow of the application from the prompt plugins to the frontend process. This change would make the user interface extensible independently from the backend. As a result, this would make it trivial to run a single test after completing a test run. Second, we should move the responsibility of the remaining plugins to standalone scripts. The command to call the scripts would be configurable to remain flexible. For example, this could be the command to run tests in random order:     checkbox-runner $CHECKBOX_SHARE/jobs/local.txt \     | checkbox-transform --blacklist='plugin=local' \     | checkbox-random Last, we should introduce the concept of a test plan to invalidate forking Checkbox with custom tests. A test plan would have the sorted jobs from a whitelist with their scripts, so any version of checkbox with this support would run the same tests the same way.

Participants:
attending achiang (Alex Chiang)
attending ajenbo (AJenbo)
attending apulido (Ara Pulido)
attending bladernr (Jeff Lane)
attending brendan-donegan (Brendan Donegan)
attending drussell (Dave Russell)
attending einonm (Mark Einon)
attending joetalbott (Joe Talbott)
attending lexical (Keng-Yü Lin)
attending mahmoh (M.Morana)
attending mfisch (Matt Fischer)
attending narindergupta (Narinder Gupta)
attending ove-risberg (Ove Risberg)
attending primes2h (Sergio Zanchetta)
attending roadmr (Daniel Manrique)
attending schwuk (David Murphy)
attending smagoun (Steve Magoun)
attending sylvain-pineau (Sylvain Pineau)
attending xnox (Dimitri John Ledkov)

Tracks:
  • Hardware
B3-M7 (Audio Feed) (IRC Logs) Go to Blueprint
Tuesday 09:00 - 09:55 CET
Not Attending Kernel Round Table (Tuesday)
Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Participants:
attending apw (Andy Whitcroft)
attending ben-collins (Ben Collins)
attending brouer (Jesper Dangaard Brouer)
attending christopherarges (Chris J Arges)
attending ikepanhc (Ike Panhc)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M3 (Audio Feed) (IRC Logs)
Tuesday 10:00 - 10:45 CET
Not Attending Arm Power Measurement
A discussion of best practices for measuring and reporting power consumption on low power devices. This will include software tools, lab testing environments, and tools for troubleshooting problems.

Participants:
attending brianfromme (Brian Fromme)
attending brouer (Jesper Dangaard Brouer)
attending craig.magina (Craig Magina)
attending einonm (Mark Einon)
attending gerboland (Gerry Boland)
attending ikepanhc (Ike Panhc)
attending mahmoh (M.Morana)
attending mfisch (Matt Fischer)
attending milner (Mike Milner)
attending pwlars (Paul Larson)
attending taitenpeng (Taiten taiten.peng@canonical.com)
attending themuso (Luke Yelavich)

Tracks:
  • Hardware
B3-M10 (Audio Feed) (IRC Logs) Go to Blueprint
Tuesday 12:00 - 13:00 CET
Not Attending Certification coverage for 13.04 (and 12.04.3)
The Canonical hardware certification team will be hosting a session at UDS to plan and gather feedback about the certification programme for Ubuntu and how coverage will evolve during this cycle. As both hardware support in Ubuntu and available hardware continue to evolve, we need to review the elements we test, and the amount to which we test them, to ensure certification testing continues to be relevant for modern hardware while de-emphasizing elements whose usefulness decreases with age. Ubuntu end-users benefit from this effort by having information about which components are tested in Ubuntu-certified systems, which lets them know about the kind of experience they will have out-of-the-box with a Ubuntu-certified system. OEMs can also benefit from this to ensure that tested components work well with Ubuntu, thus ensuring that their systems can get certified and a good experience is provided for users. Canonical benefits from a well-defined and discussed certification coverage list to be able to tell OEMs that the hardware they include in their systems is tested to its full ability when certifying for Ubuntu. == Session overview == The UDS session will be a forum where we will discuss: * A quick overview of a test's lifecycle: blacklist, greylist and whitelist, and how a test moves between them. * A quick review of existing whitelist tests to determine their relevance and any need for improvement. * Quick overview of all tests mentioned in the 12.10 coverage document to see how they will change for 13.04, with review of greylist tests to see which ones will make it on the whitelits * Discussion on new tests to be added (they go in the greylist first) * Discussion on sleep/resume time thresholds for 13.04 == Current greylist == Hibernate/Resume (30 iterations) MMC data cards Hybrid Graphics: if UMA or discrete work out of the box: all ports working the certification will include a note specifying which device was certified. Multiple-Monitor (where supported, multi-head display (2 heads) are tested) Wi-fi Slider (hardware rfkill) Secondary function keys: Brightness Media Control Wireless Sleep Video switch Super key (Windows key) Bluetooth Audio Vertical edge scrolling Specific USB 3.0 devices Lid sensors Lid open HDMI audio Accelerometers Multitouch devices (basic functionality) Resuming from suspend in less than 3 seconds Overall suspend/resume time of less than 10 seconds == Possible new coverage ==  * Displayport audio  * Audio settings maintained after suspend. This means ensuring that user-visible settings don't change in ways that will be confusing, like the microphone (or even speakers) muting themselves for no reason, or changes in user-adjustable volume.  * LEDs  * Bluetooth file transfer  * Bluetooth browse file  * Horizontal scrolling

Participants:
attending agoliveira (Adilson Oliveira)
attending apulido (Ara Pulido)
attending ayrton (Ayrton Araujo)
attending bladernr (Jeff Lane)
attending brendan-donegan (Brendan Donegan)
attending david-duffey (David Duffey)
attending diwic (David Henningsson)
attending ethan.chang (Ethan Chang)
attending hzliu123 (Hao-Ran Liu)
attending ivoks (Ante Karamatić)
attending kate.stewart (Kate Stewart)
attending lexical (Keng-Yü Lin)
attending mahmoh (M.Morana)
attending mariusko (Marius B. Kotsbak)
attending narindergupta (Narinder Gupta)
attending nobuto (Nobuto Murata)
attending primes2h (Sergio Zanchetta)
attending roadmr (Daniel Manrique)
attending schwuk (David Murphy)
attending smagoun (Steve Magoun)
attending sylvain-pineau (Sylvain Pineau)

Tracks:
  • Hardware
B3-M7 (Audio Feed) (IRC Logs) Go to Blueprint
Tuesday 15:00 - 16:00 CET
Not Attending Ubuntu Kernel Delta Review
Review of the current Ubuntu Kernel patch delta from upstream. This session will look at the current delta comprised of both patches to the core and the ubuntu specific drivers. The aim is to record what we are carrying, review the reasons for that component(s) to be carried, and recommend replacements, updates, cleanups, upstreaming etc of those components.

Participants:
attending apw (Andy Whitcroft)
attending brouer (Jesper Dangaard Brouer)
attending christopherarges (Chris J Arges)
attending ikepanhc (Ike Panhc)
attending leannogasawara (Leann Ogasawara)
attending lexical (Keng-Yü Lin)
attending louis-bouchard (Louis Bouchard)
attending narindergupta (Narinder Gupta)
attending r-herring (Rob Herring)
attending rsalveti (Ricardo Salveti)
attending sforshee (Seth Forshee)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M6 (Audio Feed) (IRC Logs) Go to Blueprint
Tuesday 16:15 - 17:00 CET
Not Attending Intel UEFI Update
Intel to provide an update on UEFI for through 13.04 cycle

Participants:
attending anthonywong (Anthony Wong)
attending apulido (Ara Pulido)
attending apw (Andy Whitcroft)
attending bladernr (Jeff Lane)
attending brianfromme (Brian Fromme)
attending carla-sella (Carla Sella)
attending chris.gagnon (Chris Gagnon)
attending christopherarges (Chris J Arges)
attending cjwatson (Colin Watson)
attending colin-king (Colin King)
attending drussell (Dave Russell)
attending einonm (Mark Einon)
attending hzliu123 (Hao-Ran Liu)
attending ijc (Ian Campbell)
attending ivan.hu (Ivan Hu)
attending jamesodhunt (James Hunt)
attending jk-ozlabs (Jeremy Kerr)
attending josephjamesmills (Joseph Mills)
attending kate.stewart (Kate Stewart)
attending lexical (Keng-Yü Lin)
attending mahmoh (M.Morana)
attending manjo (Manoj Iyer)
attending marrusl (Mark Russell)
attending narindergupta (Narinder Gupta)
attending nobuto (Nobuto Murata)
attending paulliu (Ying-Chun Liu)
attending pederm (Peder Madsen)
attending sconklin (Steve Conklin)
attending sforshee (Seth Forshee)
attending smagoun (Steve Magoun)
attending steve-mcintyre (Steve McIntyre)
attending torstenn (Torsten Nielsen)
attending vanhoof (Chris Van Hoof)
attending vorlon (Steve Langasek)
attending xnox (Dimitri John Ledkov)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M1 (Audio Feed) (IRC Logs) Go to Blueprint
Wednesday 09:00 - 09:55 CET
Not Attending Kernel Round Table (Wednesday)
Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Participants:
attending apw (Andy Whitcroft)
attending ikepanhc (Ike Panhc)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M3 (Audio Feed) (IRC Logs)
Not Attending Firmware Test Suite Features and Improvements for 13.04
The FWTS Development Team's plans for Ubuntu 13.04 12.10 Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-fwts-improvements

Participants:
attending apulido (Ara Pulido)
attending apw (Andy Whitcroft)
attending ayrton (Ayrton Araujo)
attending bladernr (Jeff Lane)
attending brendan-donegan (Brendan Donegan)
attending chris.gagnon (Chris Gagnon)
attending colin-king (Colin King)
attending ethan.chang (Ethan Chang)
attending ivan.hu (Ivan Hu)
attending kaja (Kaja Podlaska Christiansen)
attending lexical (Keng-Yü Lin)
attending narindergupta (Narinder Gupta)
attending sconklin (Steve Conklin)
attending sforshee (Seth Forshee)
attending smagoun (Steve Magoun)
attending sylvain-pineau (Sylvain Pineau)
attending taitenpeng (Taiten taiten.peng@canonical.com)
attending vanhoof (Chris Van Hoof)

Tracks:
  • Hardware
B3-M7 (Audio Feed) (IRC Logs) Go to Blueprint
Wednesday 10:00 - 10:45 CET
Not Attending Kernel Version and Flavors
Discussions on the likely mainline kernel version and appropriate kernel flavors for 13.04.

Participants:
attending amscanne (Adin Scannell)
attending apw (Andy Whitcroft)
attending ben-collins (Ben Collins)
attending diwic (David Henningsson)
attending gilir (Julien Lavergne)
attending ikepanhc (Ike Panhc)
attending jsalisbury (Joseph Salisbury)
attending leannogasawara (Leann Ogasawara)
attending marrusl (Mark Russell)
attending narindergupta (Narinder Gupta)
attending r-herring (Rob Herring)
attending sforshee (Seth Forshee)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M6 (Audio Feed) (IRC Logs) Go to Blueprint
Wednesday 12:00 - 13:00 CET
Not Attending ARM Kernel Flavour Selection and Maintenance
Specific discussions surrounding kernel flavour selection and maintenance on ARM reference hardware for the Raring cycle

Participants:
attending achiang (Alex Chiang)
attending apw (Andy Whitcroft)
attending hggdh2 (C de-Avillez)
attending hrw (Marcin Juszkiewicz)
attending ikepanhc (Ike Panhc)
attending jm-leddy (James M. Leddy)
attending leannogasawara (Leann Ogasawara)
attending mariusko (Marius B. Kotsbak)
attending narindergupta (Narinder Gupta)
attending r-herring (Rob Herring)
attending rsalveti (Ricardo Salveti)
attending sforshee (Seth Forshee)
attending steve-mcintyre (Steve McIntyre)
attending utlemming (Ben Howard)
attending vanhoof (Chris Van Hoof)

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

Participants:
attending apulido (Ara Pulido)
attending bladernr (Jeff Lane)
attending brendan-donegan (Brendan Donegan)
attending david-duffey (David Duffey)
attending elsawang (Elsa Wang)
attending ethan.chang (Ethan Chang)
attending hardik-dalwadi (Hardik Dalwadi)
attending lexical (Keng-Yü Lin)
attending narindergupta (Narinder Gupta)
attending roadmr (Daniel Manrique)
attending smagoun (Steve Magoun)
attending sylvain-pineau (Sylvain Pineau)

Tracks:
  • Hardware
B3-M4 (Audio Feed) (IRC Logs) Go to Blueprint
Thursday 09:00 - 09:55 CET
Not Attending Kernel Round Table (Thursday)
Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Participants:
attending apw (Andy Whitcroft)
attending ikepanhc (Ike Panhc)
attending zequence (Kaj Ailomaa)

Tracks:
  • Hardware
B3-M3 (Audio Feed) (IRC Logs)
Thursday 12:00 - 13:00 CET
Not Attending Power Architecture Kernel Development
The current powerpc kernel state is stagnant and based on there only being PowerMac and IBM P-Series kernels. With the expansion of Power into various other vendors and the availability of many types of machines, this needs to be expanded. However, this may incur patches that are not PowerPC centric, so the possibility exists where the power kernel may need to be built separate from the stock kernel package in Ubuntu. DIscussion is needed on the best way to proceed, best practices for maintaining it and best methods of supporting as many alternate Power CPUs/SoCs as possible while keeping the package maintainable. == Comment == Hi Ben, Currently the session shortname (powerpc-kernel-devel) doesn't fit the convention for the tracks. Would you be able to determine where you think this best fits? -- Daviey Changed to hardware-r-powerpc-devel -- BenC

Participants:
attending adconrad (Adam Conrad)
attending apw (Andy Whitcroft)
attending ben-collins (Ben Collins)
attending gilir (Julien Lavergne)
attending hatocorp (Jacob Okoniewski)
attending kate.stewart (Kate Stewart)
attending leannogasawara (Leann Ogasawara)
attending narindergupta (Narinder Gupta)

Tracks:
  • Hardware
B3-M2 (Audio Feed) (IRC Logs) Go to Blueprint