[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectProposal: 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.


    1. Developers submit all Linux kernel patches to
    (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>
    <more tags>


    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


    - 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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.026 / U:0.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site