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 includes tasks 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.
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 18.104.22.168, 22.214.171.124, 126.96.36.199, and 188.8.131.52 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 184.108.40.206, 220.127.116.11, and 18.104.22.168 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.
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
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.
If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.
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 <firstname.lastname@example.org> 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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 == Kees Cook == === General Feedback === I've worked with Leann on kernel security update for a while now. She has great attention to detail, and I'm very comfortable with her work. I highly recommend her for kernel upload rights. === Specific Experiences of working together === During a recent kernel security update, a huge stack of complex upstream commits needed to be sorted and backported across a number of architectures (the mremap patch bundle). Leann plowed through these, and got them all done in short order. It was an impressive bit of work. :) === Areas of Improvement === While already doing a fair amount of automation, I sense that there may still be more areas where scripting could further benefit her workflows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Kees Cook <email@example.com> iEYEARECAAYFAku1Ff4ACgkQH/9LqRcGPm1mJwCdEtnV+G22LbfulddO6lOZo5QC anYAmgPczSkWBlD/cRsrSzDIPKuplQAa =q9UE -----END PGP SIGNATURE-----
== <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 ===