2011-12-13

Meeting Minutes

IRC Log of the meeting.
Meeting minutes.

Agenda

20111213 Meeting Agenda

ARM Status

P/omap4: a new kernel (3.2.0-1402.2) based off 3.2 (Ubuntu-3.2.0-3.9) has been released, while a new TI BSP + 3.2-rc5 is in the pipe. SRU kernels: nothing to report.

Release Metrics and Incoming Bugs

Just adding link this week, instead of posting all data. http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

  • apw

    hardware-p-kernel-boot

    1 work item

    hardware-p-kernel-config-review

    4 work items

    hardware-p-kernel-delta-review

    4 work items

    foundations-p-ipv6

    1 work item

    cking

    hardware-p-kernel-delta-review

    1 work item

    jsalisbury

    other-p-bug-workflows

    1 work item

    ogasawara

    hardware-p-kernel-version-and-flavors

    1 work item

    hardware-p-kernel-config-review

    21 work items

    tgardner

    hardware-p-kernel-version-and-flavors

    1 work item

    hardware-p-kernel-delta-review

    1 work item

    If your name is in the above table, please review your Alpha-2 work items. Note that Alpha-2 is Thurs Feb 2.

Blueprint: hardware-p-kernel-power-management

Status: Precise Development Kernel

  • We have uploaded the 3.2.0-4.10 Ubuntu kernel which is based on latest upstream v3.2-rc5 kernel. Additionally, after yesterday's Tech Board discussion around the i386 non-pae flavor, it was decided to continue carrying this flavor for 12.04 and then drop it in 12.10. The installer will also be switched to default to the pae flavor for i386.

Important Upcoming Dates:

  • Thurs Feb 2 - Alpha 2 (~7 weeks)

Status: CVE's

  • CVE-2010-4251 CVE-2010-4805 CVE-2011-1082 CVE-2011-1083: epoll DOS -- fix incomplete, referred back to Security for review CVE-2011-1747: agp ioctl memory DOS -- no upstream fix as yet CVE-2011-3347: be2net non-member vlan DOS -- cannot identify upstream fix CVE-2011-3638: ext4 extent split -- upstream fix identified, pending application CVE-2011-4112: pktgen bridge panic -- redhat is withdrawing the CVE CVE-2011-4131: nfs4 ACL oops -- fix is still iterating upstream, pending CVE-2011-4347: kvm kvm_vm_ioctl_assign_device crashes -- no upsteam fix as yet === CVE Metrics === Currently open CVEs for each supported branch:

    Package

    Open

    linux Hardy

    10 (-1)

    linux Lucid

    7 (-1)

    linux Maverick

    7 (-1)

    linux Natty

    7 (-1)

    linux Oneiric

    5

    linux Precise

    5

    linux-ec2 Lucid

    7 (-1)

    linux-fsl-imx51 Lucid

    7 (-1)

    linux-mvl-dove Lucid

    7 (-1)

    linux-mvl-dove Maverick

    7 (-1)

    linux-ti-omap4 Maverick

    7 (-1)

    linux-ti-omap4 Natty

    7 (-1)

    linux-ti-omap4 Oneiric

    5

    linux-ti-omap4 Precise

    5

    linux-lts-backport-maverick Lucid

    7 (-1)

    linux-lts-backport-natty Lucid

    7 (-1)

    linux-lts-backport-oneiric Lucid

    5

    We only have one open CVE with an upstream fix currently. The remainder await fixes from upstream. (bah, will drop the CVE- prefix for future updates.) ..

Status: Stable, Security, and Bugfix Kernel Updates - Oneiric/Natty/Maverick/Lucid/Hardy

Hardware Certification - Testing Pools

Let me do this gradually As part of the SRU workflow the hardware certification team tests the -proposed kernel on as many certified systems as possible. As the number of certified systems for each release has grown, getting full coverage has become more and more difficult. To allow us to reduce the number of systems tested we have devised a system of 'testing pools'. This takes advantage of a system which stores details of the certified hardware including it constituent components to provide as broad a component coverage as possible.

Initially the system ensured that at least one instance of each piece of hardware (as identified by PCI Id's) was present in the testing pool. This turned out not to fulfill the goal of the system since we still ended up with needing almost all the systems we had to provide full coverage (e.g. 165 systems certified for Natty gave a testing pool of 158)

We made a first effort at reducing the size of the pools by considering only components of particular categories to be 'important'. A list of these was sent to the kernel-team mailing list. https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AphFraZYTghddElqTHl3NmZsWXVDYkMxcE5zX3EtR0E&hl=en_US#gid=0

These give us testing pools of ~50 systems. However we are not happy yet with the coverage. We need feedback on which components need to be added in. The criteria used should be: how likely is it that a bug could occur in just a subset of the components of this category? A good example is the category 'Display Controller/VGA Compatible Controller' which we do cover already. We know for a fact that bugs will be specific to particular makes of graphics card. Same for CPUs ('Processor' category)

We really need feedback on this

  • ..

brendand, This will all be documented in the meeting minutes. It would be good if you could also follow up with an email to the kernel-team mailing list.

Open Discussion or Questions? Raise your hand to be recognized

brendand: Do you have a revised list which has all the possible components you want us to review to consider adding back in? Also, what # are you looking for to satify coverage? ogasawara - if you can access that link then all the ones marked 'x' are not considered at the moment

We have no fixed number to reach

brendand, what is the max number of machines that you can cover ?

tgardner - it seems to be about 90, realistically speaking. something like that. ack

i would prefer for now to take each component category on it's own merits' rather than considering how many extra systems it adds. we (the hwcert team) can worry about managing that

i had a question to pose, as a bit of a thought experiment

Could a bug affect only a subset of device of the category 'Bridge/PCI bridge'?

brendand, likely, but its more likely to be BIOS specific if there is more than one different piece of h/w in any category it is possible to get different results from each however, we have way fewer problems with PCI bridges.

apw - yes, definitely *possible*. actually the point of that question was to illustrate the line of thinking that needs to be taken to evaluate this list of component categories between tgardner and apw that's the kind of critique of the list i'm looking for thanks Any Open Discussion comments?

one last thing. i'm not sure is that link public. anyone who can't get access please let me know and i'll sort something out

If no other comments, then going once

brendand: how do you want feedback, maybe a "feedback" column, and we'll add X's to categories we think should be added back?

ogasawara - i'm arranging for everyone to have edit rights and i'll add a feedback column

brendand: let us know when it's ready for editing. I'm sure a few of us can just a quick pass off and tick the ones we want. brendand, any other comments?

yeah, if any of the categories don't make sense to you, contact me about it i'll send the link to the kernel-team list

brendand, dot dot then ?

Any other open discussions or questions?

KernelTeam/Meeting/2011-12-13 (last edited 2011-12-13 18:14:34 by jsalisbury)