From: Lee Jones <lee.jones@linaro.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"Olof Johansson" <olof@lixom.net>,
"Matthias Klein" <matthias.klein@linux.com>,
"Hauke Mehrtens" <hauke@hauke-m.de>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org
Subject: Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree
Date: Tue, 9 Dec 2014 08:21:12 +0000 [thread overview]
Message-ID: <20141209082112.GQ3951@x1> (raw)
In-Reply-To: <5485E1EA.2070902@wwwdotorg.org>
On Mon, 08 Dec 2014, Stephen Warren wrote:
> On 12/08/2014 09:51 AM, Lee Jones wrote:
> >On Mon, 08 Dec 2014, Stephen Warren wrote:
> ...
> >>The primary purpose of the kernel.org linux-rpi.git repo is for
> >>staging patches into arm-soc/linux-next. As such, just like any
> >>other similar repo, users should expect at least the for-xxx (e.g.
> >>for-next) branches to get reset as kernel versions tick over, in
> >>order to contain the content for the next kernel. Anyone using those
> >>branches for anything else (e.g. local development) simply has to be
> >>prepared to do a rebase themselves when that happens.
> >
> >I agree with this.
> >
> >>Equally, and patches that get sent to arm-soc should probably never
> >>be applied to linux-rpi.git; anything that gets applied to
> >>linux-rpi.git should get sent to arm-soc as a pull request. That
> >>avoids duplicate commits.
> >
> >I'm okay to follow this rule if my perception of the tree is changed.
> >The current view is that this repo can be used by engineers/hobbyists
> >as a single resource to pick up RPi patches which are yet to complete
> >their full transition into Mainline.
> >
> >Arnd and I had a discussion where I flagged my concerns about these
> >kinds of conflicts. The outcome was that as long as the patches were
> >simple enough, then no conflict should arise. Unfortunately this
> >turned out not to be quite true.
> >
> >So I'm happy with whatever. Stephen, the repo is your concept. I'll
> >play it however you want me to play it. As the merge-window is now
> >open I'm going to eradicate rpi/for-next in any case.
>
> Eradicate or reset? If you delete it, Stephen Rothwell will have a
> problem fetching it when creating linux-next. Usually to empty out
> the for-next branch, you'd reset it to some recent Linus tag; 3.18
> seems like a good one at present.
Yes, in this case eradicate == `git reset <blah>`.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-next: manual merge of the bcm2835 tree with the arm-soc tree
Date: Tue, 9 Dec 2014 08:21:12 +0000 [thread overview]
Message-ID: <20141209082112.GQ3951@x1> (raw)
In-Reply-To: <5485E1EA.2070902@wwwdotorg.org>
On Mon, 08 Dec 2014, Stephen Warren wrote:
> On 12/08/2014 09:51 AM, Lee Jones wrote:
> >On Mon, 08 Dec 2014, Stephen Warren wrote:
> ...
> >>The primary purpose of the kernel.org linux-rpi.git repo is for
> >>staging patches into arm-soc/linux-next. As such, just like any
> >>other similar repo, users should expect at least the for-xxx (e.g.
> >>for-next) branches to get reset as kernel versions tick over, in
> >>order to contain the content for the next kernel. Anyone using those
> >>branches for anything else (e.g. local development) simply has to be
> >>prepared to do a rebase themselves when that happens.
> >
> >I agree with this.
> >
> >>Equally, and patches that get sent to arm-soc should probably never
> >>be applied to linux-rpi.git; anything that gets applied to
> >>linux-rpi.git should get sent to arm-soc as a pull request. That
> >>avoids duplicate commits.
> >
> >I'm okay to follow this rule if my perception of the tree is changed.
> >The current view is that this repo can be used by engineers/hobbyists
> >as a single resource to pick up RPi patches which are yet to complete
> >their full transition into Mainline.
> >
> >Arnd and I had a discussion where I flagged my concerns about these
> >kinds of conflicts. The outcome was that as long as the patches were
> >simple enough, then no conflict should arise. Unfortunately this
> >turned out not to be quite true.
> >
> >So I'm happy with whatever. Stephen, the repo is your concept. I'll
> >play it however you want me to play it. As the merge-window is now
> >open I'm going to eradicate rpi/for-next in any case.
>
> Eradicate or reset? If you delete it, Stephen Rothwell will have a
> problem fetching it when creating linux-next. Usually to empty out
> the for-next branch, you'd reset it to some recent Linus tag; 3.18
> seems like a good one at present.
Yes, in this case eradicate == `git reset <blah>`.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-12-09 8:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 1:06 linux-next: manual merge of the bcm2835 tree with the arm-soc tree Stephen Rothwell
2014-12-08 1:06 ` Stephen Rothwell
2014-12-08 1:06 ` Stephen Rothwell
2014-12-08 11:25 ` Arnd Bergmann
2014-12-08 11:25 ` Arnd Bergmann
2014-12-08 13:00 ` Lee Jones
2014-12-08 13:00 ` Lee Jones
2014-12-08 13:28 ` Arnd Bergmann
2014-12-08 13:28 ` Arnd Bergmann
2014-12-08 13:49 ` Lee Jones
2014-12-08 13:49 ` Lee Jones
2014-12-08 15:08 ` Arnd Bergmann
2014-12-08 15:08 ` Arnd Bergmann
2014-12-08 16:08 ` Stephen Warren
2014-12-08 16:08 ` Stephen Warren
2014-12-08 16:51 ` Lee Jones
2014-12-08 16:51 ` Lee Jones
2014-12-08 17:37 ` Stephen Warren
2014-12-08 17:37 ` Stephen Warren
2014-12-09 8:21 ` Lee Jones [this message]
2014-12-09 8:21 ` Lee Jones
-- strict thread matches above, loose matches on Subject: below --
2014-03-09 12:14 Mark Brown
2014-03-03 1:02 Stephen Rothwell
2014-03-03 1:02 ` Stephen Rothwell
2014-03-03 1:02 ` Stephen Rothwell
2014-03-03 5:21 ` Stephen Warren
2014-03-03 5:21 ` Stephen Warren
2014-03-03 5:35 ` Olof Johansson
2014-03-03 5:35 ` Olof Johansson
2013-03-18 4:06 Stephen Rothwell
2013-03-18 4:06 ` Stephen Rothwell
2013-03-18 4:06 ` Stephen Rothwell
2013-03-18 4:04 Stephen Rothwell
2013-03-18 4:04 ` Stephen Rothwell
2013-03-18 4:04 ` Stephen Rothwell
2013-03-18 15:19 ` Stephen Warren
2013-03-18 15:19 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141209082112.GQ3951@x1 \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=hauke@hauke-m.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=matthias.klein@linux.com \
--cc=olof@lixom.net \
--cc=sfr@canb.auug.org.au \
--cc=swarren@wwwdotorg.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.