Abstract

Andrew will summarize the kernel.org development and decision-making processes. Special focus will be placed upon how they impact the developers of Linux for embedded products, including the economics of using a modern kernel versus staying on a frozen older kernel version, and the economics of maintaining private patchsets versus merging work back into the public kernel. For those who choose to work with the kernel.org team, Andrew will look at how that can most effectively be done. Andrew works with Linus Torvalds and other members of the Linux development community (including open source developers and distribution vendors and industry contributors) to shepherd new features and quality improvements into the Linux kernel.

Biography

Andrew has worked at Nortel Networks' R&D labs, and Digeo Interactive, a maker of digital home entertainment products. He is currently employed by Google, working fulltime on the Linux kernel. His long experience with Linux development, and experience in the embedded realm, give Andrew a unique and valuable perspective on the issues facing embedded Liux developers.

Over time, it will help prioritize it was work.
You help people understand what things are most beneficial to the most users as they work on the Linux kernel.

I find that a lot of people are monitoring the mailing lists, websites, release announcements and that sort of things.
Often they come to conferences and people tell me things they didn't know.
And that's bad.
I shouldn't not know anything.
If you know something that is potentially of use to the kernel, to help or guide development, tell us.
And a way to tell us, is by sending an e-mail to you-know-which-mailinglist.
Tell us what you need.
There's no way we can do it if we don't know that there's a need.

Another way in which a person can contribute to kernel.org development is to review the patches as they go past.

16:00 - 17:00:

You can help us to check if the change will not damaging to embedded in any way.
You may see a feature which is close to what you need, but it needs a few tweaks to be more useful.
Please tell us!
Reviewing the patches, checking them for correctness and suitability for your application is direct
contribution and it's not a lot of work.

"Squeaky gates get the oil" is an old English phrase in that the person who makes the most
noise, is the one that gets the most attention. I'm afraid that's how kernel work is.
There's historically been a group of people who were very good at making a lot of fuss about
for example latency on a desktop and as a consequence, quite a lot of developers and
resources have been devoted to improving the latency on desktops for multimedia applications
and games.

17:00 - 18:00:

That wouldn't have happened if the first people hadn't appeared on the mailing
list and make us look bad.
So if you want something done; come on the mailing list and make us look bad.
Chances are, it will happen.

What a secretly fruitful group embedded is.
All ### and companies making embedded products.
They tend to sit on their own pile of patches
which they think are only relevant to your own product and you maintain them
out of tree. Consequently, these patches get larger and larger and your ###
becomes older and older and it becomes harder and harder to ###.
and basically never gets merged in the mainline tree.

18:00 - 19:00:

it's quite a bit of work to make a patch to merge with the mainline tree.
I hope the main reason why people sit on their work without sending it
upstream is because it's quite a lot of work to get it upstream.
But I've also heard of companies who want to keep the patches to themselves
because they believe they will be beneficial to their competitors.

sorry, that's not a good reason.
This is an open source product.
Yes, it will potentially be some small damage if software becomes available to your
competitors, but I think you have to see that as the price of admission to use
Linux. It's an open source product, everybody else is contributing into it, you
have at least the moral, if not a legal obligation to contribute to it
yourself.

Another problem of patch hoarding is that it gets increasingly expensive over
time as you have to roll forward through kernel versions.