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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ