KernelUploadsApplication

Differences between revisions 10 and 11
Revision 10 as of 2010-03-22 17:50:27
Size: 12195
Editor: c-76-105-148-120
Comment:
Revision 11 as of 2010-03-22 17:52:53
Size: 12203
Editor: c-76-105-148-120
Comment:
Deletions are marked like this. Additions are marked like this.
Line 81: Line 81:
From a kernel point of view, I really find our multiple topic branches and packages a huge pain in the ass when it comes to CVE's. Particularly when there's an ABI bump it's extremely tedious updating every package and meta package as well as LBM, LUM, and LRM for every release that's affected by the ABI bump. However, I think we've started to recognize this pain point and began working with the security team to improve each of our work flows. For example, rather than waiting for the security team to ping us that we need to to process the latest 20 CVE's, we've taken a more proactive approach and will try to stay up to date with the latest CVE's in the security queue. This provides us the freedom to propose a security update when there's say not packages in -proposed and also yields a quicker turn around time if an when we have a high priority CVE that the security team needs released asap. From a kernel point of view, I really find our multiple topic branches and packages a huge pain in the ass when it comes to CVE's. Particularly when there's an ABI bump it's extremely tedious updating every package and meta package as well as LBM, LUM, and LRM for every release that's affected by the ABI bump. However, I think we've started to recognize this pain point and began working with the security team to improve each of our work flows. For example, rather than waiting for the security team to ping us that we need to to process the latest 20 CVE's, we've taken a more proactive approach and will try to stay up to date with the latest CVE's in the security queue. This provides us the freedom to propose a security update when there's for example no packages in -proposed and also yields a quicker turn around time if and when we have a high priority CVE that the security team needs released asap.

I, Leann Ogasawara, apply for upload rights for the linux kernel package(s) and friends (see detailed list below).

Who I am

Hi, I'm Leann Ogasawara. I'm a member of the Ubuntu Kernel Team and employed by Canonical. I originally started as the Ubuntu Kernel Team's QA/Triage Engineer but have since transitioned into a full Kernel Dev position. I've since been focused on helping with stable kernel maintenance. This includestasks such as processing CVE's, reviewing and applying upstream stable patch sets, and bug triaging/fixing.

My Ubuntu story

I got my first taste of Linux while attending college back in the early 2000's where our CS lab ran with Red Hat installations. As a recent college graduate, I was fortunate enough to land a job at the Open Source Development Lab where I began focusing on the kernel. I started with the usual kernel janitor work and also kernel QA. While at OSDL I began hearing about this new distribution called Ubuntu. I installed Dapper and have been a faithful Ubuntu user ever since. I was amazed at it's ease of use and that everything "just worked". In 2007 I was lucky enough to get the opportunity to come work for Canonical as a member of the Ubuntu QA Team and have since made a full transition to the Ubuntu Kernel Team.

My involvement

As noted above, my current involvement is with stable kernel maintenance. This involves the following:

  • Applying and backporting patches for CVE's
  • Building, testing, and packaging the security kernels
  • Reviewing and applying upstream stable patch sets
  • Bug triage and fixes - particularly focusing on regressions and SRU's
  • Going forward I'm going to be the Ubuntu kernel maintainer for Lucid+1 and have already started the prep work for the Ubuntu M kernel.

Examples of my work / Things I'm proud of

Kernel security updates for the Dapper, Hardy, Intrepid, Jaunty, and Karmic from October 2009 through end of January 2010 were a direct result of work I'd done. I found this work to be very fulfilling and dare I say fun. Also, due to my CVE work, I was granted full git commit privileges to all the Ubuntu kernel trees.

During the same time frame I was also heavily involved with reviewing stable patch sets from upstream and applying them to our Ubuntu Karmic kernel for SRU. All of these kernels have since moved through -proposed and into -updates. I'm also proud of the fact that a few of my own patches for Ubuntu bugs that I submitted upstream were accepted into upstream stable patch sets and thus made their way back into the Ubuntu kernels and fixed known issues reported by Ubuntu users. This was very gratifying to witness patches of mine come full circle.

Areas of work

  • Kernel CVE's. I processed 4 rounds of Kernel CVE's from Oct 2009 through Jan 2010. The work included investigation of each CVE, finding appropriate fixes, and applying patches to Dapper, Hardy, Intrepid, Jaunty, Karmic, and Lucid where applicable. In addition to this, I was also responsible for performing build tests, boot tests, and qa regression tests for each security kernel across all releases and all arch's. As a final step, I packaged each kernel and meta package to be handed off to the security team to do a final set of build tests, re-sign, and upload to the security pocket. I primarily worked with Stefan Bader (Ubuntu Kernel Team) and Kees Cook (Ubuntu Security Team). As of Feb 2010 we've been bringing another Kernel Team member up to speed on processing CVE's but I've continued to provide feedback in the form of patch reviews as well as helping test.
  • Upstream Stable Patch Sets. I reviewed and applied the upstream 2.6.31.6, 2.6.31.7, 2.6.31.8, and 2.6.31.9 stable patch sets. I also helped upload these packages to our pre-proposed kernel-ppa and had a few uploads to -proposed sponsored by Stefan Bader. I've since continued to help review the 2.6.31.10, 2.6.31.11, and 2.6.31.12 upstream patch sets while another member of the team has applied them. I primarily worked with Stefan Bader (Ubuntu Kernel Team).
  • As I begin ramping up for Lucid+1, ie M, I've done some misc work with other members of the Ubuntu kernel team. I worked with Tim Gardner (Ubuntu Kernel Team) to apply and package some fixes for our Freescale iMX51 package. Tim subsequently sponsored this upload for me. Also per Tim's request I sync'd the OEM Hardy LUM and LBM tarballs into our main Hardy git repo and Stefan handled the upload to the netbook-lpia pocket. I've also made Andy Whitcroft (Ubuntu Kernel Team) my new BFF for M's release cycle :). I fully expect to work more closely with him between the months leading up to M all the way through M's release. He's already got me prepping ubuntu-m's git repo.

I'd also like to make a note here about our kernel bug situation. Having transitioned from the Kernel QA/Triage role to a Kernel Dev role I still consider bug triage a big area of work that I plan to stay involved in. I've witnessed first hand the insane volume of kernel bugs that get reported against the linux kernel package. I think we're taking a step in the right direction by staying up to date with the latest upstream stable patch sets as their primary purpose is to fix kernel bugs. I also believe the work we've started doing with the kernel arsenal scripts has allowed us to manage such a large volume of bugs in a somewhat automated fashion and a limited amount of resources.

Things I could do better

Obviously I have a very narrow focus at the moment with my sights purely set on the kernel. As such, I primarily interact with other members of the Ubuntu Kernel Team. However, I know there is an untapped wealth of knowledge outside of the Ubuntu Kernel Team that I should take more advantage of. This encompasses not only other Ubuntu teams, but also the community at large. Every opportunity I've had to work with individuals outside our team has always increased my productivity as well as the team's productivity. From a community standpoint there's much larger pool of triagers, patch submitters, or testers that we should be engaging. Likewise, even within our own Ubuntu teams, I recognize we share common pain points which we may have unknowingly duplicated efforts to resolve.

Upload Rights

I'm requesting upload rights for the kernel package set for all active series, which includes the following kernel packages:

linux
linux-ec2
linux-fsl-imx51
linux-mvl-dove
linux-ports
linux-qcm-msm
linux-ti-omap
linux-meta
linux-meta-ec2
linux-meta-fsl-imx51
linux-meta-mvl-dove
linux-ports-meta
linux-meta-qcm-msm
linux-meta-ti-omap
linux-restricted-modules
linux-backports-modules-2.6.24
linux-backports-modules-2.6.27
linux-backports-modules-2.6.28
linux-backports-modules-2.6.31
linux-backports-modules-2.6.32
linux-ubuntu-modules-2.6.24
linux-source-2.6.15
linux-restricted-modules-2.6.15
linux-restricted-modules-2.6.24
initramfs-tools
linux-firmware
linux-firmware-nonfree

Plans for the future

General

I'm really looking forward to being Lucid+1's, ie M's, Ubuntu kernel maintainer. This is the primary reason why I'm requesting kernel upload rights. Having already gotten a taste of the stable maintenance kernel tasks I'm excited to get more involved with the the current development/release oriented tasks and live on the bleeding edge :).

What I like least in Ubuntu

From a kernel point of view, I really find our multiple topic branches and packages a huge pain in the ass when it comes to CVE's. Particularly when there's an ABI bump it's extremely tedious updating every package and meta package as well as LBM, LUM, and LRM for every release that's affected by the ABI bump. However, I think we've started to recognize this pain point and began working with the security team to improve each of our work flows. For example, rather than waiting for the security team to ping us that we need to to process the latest 20 CVE's, we've taken a more proactive approach and will try to stay up to date with the latest CVE's in the security queue. This provides us the freedom to propose a security update when there's for example no packages in -proposed and also yields a quicker turn around time if and when we have a high priority CVE that the security team needs released asap.


Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.


Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.


BEGIN PGP SIGNED MESSAGE


Hash: SHA1

Tim Gardner <tim.gardner@canonical.com> Leann has done stellar work on CVE's and stable maintenance. I have approved and uploaded a number of kernel packages prepared by her. She is skilled, diligent, and thorough. But most of all, I trust her.


BEGIN PGP SIGNATURE


Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkufgbIACgkQ/VwK2Iv57+Z72gCgrNcs5Yoz44ns8OUWqh+HsyQs fq0An1z03UkBpiDcMXYWe21G9TrB8UuW =Kjqw


END PGP SIGNATURE



BEGIN PGP SIGNED MESSAGE


Hash: SHA1

Stefan Bader

General feedback

Leann processed several CVE kernel updates for me. Her quality of work was exceptionl right from the beginning. And she improved to a level where I will trust her work completely. She also did take care of uploads to our pre-proposed PPA and prepared proposed kernel uploads.


BEGIN PGP SIGNATURE


Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkuiKjcACgkQP+TjRTJVqvT/fwCdFoH8fZIloAGY1y9fFaBEtZO4 dpsAn3u5JSK9nEqdQcSfeu8+M7W+bIlN =zPks


END PGP SIGNATURE



BEGIN PGP SIGNED MESSAGE


Hash: SHA1

Andy Whitcroft

General Feedback

I have worked with Leann on an ongoing basis for over a year. She has is a diligent worker producing deliverables on time. More importantly she knows when she needs help and is comfortable asking for it. I trust her to do a task and to do it well. I highly recommend her.

Specific Experiences of working together

Leann has been working to open the kernel for Lucid+1 she has taken on this huge task efficiently, already having rebased the Ubuntu delta to 2.6.33.

Areas of Improvement

Leann needs little improvement that cannot best be gained by direct experience, which is why it is time she had upload rights for the kernel packages.


BEGIN PGP SIGNATURE


Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuj4dIACgkQ7kQoFRG3d6+fcgCgz7dHc/yTQaIdp2YvITV9yY/N XAYAnAg59aKNvt77eaiD5VUqCcPxDDw/ =PNgM


END PGP SIGNATURE



TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
=== Areas of Improvement ===


LeannOgasawara/KernelUploadsApplication (last edited 2010-04-01 21:58:33 by c-76-105-168-175)