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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/