linux-kernel - linux-next: procedures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081112173807.05cfadf0.sfr@canb.auug.org.au>
Date:	Wed, 12 Nov 2008 17:38:07 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	linux-next@...r.kernel.org
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: linux-next: procedures

Hi all,

I just though I would send out a reminder and clarification of the
procedures around the linux-next tree.

Prerequisites for inclusion of a tree (a branch of a git tree or a quilt
series) in linux-next:

	- all its commits/patches have been posted to appropriate mailing
lists
	- they have all been reviewed
	- the tree has been "unit tested"
	- the tree is destined for the next merge window (except during a
merge window when only changes destined for the current merge window
should be there).

So, to be clear, the posting, reviewing and testing should be done
*before* commits/patches are added to linux-next.  linux-next is meant to
be for integration testing only i.e. the trees should be as close to what
will be sent to Linus as possible (but may need changes to cope with
changes in other subsystems/architectures).

These trees should be usually based on Linus' tree.  In some cases there
will be dependencies and we will deal with these on a case by case basis
(there have not been many so far).

The following will cause a tree to be temporarily dropped from linux-next:
	- non-trivial conflicts with Linus' tree
	- build failures
	- non-obvious conflicts with other trees (this will require
us to come up with some way forward for the trees involved)
	- the contact for the tree being unresponsive

Most conflicts will be notified to the contacts for the trees involved
(some really trivial ones will not).  Simple conflicts between trees I
will try to fix up (if possible) and carry such resolutions as necessary.

I will not, any more, carry fix up patches to make linux-next build or
boot.  If a tree is identified as causing such a problem, it will be
dropped until the problem is fixed.

This is all open to discussion ...

The result I am aiming for is that during a merge window, the trees in
linux-next are sent to Linus verbatim (or with minor conflict fixups) by
their owners and the linux-next ends up basically empty (wrt Linus' tree)
when -rc1 is released (except for a few trees that need to be merged
late).  At other times linux-next should be in a state that Andrew can
use it as the basis for an -mm release without to much pain.

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/

Content of type "application/pgp-signature" skipped