Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300521 > unrolled thread

Re: Including Raspberry Pi -next trees in linux-next

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Including Raspberry Pi -next trees in linux-next Stephen Rothwell <sfr@canb.auug.org.au> - 2016-01-04 08:30 +0100
    Re: Including Raspberry Pi -next trees in linux-next Eric Anholt <eric@anholt.net> - 2016-01-05 21:10 +0100
      Re: Including Raspberry Pi -next trees in linux-next Florian Fainelli <f.fainelli@gmail.com> - 2016-01-05 21:20 +0100
      Re: Including Raspberry Pi -next trees in linux-next Stephen Warren <swarren@wwwdotorg.org> - 2016-01-05 21:30 +0100
        Re: Including Raspberry Pi -next trees in linux-next Arnd Bergmann <arnd@arndb.de> - 2016-01-05 22:30 +0100
          Re: Including Raspberry Pi -next trees in linux-next Stephen Rothwell <sfr@canb.auug.org.au> - 2016-01-05 23:40 +0100
            Re: Including Raspberry Pi -next trees in linux-next Stephen Warren <swarren@wwwdotorg.org> - 2016-01-06 00:00 +0100

#1300521 — Re: Including Raspberry Pi -next trees in linux-next

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@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1302012

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1302044

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302071

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302227

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302250

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@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302257

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web