Subject: Re: linux-next: New platform-drivers-x86 tree

From: Stephen Rothwell <[email-masked]>
Date: Mon, 8 Sep 2014 10:46:57 +1000

Hi Darren,

On Wed, 3 Sep 2014 20:18:07 +0100 Mark Brown <[email-masked]> wrote:
>
> On Tue, Sep 02, 2014 at 10:21:20PM -0700, Darren Hart wrote:
> > 
> > I searched the documentation (development-process/*) but found the linux-next
> > wiki to be down (for a while now it seems). Apologies if I'm missing something
> > documented there.
> 
> This is pretty much the process.  Stephen's on holiday this week, I've
> updated the configuration for the trees I'm building this week but you
> might want to check that this gets carried over when he's back on
> Monday.

I have updated my config files as well.

> > I have subscribed to the linux-next mailing list. Is there more I need to be
> > doing? Do I need to send you pull requests, or do you pull a list of branches
> > automatically?
> 
> It's all done automatically - for-next will be fetched for each -next
> build.  Stephen's form letter for this can be found in the archives, the
> main rule is that you should only be putting code there intended to go
> in during the merge window.

What Mark said :-)

The only other thing is the following legalese:

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 
[email-masked]