We show up

It’s really common for pitches to managements within companies about Linux kernel upstreaming to focus on cost savings to vendors from getting their code into the kernel, especially in the embedded space. These benefits are definitely real, especially for vendors trying to address the general market or extend the lifetime of their devices, but they […]

Maintaining your email

One of the difficulties of being a kernel maintainer for a busy subsystem is that you will often end up getting a lot of mail that requires reading and handling which in turn requires sending a lot of mail out in reply. Some of that requires thought and careful consideration but a lot of it […]

Human factors

An issue which I always find depressing but sadly unsurprising in discussions of process with software is the frequent disregard for human elements; indeed often the goal people have in creating process is to try to control and eliminate human elements. Little thought is given to what is going to motivate people to do what’s […]

Making patches easy to review

One of the big things that seems to cause a learning curve for many new contributors for Linux and other projects that make a big effort with code review is the process of putting patches together in a way that makes the code review process more smoothly. This is a fairly straightforward thing but it […]

Changing core code

One of the biggest differences between working on most other OSs and working upstream on drivers for the Linux kernel is that elsewhere the core is usually a fixed thing that has been released and can’t really be changed, even if source is available (which may not even be the case). If whatever subsystem you’re […]