Saturday, September 20, 2008

Bureaucracy

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.

~pete

3 comments:

Ross said...

I thought it only prudent that you should correct this line "weather a backport from a newer kernel"

By replacing "weather" with "whether". Before someone screams hypocrite :)

~pete said...

Thanks for the catch! Thats what I get for failing spelling in school and relying on that damn spell check in Firefox!!!

laga said...

And why don't you simply add the reason for the patch into the commit message?

Accountability is a good thing, though. I've been looking into AUFS in the Ubuntu kernel. AFAIK AUFS was added as a big monolithic patch, consisting of an upstream checkpout (from http://aufs.sf.net) and several patches to get the old source to compile with newer kernels plus some bug fixes. The whole thing is a maintenance nightmare because it's not possible to identify individual changesets - I think they got lost because of the kernel team's workflow.

How is your "bug entry" effort going to help situations like this? As far as I understand, there will be LP hooks which add the SHA1 hash of a commit to the ticket. How is that going to help if commits are lost because you're constantly rebasing? Will the patch be added to the ticket?


Sorry if I come across as rude, it's certainly not meant that way. I'm just trying to understand some things.