Saturday, September 20, 2008


I received a comment on my blog, referencing the Kernel Team requiring a LP bug prior to committing a patch to the tree. The person commenting called it "Bureaucracy". I thought this would be the common reaction so I wanted to raise it here. My response is below...

Its not about bureaucracy, its about accountability. We add numerous patches during a cycle. While most do have a LP entry there are quite a few that don't. The problem manifests itself when someone can't remember why they added the patch. Obviously it was intended to fix a problem. There have been occasions where the patch, while fixing one bug introduced a much bigger one. When going back through the history trying to figure out why we would add it, the usual answer is "it seemed like a good idea at the time".

We are striving to stick as closely as possible to upstream, and every patch we add, whether a backport from a newer kernel or a sauce patch needs to have a bug attached. This is common a common "Change Control Measure". If it worth adding it should have a valid bug attached.


Linux Plumbers Conference Recap.

Seems like these days I get most of my blogging done on the plane going from here to there. This entry is no different.

I spent the last week with the kernel team in Portland. We held a mini-sprint on Monday and Tuesday, and Wednesday thru Friday were consumed with the Linux Plumbers Conference.

Some developments out of the mini-sprint:

* We will be adding git commit hooks for all check-ins. If a LP bug number is not referenced in the commit template, the commit won't happen. This will prevent stray patches from going to the tree with out a bug, explanation/rationale & justification. Thanks to Launchpad's new API we can flip the state from "In Progress" to "Fixed Released" and drop the commits SHA1 id into a comment in the bug.

* More kernel QA. We will be hooking the build into Kees's automatic security testing framework. By having every commit needing a LP bug we can attach a test case to the bug and have it automatically inserted into the test harness. This will keep regressions from sneaking into the build and give us a higher QA on the kernel.

* The kernel team will be packaging up the latest bleeding edge upstream "Vanilla" kernel. There are some details still to be worked out, like where it will live. Will go in main or universe, a PPA... The point with this is so that users will have a pristine upstream kernel to test against. This is where the kernel team is doing new development anyway. If the issue is fixed we can quickly do a git bisect and figure out what patch is needed and backport it to the stable kernel if it makes sense. I'll write more about this one in a future blog posting.

The Plumbers Conference was outstanding given this was it's first year. The talks were good, focused and useful. For example Arjan's "Booting in 5 sec" was right on time. Some of the low hanging fruit faster boot stuff we can prob squeeze into Intrepid.

Canonical took a beating from Greg Kroah-Hartman of Novell during his Keynote Speech. He has had a long running issue with Canonical not "giving back" and "leeching". Both Matt Zimmerman and I took this opportunity to talk with Greg.

It was a productive conversation and I think we have come to some common ground. Our plan as we hire more kernel developers is to work in upstream head and work on kernel bits that are of interest to Ubuntu and Canonical. We will be pushing patches and fixes to the upstream sub-system maintainers. We talked briefly on what he considers "good upstream" citizenry. Greg offered his help and advice going forward. We will continue the discussion in email.

We'll the battery is about dead so I need to save and shutdown.