With my recent job change, I’m starting to run into a bunch of people asking “What exactly are you going to be doing now?”
I’ve tried responding by describing the kernel related stuff I’ve been doing for the past years, and it turns out that a lot of people didn’t even realize I was doing that.
So, here’s a short list of some of the things that I’m going to be doing at my new job, and most importantly, how you can track what I do yourself, so that I never have to write a status report again…
Stable kernel releases
I’ve been releasing the Linux kernel stable releases since way back when they first started up, in mid 2005. Early on, the most excellent kernel developer Chris Wright helped out with this task, but for the past few years, I’ve been doing this on my own.
These releases take the last kernel released by Linus and add any needed bugfixes and other related patches that have gone into Linus’s development tree, and package it all up in a format that users can use themselves during the 2-3 month development cycle time while the kernel developers are madly working on creating the next kernel release.
For a description of what entails a change that is acceptable into the stable kernel releases, and how to get a patch accepted, please see the file Documentation/stable _ kernel _ rules.txt in the kernel source tree.
Every year I pick a specific kernel version and declare that as “longterm”. That kernel gets support from me for bugfixes and related things for two years before it is gracefully retired to a more leisurely release cycle by the capable extra-extra longterm maintainer. For details on how the longterm kernel works, and how it is picked, see this older post I wrote on the topic.
If you want to be notified of when these kernels are released, you can do one of the following:
- read lwn.net, they post the announcements mere hours after they happen. They also post lots of other wonderful things, if you aren’t reading this site already, you are missing out.
- subscribe to the linux-kernel or stable mailing lists. Note, you will get a lot of other traffic, but it’s all good, you wanted to know what was going on in Linux kernel development directly from the developers themselves, right?
- subscribe to my twitter feed. You might get other random blatherings there, but I do post the announcements to it.
- watch the Linux G+ feed, the releases are all announced there.
- subscribe to the google calender feeds of the kernel releases. This is maintained by the talented Tsugikazu Shibata (high powered executive by day, Linux kernel developer by night) and can be found here for the stable kernel releases, here for the main Linux kernel releases, and here for the kernel development releases.
Kernel subsystem maintainer
When I’m not releasing stable kernels, I also maintain a number of different kernel subsystems. These entail USB, driver core, staging, tty, and a variety of other bits of the kernel. Being a maintainer means you read patches from submitters, handle questions from both developers and users about things related to the subsystem (usually bug reports). If a patch looks acceptable, you test it if possible, and apply it to the relevant git tree and push it publicly, and notify the author that it was accepted. Every weekday, these git trees get merged together in the linux-next release, and inevitably, problems are reported and it’s up to the maintainer to fix them when they affect their portion of the kernel.
If you are curious as to exactly what portions of the kernel I maintain, look at the MAINTAINERS file in the kernel source tree and search for my name. Those entries will show you exactly where the git tree for the subsystem lives, as well as the proper mailing list to contact if you have questions in those areas.
If you want to follow the development done in these various areas, and what patches I apply, you can subscribe to the RSS feed of the individual git trees listed in the MAINTAINERS file, or you can follow along on the various different mailing lists.
Kernel development
When not releasing kernels or reviewing patches from others, I occasionally get time to fix bugs, rework existing code to solve problems or extend it in various ways, or even rarer, write a new driver for some random hardware device. This is one area that I should be doing more of now that I have extra time available.
Right now I’m working on a driver for a USB to serial device that Linux doesn’t support, and I have some ideas for how portions of the driver core can be reworked to handle some areas better (most of that has been suggested by Kay years ago, I really should get around to implementing them…) I also have some ideas on cleaning up some cruftier portions of the kernel that haven’t seen any love for many years, but that’s more of a long-term goal, no specifics yet.
If you want to follow along with this development, just watch the main kernel tree for commits by me. That can be done by either subscribing to the rss feed for the kernel tree, or just using git and doing simple searches.
I keep my kernel development and maintainership scripts and directory structure in a public github repo, if you are curious about how this type of thing works. There’s lots of scripts helpfully named “do.sh” which I really should rename to be a bit more descriptive, but make sense to me relative to the directory they are located in.
I also have lots of talks, scripts, and other minor projects in my public github repo, if you are curious as to other things I work on over time.
Linux Driver Project
Despite the creaky web page, the Linux Driver project is continuing on quite well. We have written a number of new drivers now included in the main kernel tree, as well as maintaining the staging portion of the kernel. I’ll be working on revamping the web site to make it a bit more obvious as to what is going on here, but again, the best way to follow this work is to watch the mailing list.
LTSI kernel maintainership
As has been announced in various places, the LTSI project (Long Term Support Initiative) has started up with the goal to provide a kernel that the consumer electronic companies can use to help reduce their maintenance burden, and to provide a common area where they can learn how to get involved in upstream kernel development.
I’m helping in setting the kernel tree for that project up, and getting some of the procedures and processes in place for it to succeed in the long run. For now, until it really gets up and going, I’m also going to be maintaining the tree myself, handling the patches and working on the support scripts to make it easier to develop using it. If you want to track this work, watch the kernel tree, or join the public mailing list.
I’m also talking with lots of different companies that create chips used in consumer devices that have traditionally been out of the main kernel tree, and with others that are active upstream developers, to try to get them all working better together. I’m also working with the Yocto project to see how the two projects can work together in sharing their kernel needs.
To follow the development of this kernel, you can subscribe to the mailing list, read the archives, or just watch the git tree.
Distribution work
I’m still going to continue my maintenance of the openSUSE Tumbleweed distro, as I’ve come to rely on it, and it really takes almost no time at all to keep up and working properly. To follow along with any Tumbleweed questions/concerns, please read the openSUSE-Factory mailing list. The scripts used to maintain the Tumbleweed distro, and the list of packages in it, can be seen, and watched, in the tumbleweed github repo.
I’m also going to continue to remain a Gentoo developer, and will have time to do more package maintenance there, which I have not had the opportunity over the past few years.
Both of these are distros that I use every day on my development systems and my servers, and are great community-based distributions.
Travel
“You traveled last year as much as people think you do.” — my wife
As usual, I’ll be attending all of the various Linux Foundation events held all around the world, as well as other different conferences that I’m invited to and can find time to get to. Odds are I’ll also be traveling to different companies to work with their kernel developers on how to get them to integrate better with the upstream kernel community, or how the LTSI kernel can help them out.
So once again, my frequent flier miles status will probably not be downgraded this year, much to my very patient family’s despair.
Is that all?
So, hopefully that explains a bit of what I’ll be doing in the near future for the upcoming years. Needless to say, I’m thrilled to be working for the Linux Foundation and that they are supporting me in all of this. If there’s anything that anyone is thinking I should be doing but seem not to be, please
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
. I want to make Linux succeed and thrive, and whatever I can do to help that out, I will.