Subject: Re: linux-next: add s390 set_fs branch?

From: Stephen Rothwell <[email-masked]>
Date: Wed, 16 Sep 2020 09:54:37 +1000

Hi Heiko,

On Tue, 15 Sep 2020 17:55:34 +0200 Heiko Carstens <[email-masked]> wrote:
>
> could you please add the 'set_fs' branch of the s390 kernel.org
> repository to linux-next?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git set_fs
> 
> I'm wondering what the best way would be to deal with additional s390
> specific topic branches and how to get them merged into linux-next?
> 
> As far as I can tell other maintainers merge all their branches into a
> 'for-next' branch, so that you only need to pull one branch (and don't
> need to deal with requests like this one ;) ).
> 
> Would that the best way for you? If so we could simply do the same for
> s390 as well. Please let us know.

Yes, normally maintainers merge their topic branches into a single
"for-next" (or similar) branch for me to merge.  However, in some cases
I carry separate topic branches.  So what ever is easiest.

I have added the set_fs branch today (I called it s390-setfs).  If this
is going to be short lived (or you decide to do the merge yourself),
please try to remember to tell me to remove it when it is done with.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement 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]