Re: [PATCH] HOWTO: Updates on subsystem trees, patchwork, -next (vs. -mm)

From: Loïc Grenié
Date: Thu Jan 14 2010 - 19:41:56 EST


2010/1/14 Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>:
> One of the roles which -mm fulfilled some time ago (to offer an
> integration testing ground) has been taken over by -next.  This is still
> news to Documentation/HOWTO, so mention it there.
>
> Also add a word on how patchwork is used to track patches as they make
> their way into subsystem trees.  Remove some arbitrary links to
> subsystem repositories; they can all be found in the MAINTAINERS
> database.
>
> Signed-off-by: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
> ---
>
> This supersedes
> [PATCH] HOWTO: Point to patchwork.kernel.org and patchwork.ozlabs.org
>
>  Documentation/HOWTO |  112 ++++++++++++++++-----------------------------------
>  1 files changed, 35 insertions(+), 77 deletions(-)
>
> diff --git a/Documentation/HOWTO b/Documentation/HOWTO
> index 8495fc9..085d281 100644
> --- a/Documentation/HOWTO
> +++ b/Documentation/HOWTO
> @@ -221,8 +221,8 @@ branches.  These different branches are:
>   - main 2.6.x kernel tree
>   - 2.6.x.y -stable kernel tree
>   - 2.6.x -git kernel patches
> -  - 2.6.x -mm kernel patches
>   - subsystem specific kernel trees and patches
> +  - the 2.6.x -next kernel tree for integration tests
>
>  2.6.x kernel tree
>  -----------------
> @@ -232,7 +232,7 @@ process is as follows:
>   - As soon as a new kernel is released a two weeks window is open,
>     during this period of time maintainers can submit big diffs to
>     Linus, usually the patches that have already been included in the
> -    -mm kernel for a few weeks.  The preferred way to submit big changes
> +    -next kernel for a few weeks.  The preferred way to submit big changes
>     is using git (the kernel's source management tool, more information
>     can be found at http://git.or.cz/) but plain patches are also just
>     fine.
> @@ -293,84 +293,42 @@ daily and represent the current state of Linus' tree.  They are more
>  experimental than -rc kernels since they are generated automatically
>  without even a cursory glance to see if they are sane.
>
> -2.6.x -mm kernel patches
> -------------------------
> -These are experimental kernel patches released by Andrew Morton.  Andrew
> -takes all of the different subsystem kernel trees and patches and mushes
> -them together, along with a lot of patches that have been plucked from
> -the linux-kernel mailing list.  This tree serves as a proving ground for
> -new features and patches.  Once a patch has proved its worth in -mm for
> -a while Andrew or the subsystem maintainer pushes it on to Linus for
> -inclusion in mainline.
> -
> -It is heavily encouraged that all new patches get tested in the -mm tree
> -before they are sent to Linus for inclusion in the main kernel tree.  Code
> -which does not make an appearance in -mm before the opening of the merge
> -window will prove hard to merge into the mainline.
> -
> -These kernels are not appropriate for use on systems that are supposed
> -to be stable and they are more risky to run than any of the other
> -branches.
> -
> -If you wish to help out with the kernel development process, please test
> -and use these kernel releases and provide feedback to the linux-kernel
> -mailing list if you have any problems, and if everything works properly.
> -
> -In addition to all the other experimental patches, these kernels usually
> -also contain any changes in the mainline -git kernels available at the
> -time of release.
> -
> -The -mm kernels are not released on a fixed schedule, but usually a few
> --mm kernels are released in between each -rc kernel (1 to 3 is common).
> -
>  Subsystem Specific kernel trees and patches
>  -------------------------------------------
> -A number of the different kernel subsystem developers expose their
> -development trees so that others can see what is happening in the
> -different areas of the kernel.  These trees are pulled into the -mm
> -kernel releases as described above.
> -
> -Here is a list of some of the different kernel trees available:
> -  git trees:
> -    - Kbuild development tree, Sam Ravnborg <sam@xxxxxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
> -
> -    - ACPI development tree, Len Brown <len.brown@xxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> -
> -    - Block development tree, Jens Axboe <jens.axboe@xxxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
> -
> -    - DRM development tree, Dave Airlie <airlied@xxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> -
> -    - ia64 development tree, Tony Luck <tony.luck@xxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
> -
> -    - infiniband, Roland Dreier <rolandd@xxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> -
> -    - libata, Jeff Garzik <jgarzik@xxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> -
> -    - network drivers, Jeff Garzik <jgarzik@xxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> -
> -    - pcmcia, Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
> -
> -    - SCSI, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> -       git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> -
> -    - x86, Ingo Molnar <mingo@xxxxxxx>
> -       git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> -
> -  quilt trees:
> -    - USB, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@xxxxxxx>
> -       kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
> +The maintainers of the various kernel subsystems --- and also many
> +kernel subsystem developers --- expose their current state of
> +development in source repositories.  That way, others can see what is
> +happening in the different areas of the kernel.  In areas where
> +development is rapid, a developer may be asked to base his submissions
> +onto such a subsystem kernel tree so that conflicts between the
> +submission and other already ongoing work are avoided.
> +
> +Most of these repositories are git trees, but there are also other SCMs
> +in use, or patch queues being published as quilt series.  Addresses of
> +these subsystem repositories are listed in the MAINTAINERS file.
> +
> +Before a proposed patch is committed to such a subsystem tree, it is
> +subject to review which primarily happens on the on mailing lists (see

There is a small typo "on the on".

> +the respective section below).  For several kernel subsystems, this
> +submission and review process is tracked with the tool patchwork.
> +Patchwork offers a web interface which shows patch postings, any
> +comments on a patch or revisions to it, and maintainers can mark patches
> +as under review, accepted, or rejected.  Most of these patchwork sites
> +are listed at http://patchwork.kernel.org/ or http://patchwork.ozlabs.org/.
> +
> +2.6.x -next kernel tree for integration tests
> +---------------------------------------------
> +Before updates from subsystem trees are merged into the mainline 2.6.x
> +tree, they need to be integration-tested.  For this purpose, a special
> +testing repository exists into which virtually all subsystem trees are
> +pulled on an almost daily basis:
> +       http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
> +       http://linux.f-seidel.de/linux-next/pmwiki/
> +
> +This way, the -next kernel gives a summary outlook onto what will be
> +expected to go into the mainline kernel at the next merge period.
> +Adventurous testers are very welcome to runtime-test the -next kernel.
>
> -  Other kernel trees can be found listed at http://git.kernel.org/ and in
> -  the MAINTAINERS file.
>
>  Bug Reporting
>  -------------
>
> --
> Stefan Richter
> -=====-==-=- ---= -===-
> http://arcgraph.de/sr/
>

Loïc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/