The Lifecycle of a Patch

Patches do not go directly from the developer’s keyboard into the mainline kernel. There is, instead, a somewhat involved (if somewhat informal) process designed to ensure that each patch is reviewed for quality and that each patch implements a change which is desirable to have in the mainline. This process can happen quickly for minor fixes, or, in the case of large and controversial changes, go on for years. Much developer frustration comes from a lack of understanding of this process or from attempts to circumvent it.

In the hopes of reducing that frustration, this document will describe how a patch gets into the kernel. What follows below is an introduction which describes the process in a somewhat idealized way. A much more detailed treatment will come in later sections.

The stages that a patch goes through are, generally:

  • Design. This is where the real requirements for the patch – and the way those requirements will be met – are laid out. Design work is often done without involving the community, but it is better to do this work in the open if at all possible; it can save a lot of time redesigning things later.
  • Early review. Patches are posted to the relevant mailing list, and developers on that list reply with any comments they may have. This process should turn up any major problems with a patch if all goes well.
  • Wider review. When the patch is getting close to ready for mainline inclusion, it will be accepted by a relevant subsystem maintainer – though this acceptance is not a guarantee that the patch will make it all the way to the mainline. The patch will show up in the maintainer’s subsystem tree and into the staging trees (described below). When the process works, this step leads to more extensive review of the patch and the discovery of any problems resulting from the integration of this patch with work being done by others.
  • Merging into the mainline. Eventually, a successful patch will be merged into the mainline repository managed by Linus Torvalds. More comments and/or problems may surface at this time; it is important that the developer be responsive to these and fix any issues which arise.
  • Stable release. The number of users potentially affected by the patch is now large, so, once again, new problems may arise.
  • Long-term maintenance. While it is certainly possible for a developer to forget about code after merging it, that sort of behavior tends to leave a poor impression in the development community. Merging code eliminates some of the maintenance burden, in that others will fix problems caused by API changes. But the original developer should continue to take responsibility for the code if it is to remain useful in the longer term.

One of the largest mistakes made by kernel developers (or their employers) is to try to cut the process down to a single „merging into the mainline“ step. This approach invariably leads to frustration for everybody involved.