Daniel Quinlan: Proposal: Linux Kernel Patch Management System
Sep 13, 2000, 18:02 (1 Talkback[s])
(Other stories by Daniel Quinlan)
WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
Date: Wed, 13 Sep 2000 02:15:58 -0700
From: Daniel Quinlan firstname.lastname@example.org
Subject: Proposal: Linux Kernel Patch Management System
Here is a proposal to improve the kernel development process. It was
co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and
myself. We are posting the proposal here for public review and
comment. Seb is the guy writing on the software; he's nearly done the
Description of the problem:
1. There is no system that archives and tracks Linux kernel patches.
2. There isn't a good way of marking that a particular patch is
believed to address a particular problem on the TODO list.
(Patches should be tied to the TODO items.)
3. There is no archival system and no easy way to determine which
patches have made it into the kernel.
1. Developers submit all Linux kernel patches to email@example.com
(not in place yet, so don't start sending patches).
2. Each patch will conform to a standardized, but simple, text format,
which looks something like this (exact details to be determined):
Subject: this is a short description of the patch
<tag 1>: <whatever>
<tag 2>: <line one>
<additional lines are indented>
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
"Description" - a detailed description of the patch.
"Fixes" - followed by one or more bug numbers (tracked by tytso
for now). For example, "T0001" might be tytso bug
"Obsoletes" - followed by one or more kernel-patch identifiers.
For example, "KP7555".
"Requires" - followed by one or more kernel-patch identifiers.
For example, "KP7555".
"Cc" - followed by one or more email addresses to be carbon-copied
"Flags" - followed by one or more supported flags.
For example, "experimental" (that is, don't submit
anything to Linus).
The tags are basically in RFC 822 format, but are placed in the body
of the email. (Additional lines are preceeded by whitespace, tags are
followed by a colon, etc.)
Linus wants the body of patches to be in text format and not
MIME-encoded or uuencoded.
3. A robot will process all patches for correctness (mostly, does it
apply?) with the possibility of additional tests later such as
compilation tests, regression tests, etc.
4. If the robot likes the patch, it will create a unique identifier
(i.e. "KP7562") and prepend a log entry to the body of the patch:
--- linux/Documentation/patch-log Tue Aug 29 17:24:37 2000
+++ linux/Documentation/patch-log Tue Aug 29 17:24:44 2000
@@ -1 +1,3 @@
+Applied patch KP7562 (2000/08/30)
+ Synopsis: <short description> (<author>)
(Yes, this prepend patch will always successfully apply.)
Good patches are sent to the linux-kernel mailing list which is
also where additional discussion about these patches can take
place. All patches (good and bad) will be logged and there will be
a web interface to access the patch database.
We had some amount of discussion about whether a separate mailing
list would be a good idea, but we ruled the idea out because
fragmenting the kernel-related discussion would have negative
effects on development. If it becomes a problem, we can always
separate it later.
If the patch is long, the actual body of the patch won't be
included in the email to the discussion mailing list, just a URL to
Also, information about each applied patch can be retrieved from
the patch web site (using the identifier).
5. If the robot doesn't like the patch, it will send the patch back to
the submitter with a failure report.
6. When and if Linus applies an entire patch, the patch-log will be
updated with a record of the changes. If Linus applies a partial
patch, then he will remove (or edit) the patch-log section of the
- The web site will document version strings that will work with the
server. Patches against unsupported versions will probably not work
and should be rejected, sent to somewhere else, etc.
- This system can be put into place quickly.
- Linus should reject most out-of-band patches if this is to work.
- PGP signing of patches
- conversion of uuencoded patches to text format for people with broken