Including Raspberry Pi -next trees in linux-next

Including Raspberry Pi -next trees in linux-next

[Eric Anholt]

I'll be sending pull-requests to Florian soon, but I would like to get
my trees included in linux-next to get increased testing coverage of
them against everything else going on for 4.5.  I'm expecting to produce
trees under these branch names for the forseeable future.

Repo: https://github.com/anholt/linux.git

branches:
drm-vc4-next
bcm2835-dt-next
bcm2835-soc-next
bcm2835-drivers-next
bcm2385-defconfig-next
(bcm2835-maintainers-next is a placeholder since we have nothing for it
this round)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151226/6f657379/attachment.sig>

Including Raspberry Pi -next trees in linux-next

[Stephen Rothwell]

Hi Eric,

On Sat, 26 Dec 2015 13:15:50 -0800 Eric Anholt <eric@anholt.net> wrote:
>
> I'll be sending pull-requests to Florian soon, but I would like to get
> my trees included in linux-next to get increased testing coverage of
> them against everything else going on for 4.5.  I'm expecting to produce
> trees under these branch names for the forseeable future.
> 
> Repo: https://github.com/anholt/linux.git
> 
> branches:
> drm-vc4-next
> bcm2835-dt-next
> bcm2835-soc-next
> bcm2835-drivers-next
> bcm2385-defconfig-next
> (bcm2835-maintainers-next is a placeholder since we have nothing for it
> this round)

I have added the first 5 from today.  Can you tell me which trees they
will be merged via so I can position them in my list correctly,
please?

Also, I was wondering how they relate to the bcm2835 tree I currently
have (git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
for-next) currently maintained by Stephen Warren (cc'd).

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 at canb.auug.org.au

Including Raspberry Pi -next trees in linux-next

[Eric Anholt]

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Eric,
>
> On Sat, 26 Dec 2015 13:15:50 -0800 Eric Anholt <eric@anholt.net> wrote:
>>
>> I'll be sending pull-requests to Florian soon, but I would like to get
>> my trees included in linux-next to get increased testing coverage of
>> them against everything else going on for 4.5.  I'm expecting to produce
>> trees under these branch names for the forseeable future.
>> 
>> Repo: https://github.com/anholt/linux.git
>> 
>> branches:
>> drm-vc4-next
>> bcm2835-dt-next
>> bcm2835-soc-next
>> bcm2835-drivers-next
>> bcm2385-defconfig-next
>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
>> this round)
>
> I have added the first 5 from today.  Can you tell me which trees they
> will be merged via so I can position them in my list correctly,
> please?

drm-vc4-next goes through airlied's drm-next.  bcm2835-* are intended to
go through Florian's stblinux tree, though things didn't go that way
this time because I'm still figuring out timelines.

Looking through Next/Trees, it looks like stblinux isn't in the list.
That seems like something that would be useful, given that Florian's
been successfully sending pull requests to arm-soc for at least a couple
of releases.  (<1445718981-13552-1-git-send-email-f.fainelli@gmail.com>,
for example).  His branches appear to be defconfig/next,
devicetree/next, maintainers/next, and soc/next, all on
https://github.com/Broadcom/stblinux.git.

> Also, I was wondering how they relate to the bcm2835 tree I currently
> have (git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> for-next) currently maintained by Stephen Warren (cc'd).

Stephen and Lee have limited time to work on 2835 as it's only been a
free-time project for them afaict.  I offered to help on the merging
process, since it's job related.  I don't have kernel.org access any
more I think, and it turns out github process is familiar to 2835's
potential contributors, so it's working out quite well to host the
branches there.  They're still chiming in with acks and feedback when
time permits, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160105/3c8184ac/attachment.sig>

Including Raspberry Pi -next trees in linux-next

[Florian Fainelli]

On 05/01/16 12:06, Eric Anholt wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
>> Hi Eric,
>>
>> On Sat, 26 Dec 2015 13:15:50 -0800 Eric Anholt <eric@anholt.net> wrote:
>>>
>>> I'll be sending pull-requests to Florian soon, but I would like to get
>>> my trees included in linux-next to get increased testing coverage of
>>> them against everything else going on for 4.5.  I'm expecting to produce
>>> trees under these branch names for the forseeable future.
>>>
>>> Repo: https://github.com/anholt/linux.git
>>>
>>> branches:
>>> drm-vc4-next
>>> bcm2835-dt-next
>>> bcm2835-soc-next
>>> bcm2835-drivers-next
>>> bcm2385-defconfig-next
>>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
>>> this round)
>>
>> I have added the first 5 from today.  Can you tell me which trees they
>> will be merged via so I can position them in my list correctly,
>> please?
> 
> drm-vc4-next goes through airlied's drm-next.  bcm2835-* are intended to
> go through Florian's stblinux tree, though things didn't go that way
> this time because I'm still figuring out timelines.
> 
> Looking through Next/Trees, it looks like stblinux isn't in the list.
> That seems like something that would be useful, given that Florian's
> been successfully sending pull requests to arm-soc for at least a couple
> of releases.  (<1445718981-13552-1-git-send-email-f.fainelli@gmail.com>,
> for example).  His branches appear to be defconfig/next,
> devicetree/next, maintainers/next, and soc/next, all on
> https://github.com/Broadcom/stblinux.git.

Correct, there is also devicetree-arm64/next for ARM64 DTS changes,
which could be helpful to have.
-- 
Florian

Including Raspberry Pi -next trees in linux-next

[Stephen Warren]

On 01/05/2016 01:06 PM, Eric Anholt wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
>> Hi Eric,
>>
>> On Sat, 26 Dec 2015 13:15:50 -0800 Eric Anholt <eric@anholt.net> wrote:
>>>
>>> I'll be sending pull-requests to Florian soon, but I would like to get
>>> my trees included in linux-next to get increased testing coverage of
>>> them against everything else going on for 4.5.  I'm expecting to produce
>>> trees under these branch names for the forseeable future.
>>>
>>> Repo: https://github.com/anholt/linux.git
>>>
>>> branches:
>>> drm-vc4-next
>>> bcm2835-dt-next
>>> bcm2835-soc-next
>>> bcm2835-drivers-next
>>> bcm2385-defconfig-next
>>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
>>> this round)

Typically maintainers merge everything together into a single "for-next" 
to maintain a reasonable set of branches. I guess it doesn't affect me 
so my opinion isn't too relevant though:-)

>> I have added the first 5 from today.  Can you tell me which trees they
>> will be merged via so I can position them in my list correctly,
>> please?
>
> drm-vc4-next goes through airlied's drm-next.  bcm2835-* are intended to
> go through Florian's stblinux tree, though things didn't go that way
> this time because I'm still figuring out timelines.
>
> Looking through Next/Trees, it looks like stblinux isn't in the list.
> That seems like something that would be useful, given that Florian's
> been successfully sending pull requests to arm-soc for at least a couple
> of releases.  (<1445718981-13552-1-git-send-email-f.fainelli@gmail.com>,
> for example).  His branches appear to be defconfig/next,
> devicetree/next, maintainers/next, and soc/next, all on
> https://github.com/Broadcom/stblinux.git.
>
>> Also, I was wondering how they relate to the bcm2835 tree I currently
>> have (git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>> for-next) currently maintained by Stephen Warren (cc'd).
>
> Stephen and Lee have limited time to work on 2835 as it's only been a
> free-time project for them afaict.  I offered to help on the merging
> process, since it's job related.  I don't have kernel.org access any
> more I think, and it turns out github process is familiar to 2835's
> potential contributors, so it's working out quite well to host the
> branches there.  They're still chiming in with acks and feedback when
> time permits, though.

It'd be quite easy to get you access to the existing kernel.org bcm2835 
tree though; just get an account there and the admins can add you to the 
ACL.

Including Raspberry Pi -next trees in linux-next

[Arnd Bergmann]

On Tuesday 05 January 2016 13:22:49 Stephen Warren wrote:
> >>>
> >>> branches:
> >>> drm-vc4-next
> >>> bcm2835-dt-next
> >>> bcm2835-soc-next
> >>> bcm2835-drivers-next
> >>> bcm2385-defconfig-next
> >>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
> >>> this round)
> 
> Typically maintainers merge everything together into a single "for-next" 
> to maintain a reasonable set of branches. I guess it doesn't affect me 
> so my opinion isn't too relevant though:-)

In my experience the common for-next branch works best because
you can change the set of branches that get merged into it as
needed. If there are 6 branches today, it's quite likely that there
will be another one in the future and if only one branch gets
merged into for-next, you don't need to worry about updating the list.

	Arnd

Including Raspberry Pi -next trees in linux-next

[Stephen Rothwell]

Hi Eric,

On Tue, 05 Jan 2016 22:26:33 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tuesday 05 January 2016 13:22:49 Stephen Warren wrote:
> > >>>
> > >>> branches:
> > >>> drm-vc4-next
> > >>> bcm2835-dt-next
> > >>> bcm2835-soc-next
> > >>> bcm2835-drivers-next
> > >>> bcm2385-defconfig-next
> > >>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
> > >>> this round)  
> > 
> > Typically maintainers merge everything together into a single "for-next" 
> > to maintain a reasonable set of branches. I guess it doesn't affect me 
> > so my opinion isn't too relevant though:-)  
> 
> In my experience the common for-next branch works best because
> you can change the set of branches that get merged into it as
> needed. If there are 6 branches today, it's quite likely that there
> will be another one in the future and if only one branch gets
> merged into for-next, you don't need to worry about updating the list.

Certainly, that would be easier for me.  Though you may want to keep
the drm-vc4-next branch separate since that get merged via a different
tree (and can appear at a different point in my merge list).

It does mean an extra step for you i.e. you would need to merge all the
relevant branches into the single "for-next" branch, but that should
not be too big an imposition.
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

Including Raspberry Pi -next trees in linux-next

[Stephen Warren]

On 01/05/2016 03:32 PM, Stephen Rothwell wrote:
> Hi Eric,
>
> On Tue, 05 Jan 2016 22:26:33 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tuesday 05 January 2016 13:22:49 Stephen Warren wrote:
>>>>>>
>>>>>> branches:
>>>>>> drm-vc4-next
>>>>>> bcm2835-dt-next
>>>>>> bcm2835-soc-next
>>>>>> bcm2835-drivers-next
>>>>>> bcm2385-defconfig-next
>>>>>> (bcm2835-maintainers-next is a placeholder since we have nothing for it
>>>>>> this round)
>>>
>>> Typically maintainers merge everything together into a single "for-next"
>>> to maintain a reasonable set of branches. I guess it doesn't affect me
>>> so my opinion isn't too relevant though:-)
>>
>> In my experience the common for-next branch works best because
>> you can change the set of branches that get merged into it as
>> needed. If there are 6 branches today, it's quite likely that there
>> will be another one in the future and if only one branch gets
>> merged into for-next, you don't need to worry about updating the list.
>
> Certainly, that would be easier for me.  Though you may want to keep
> the drm-vc4-next branch separate since that get merged via a different
> tree (and can appear at a different point in my merge list).
>
> It does mean an extra step for you i.e. you would need to merge all the
> relevant branches into the single "for-next" branch, but that should
> not be too big an imposition.

FWIW, I almost always build/test the for-next branch rather than (or 
sometimes in addition to) the individual branches, and since I do so 
much with that branch, I use some scripts to automate generating it, and 
pushing all the branches to kernel.org. The Tegra version of those 
scripts is at:

> https://git.kernel.org/cgit/linux/kernel/git/tegra/maint-scripts.git/tree/

In particular, see merge-linux-tegra.sh and its configuration file 
tegra-branches.sh.dot. Also push-linux-tegra.sh does all the pushes.