All of lore.kernel.org
 help / color / mirror / Atom feed
* Including Raspberry Pi -next trees in linux-next
@ 2015-12-26 21:15 ` Eric Anholt
  0 siblings, 0 replies; 16+ messages in thread
From: Eric Anholt @ 2015-12-26 21:15 UTC (permalink / raw)
  To: sfr; +Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, Florian Fainelli

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

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)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2015-12-26 21:15 ` Eric Anholt
  0 siblings, 0 replies; 16+ messages in thread
From: Eric Anholt @ 2015-12-26 21:15 UTC (permalink / raw)
  To: linux-arm-kernel

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>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2015-12-26 21:15 ` Eric Anholt
@ 2016-01-04  7:26   ` Stephen Rothwell
  -1 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2016-01-04  7:26 UTC (permalink / raw)
  To: Eric Anholt
  Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel,
	Florian Fainelli, Stephen Warren

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-04  7:26   ` Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2016-01-04  7:26 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-04  7:26   ` Stephen Rothwell
@ 2016-01-05 20:06     ` Eric Anholt
  -1 siblings, 0 replies; 16+ messages in thread
From: Eric Anholt @ 2016-01-05 20:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel,
	Florian Fainelli, Stephen Warren

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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 20:06     ` Eric Anholt
  0 siblings, 0 replies; 16+ messages in thread
From: Eric Anholt @ 2016-01-05 20:06 UTC (permalink / raw)
  To: linux-arm-kernel

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>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-05 20:06     ` Eric Anholt
@ 2016-01-05 20:09       ` Florian Fainelli
  -1 siblings, 0 replies; 16+ messages in thread
From: Florian Fainelli @ 2016-01-05 20:09 UTC (permalink / raw)
  To: Eric Anholt, Stephen Rothwell
  Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, Stephen Warren

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 20:09       ` Florian Fainelli
  0 siblings, 0 replies; 16+ messages in thread
From: Florian Fainelli @ 2016-01-05 20:09 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-05 20:06     ` Eric Anholt
@ 2016-01-05 20:22       ` Stephen Warren
  -1 siblings, 0 replies; 16+ messages in thread
From: Stephen Warren @ 2016-01-05 20:22 UTC (permalink / raw)
  To: Eric Anholt, Stephen Rothwell
  Cc: linux-rpi-kernel, linux-arm-kernel, linux-kernel, Florian Fainelli

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 20:22       ` Stephen Warren
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Warren @ 2016-01-05 20:22 UTC (permalink / raw)
  To: linux-arm-kernel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-05 20:22       ` Stephen Warren
@ 2016-01-05 21:26         ` Arnd Bergmann
  -1 siblings, 0 replies; 16+ messages in thread
From: Arnd Bergmann @ 2016-01-05 21:26 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Stephen Warren, Eric Anholt, Stephen Rothwell, Florian Fainelli,
	linux-rpi-kernel, linux-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 21:26         ` Arnd Bergmann
  0 siblings, 0 replies; 16+ messages in thread
From: Arnd Bergmann @ 2016-01-05 21:26 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-05 21:26         ` Arnd Bergmann
@ 2016-01-05 22:32           ` Stephen Rothwell
  -1 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2016-01-05 22:32 UTC (permalink / raw)
  To: Eric Anholt
  Cc: Arnd Bergmann, linux-arm-kernel, Stephen Warren,
	Florian Fainelli, linux-rpi-kernel, linux-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 22:32           ` Stephen Rothwell
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Rothwell @ 2016-01-05 22:32 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Including Raspberry Pi -next trees in linux-next
  2016-01-05 22:32           ` Stephen Rothwell
@ 2016-01-05 22:52             ` Stephen Warren
  -1 siblings, 0 replies; 16+ messages in thread
From: Stephen Warren @ 2016-01-05 22:52 UTC (permalink / raw)
  To: Stephen Rothwell, Eric Anholt
  Cc: Arnd Bergmann, linux-arm-kernel, Florian Fainelli,
	linux-rpi-kernel, linux-kernel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Including Raspberry Pi -next trees in linux-next
@ 2016-01-05 22:52             ` Stephen Warren
  0 siblings, 0 replies; 16+ messages in thread
From: Stephen Warren @ 2016-01-05 22:52 UTC (permalink / raw)
  To: linux-arm-kernel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2016-01-05 22:52 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-26 21:15 Including Raspberry Pi -next trees in linux-next Eric Anholt
2015-12-26 21:15 ` Eric Anholt
2016-01-04  7:26 ` Stephen Rothwell
2016-01-04  7:26   ` Stephen Rothwell
2016-01-05 20:06   ` Eric Anholt
2016-01-05 20:06     ` Eric Anholt
2016-01-05 20:09     ` Florian Fainelli
2016-01-05 20:09       ` Florian Fainelli
2016-01-05 20:22     ` Stephen Warren
2016-01-05 20:22       ` Stephen Warren
2016-01-05 21:26       ` Arnd Bergmann
2016-01-05 21:26         ` Arnd Bergmann
2016-01-05 22:32         ` Stephen Rothwell
2016-01-05 22:32           ` Stephen Rothwell
2016-01-05 22:52           ` Stephen Warren
2016-01-05 22:52             ` Stephen Warren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.