linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: ARM/ARM-SoC plans for v3.4 merge window
Date: Wed, 08 Feb 2012 11:52:51 +0000	[thread overview]
Message-ID: <4F326213.3030500@atmel.com> (raw)
In-Reply-To: <CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw@mail.gmail.com>

On 02/08/2012 02:18 AM, Olof Johansson :
> Hi,
> 
> On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 01/29/2012 12:57 AM, Olof Johansson :
>>> Hi,
>>>
>>>
>>> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>
>>>
>>>> And we're now there.  So...
>>>>
>>>> Arnd, Olaf,
>>>>
>>>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>>>
>>>>        git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>>>
>>>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>>>
>>> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>>>
>>> Any next/ branch we start will have this as the base of said branch,
>>> so any vendor branches must either already be developed against this
>>> stable branch, or merge on top of this with minimal conflicts.
>>
>> Ok, great.
>>
>> I just let you know that there is a conflict between the current Linus'
>> tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
>>
>> I can give you the resolution of this conflict easily but I would like
>> to know which way I execute the merge:
>>
>> I use this rmk/for-armsoc as a baseline and merge the fixes already in
>> Linus' tree on top of it or the other way around?
>>
>> Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
>> on top of it. This result can be the base of our AT91 work for 3.4
>> preparation.
>>
>> Your thought?
> 
> I missed replying to this email until now when I started looking at
> picking up branches for the 3.4 staging, sorry for the delay.
> 
> Russell, would you prefer merging in v3.3-rc2 into your branch so I
> can pull the exact same resolution from there, or should we do it
> locally in arm-soc? It probably makes sense for you to do it so
> there's no more conflicts from there on out for dependent branches.

Olof,

For your information the conflict resolution is already present in
linux-next (and in my 3.4 preparation branches actually).

Best regards,
-- 
Nicolas Ferre

  reply	other threads:[~2012-02-08 11:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 11:49 ARM/ARM-SoC plans for v3.4 merge window Russell King - ARM Linux
2012-01-24  9:50 ` Russell King - ARM Linux
2012-01-24 10:56   ` Will Deacon
2012-01-24 11:27     ` Russell King - ARM Linux
2012-01-24 11:45       ` Will Deacon
2012-01-26 21:23   ` Russell King - ARM Linux
2012-01-28 23:57     ` Olof Johansson
2012-01-30 10:08       ` Nicolas Ferre
2012-02-08  1:18         ` Olof Johansson
2012-02-08 11:52           ` Nicolas Ferre [this message]
2012-02-09  1:19             ` Olof Johansson

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=4F326213.3030500@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).