Date: Wed, 13 Sep 2000 02:15:58 -0700 From: Daniel Quinlan quinlan@transmeta.com To: linux-kernel@vger.kernel.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 initial version. 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. Proposal: 1. Developers submit all Linux kernel patches to kernel-patches@kernel.org (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): ------- To: kernel-patches@kernel.org Subject: this is a short description of the patch <tag 1>: <whatever> <tag 2>: <line one> <additional lines are indented> <more tags> <patch> ------- Required tags: "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. Optional tags: "Fixes" - followed by one or more bug numbers (tracked by tytso for now). For example, "T0001" might be tytso bug number 0001. "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 on success. "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 the patch. 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 patch. Notes: - 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. Future features? - PGP signing of patches - conversion of uuencoded patches to text format for people with broken mailers
Daniel Quinlan: Proposal: Linux Kernel Patch Management System
By
Get the Free Newsletter!
Subscribe to Developer Insider for top news, trends, & analysis