Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20101116 Meeting Agenda

ARM Status

  • TI – They are still stabilizing 2.6.35 based kernel for omap4. And they will probably skip 2.6.36 and move to 2.6.37 directly, but it won’t happen before December.

Release Metrics

Release Meeting Bugs (0 bugs, 12 Blueprints)

Alpha 1 Milestoned Bugs (14 across all packages)

  • 0 linux kernel bugs (no change)
  • 0 linux-fsl-imx51 bugs (no change)
  • 0 linux-ec2 bugs (no change)
  • 0 linux-mvl-dove bugs (no change)
  • 0 linux-ti-omap bugs (no change)
  • 0 linux-meta-ti-omap bug (no change)

Release Targeted Bugs (86 across all packages)

  • 3 linux kernel bugs (no change)
  • 0 linux-fsl-imx51 bugs (no change)
  • 0 linux-ec2 bugs (no change)
  • 0 linux-mvl-dove bugs (no change)
  • 0 linux-ti-omap bugs (no change)
  • 0 linux-meta-ti-omap bug (no change)

Milestoned Features

  • 1 blueprints (Including HWE Blueprints)
    This number is wrong. The only blueprint I see on the list is mine.

Bugs with Patches Attached:138 (up 14) since the last meeting 1 month ago

  • Bugs with Patches
  • Breakdown by status
    As these are now one of my main focus points. I will begin working specifically on them this week.
    The goal is to beat this number back to zero and then maintain as close to that as possible going forward.
    I’ll be asking some of you to review bugs as needed to assess their viability and to improve my work on the overall
    list over time. Once I have the hang of it, I hope to submit those patches that make sense to the list for review.

Blueprints: Natty Bug Handling

nothing to report

Blueprints: Enhancements to the firmware test suite

Changes to fwts (natty development branch):

  • remove need for sudo when loading ACPI tables from file (bug fix)
  • initial ACPI tables field checking – on common fields that give most issues
  • move kernel log tables into json format data
  • remove –fwts-debug
  • –stdout-summary outputs FAILED levels, e.g FAILED_HIGH, FAILED_LOW, etc
  • adjust log width to match tty width when logging to stdout
  • add aborted and skipped test to summary
  • cpufreq: make this an experimental test as it’s not fully validated yet
  • check for non-compliant brightness levels
  • working on AML method sanity checking

Blueprints: Handling of Deviations from Standard Kernels

Small progress in the documentation, will do the in tree doc next and try the tooling.
For the drm33 upstream kernel I finished the scripting and have sent out the first patch queued notice

Blueprints: Review of the Stable Maintenance Process

We’re roughly half way through the first trial of the new stable kernel process, which is outlined here;

https://wiki.ubuntu.com/Kernel/StableReleaseCadence

Yesterday, we reverted commits for bugs without verification, and uploaded the resulting kernels this morning.
As soon as they are built, they will require QA and Cert testing before being released.

For Maverick, The following bugs had commits reverted due to lack of verification:

  • 598938 [Realtek ALC269] ALSA test tone not correctly played back
  • 637291 [Realtek ALC269] ALSA test tone not correctly played back; no audio on laptop speakers but
  • 648871 [Realtek ALC269] ALSA test tone not correctly played back
  • 642892 [Realtek ALC269] ALSA test tone not correctly played back
  • 655386 no audio playback except with headphones but it is extremely quiet
  • 546769 no sound with Realtek ALC269 – on Sony Vaio VPCEB1S1E
  • 663642 DVI doesn’t work at BeagleBoard xM rev A3
  • 580749 Pulseaudio is not running VT1708

    For Lucid, The following bugs had commits reverted due to lack of verification:

  • 598938 [Realtek ALC269] ALSA test tone not correctly played back
  • 637291 [Realtek ALC269] ALSA test tone not correctly played back; no audio on laptop speakers but
  • 642892 [Realtek ALC269] ALSA test tone not correctly played back
  • 655386 no audio playback except with headphones but it is extremely quiet
  • 546769 no sound with Realtek ALC269 – on Sony Vaio VPCEB1S1E
  • 580749 Pulseaudio is not running VT1708
  • 605047 Internal Microphone on Dell Lattitude e6410 does not work
  • 628776 HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs
  • 580749 Pulseaudio is not running VT1708
  • 465942 Hardware device disappearing from Sound Preferences on ASUS 0x104381b3
  • 587546 Pulseaudio fails after several seconds
    General comments on the new stable cadence process:
    * Thanks for all the help and understanding. This first test run through the process steps has been very labor intensive, slow, and error prone.
    * We are refining the process as we go. Details are being maintained on the wiki page linked above.
    * Martin Pitt has agreed to change the verification tagging for bugs to “verification=[needed|failed|done]-”
    in order to help us track verification in different released kernels within the same bug.

    Reverted patches will be reapplied once the appropriate action is taken in the bug report. For specific details see:

    https://wiki.ubuntu.com/Kernel/StableReleaseCadence

Status: Natty

apw just uploaded -4.13 yesterday. the 2.6.37-rc2 is in the works.

Security & bugfix kernels – Maverick/Lucid/Karmic/Hardy/Dapper

   Upd./Sec.    Proposed    TiP    Verified   
Dapper: Kernel    2.6.15-55.89            
Hardy: Kernel    2.6.24-28.80            
= LRM    2.6.24.18-28.7            
Karmic: Kernel    2.6.31-22.68            
= mvl-dove    2.6.31-214.30    2.6.31-214.32         
= ec2    2.6.31-307.21            
Lucid: Kernel    2.6.32-25.45    3.6.32-26.47    14    6 / 24   
= LBM    2.6.32-25.24    2.6.32-26.25         
= mvl-dove    2.6.32-209.25    2.6.32-211.27         
= fsl-imx51    2.6.31-608.19    2.6.31-608.20         
= ec2    2.6.32-309.18            
= lts-backport-maverick    2.6.35.22.34            
Maverick: Kernel    2.6.35-22.35    3.6.35-23.38    14    12 / 30   
= mvl-dove    2.6.32-410.27            
= ti-omap4    2.6.35-903.18            

Incoming Bugs: Regressions

Incoming Bugs
12 Natty Bugs
1025 Maverick Bugs (up 304 since the final maverick meeting)
1082 Lucid Bugs (up 68 since the final maverick meeting)
Current regression stats (broken down by release):

regression-potential

As this tag is deprecated, this listing is only to ensure that I keep it on my radar until
changes to the apport hooks and my processing of the currently tagged bugs is completed.

  • 3 natty bugs
  • 396 maverick bugs (up 32 since the final maverick meeting)
  • 177 lucid bugs (up 14 since the final maverick meeting)

regression-update

  • 20 maverick bugs
  • 77 lucid bugs (up 13)
  • 6 karmic bugs (no change)
  • 0 hardy bugs (no change)

regression-release

  • 147 maverick bugs
  • 193 lucid bugs (up 16)
  • 40 karmic bugs (up 3)
  • 2 hardy bugs (no change)

regression-proposed

  • 13 maverick bugs
  • 7 lucid bugs (up 1)
  • 1 karmic bug (no change)
    Please note that I have removed Jaunty from the listing above.

Incoming Bugs: Bug day report

The next Kernel Bug Day will be next Tuesday. The focus will be on bugs with patches attached
in order to begin the serious amount of work to be done there. I am planning to work with Andy
and Tim this week to see how we will handle Team Bug Days since we are changing the way we do
the Top Bugs each week. I will also begin working up a weekly report of the major bugs we are looking at.
Chances are I will make some of that data available during this meeting going forward.

Please note that if we take any of those patches, we either need the HW to verify them or have a commitment from the community to verify them or they weill be reverted

Triage Status

I talked with a number of the folks we work with to triage bugs during UDS, but, other than that,
I have nothing to report on as far as status. I am, however, interested in your thoughts on holding
another Kernel Triage Summit. We could do our own again, or we can make it a part of one of the
community events such as Ubuntu Developer Week, Open Week, etc.

Based on all the effort that you’ve put into getting community involvement, did we get any value or would you have been better off just doing that amount of effort in triaging yourself?

We saw some benefit, but I think it is too early to tell the impact. I’d have to defer to those who presented and attended as to the usefulness. I felt it was a success, more so than I had hoped for.

I’m asking about community triaging in general

We saw some improvement, but I don’t know if it was commensurate with the effort involved in organizing our own.
In summary I think I could have just done the triage effort myself.

Open Discussion or Questions

Noting new this week.