signal.git

signal.git

[Al Viro]

	Sorry for not having done that earlier; the tree is at
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal #for-next.
No non-trivial conflicts with akpm-base - only arch/*/Kconfig ones
coming from mainline.  A _lot_ of duplicates with akpm - 20 commits
from Matt and Oleg are all cherry-picked from there.

	I've included the recent uml.git pull request in there -
it's not in -next (and probably ought to be) and this time it
has a lot to do with the stuff being dealt with here.

	I hope to get task_work_add() series through that tree,
once all prereqs are there; I'll send heads-up before doing that,
since those patches are currently in akpm's patchset (and unfortunately
they do need a bunch of commits not in there to get them working on
all architectures - some of those prereqs are in this branch, some
will need to be moved to it from signal.git#master)

Re: signal.git

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

Hi Al,

On Wed, 23 May 2012 06:22:35 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> 	Sorry for not having done that earlier; the tree is at
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal #for-next.
> No non-trivial conflicts with akpm-base - only arch/*/Kconfig ones
> coming from mainline.  A _lot_ of duplicates with akpm - 20 commits
> from Matt and Oleg are all cherry-picked from there.
> 
> 	I've included the recent uml.git pull request in there -
> it's not in -next (and probably ought to be) and this time it
> has a lot to do with the stuff being dealt with here.
> 
> 	I hope to get task_work_add() series through that tree,
> once all prereqs are there; I'll send heads-up before doing that,
> since those patches are currently in akpm's patchset (and unfortunately
> they do need a bunch of commits not in there to get them working on
> all architectures - some of those prereqs are in this branch, some
> will need to be moved to it from signal.git#master)

OK, since a lot of this has been in Andrew's patch series for a while, I
will add this tree today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]