All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] at91: fixes for 3.19 #1 (bis)
Date: Mon, 12 Jan 2015 17:52:48 +0100	[thread overview]
Message-ID: <54B3FBE0.6020603@atmel.com> (raw)
In-Reply-To: <8332277.8EH8fqiOd7@wuerfel>

Le 12/01/2015 16:59, Arnd Bergmann a ?crit :
> On Monday 12 January 2015 16:08:14 Nicolas Ferre wrote:
>> Le 11/01/2015 22:12, Olof Johansson a ?crit :
>>> On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
>>>> Le 08/01/2015 23:41, Olof Johansson a ?crit :
>>>>> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
>>>>>
>>>>> This is the only fix among these patches, isn't it? The others seem to
>>>>> be code removals/cleanups better targeted for 3.20, as far as I can tell.
>>>>
>>>> Well, this is why I sent the first version of this pull-request very
>>>> early in the process. I didn't have the possibility to re-send it
>>>> earlier on top of -rc1 until this pull-request.
> 
> I think this was a bit of a communication problem. I thought about
> applying the first pull request you sent for this, but then Kevin
> commented that it would be better to rebase it on top of -rc1.
> That made sense at the time, except then we all got caught by
> surprise by Christmas and suddenly it was -rc4 ;-)

Exactly, by surprise like every year ;-)

>>> Since you mention that you have more fixes coming (why hold off on them?), do
>>> you want me to cherry-pick over that one fix to our fixes branch, or can you
>>> queue it with the other fixes when you send them up?
>>
>> Fair enough, I build a new "at91: fixes for 3.19 #1 (ter)" with tree
>> more patches right now.
> 
> This seems for the best now. This kind of late cleanup that depends on
> multiple branches going in first happens occasionally and it's never
> nice whichever way you try to handle it.
> 
> The only recommendation I have for the future is to discuss the merge
> strategy with us before the merge window instead of holding back patches
> that have other dependencies. I don't really mind merging them as a
> late branch into -rc1 if I know about them, but we should never plan
> to merge any non-bugfix patches later than -rc2.

Sure. I'll try to do better next time.
I began to create the at91-3.20-cleanup branch with this late material
and all will be fine anyway.

Thanks, bye.
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	<arm@kernel.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Boris BREZILLON <boris.brezillon@free-electrons.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"Ludovic Desroches" <ludovic.desroches@atmel.com>
Subject: Re: [GIT PULL] at91: fixes for 3.19 #1 (bis)
Date: Mon, 12 Jan 2015 17:52:48 +0100	[thread overview]
Message-ID: <54B3FBE0.6020603@atmel.com> (raw)
In-Reply-To: <8332277.8EH8fqiOd7@wuerfel>

Le 12/01/2015 16:59, Arnd Bergmann a écrit :
> On Monday 12 January 2015 16:08:14 Nicolas Ferre wrote:
>> Le 11/01/2015 22:12, Olof Johansson a écrit :
>>> On Fri, Jan 09, 2015 at 10:02:50AM +0100, Nicolas Ferre wrote:
>>>> Le 08/01/2015 23:41, Olof Johansson a écrit :
>>>>> On Mon, Jan 05, 2015 at 12:14:37PM +0100, Nicolas Ferre wrote:
>>>>>
>>>>> This is the only fix among these patches, isn't it? The others seem to
>>>>> be code removals/cleanups better targeted for 3.20, as far as I can tell.
>>>>
>>>> Well, this is why I sent the first version of this pull-request very
>>>> early in the process. I didn't have the possibility to re-send it
>>>> earlier on top of -rc1 until this pull-request.
> 
> I think this was a bit of a communication problem. I thought about
> applying the first pull request you sent for this, but then Kevin
> commented that it would be better to rebase it on top of -rc1.
> That made sense at the time, except then we all got caught by
> surprise by Christmas and suddenly it was -rc4 ;-)

Exactly, by surprise like every year ;-)

>>> Since you mention that you have more fixes coming (why hold off on them?), do
>>> you want me to cherry-pick over that one fix to our fixes branch, or can you
>>> queue it with the other fixes when you send them up?
>>
>> Fair enough, I build a new "at91: fixes for 3.19 #1 (ter)" with tree
>> more patches right now.
> 
> This seems for the best now. This kind of late cleanup that depends on
> multiple branches going in first happens occasionally and it's never
> nice whichever way you try to handle it.
> 
> The only recommendation I have for the future is to discuss the merge
> strategy with us before the merge window instead of holding back patches
> that have other dependencies. I don't really mind merging them as a
> late branch into -rc1 if I know about them, but we should never plan
> to merge any non-bugfix patches later than -rc2.

Sure. I'll try to do better next time.
I began to create the at91-3.20-cleanup branch with this late material
and all will be fine anyway.

Thanks, bye.
-- 
Nicolas Ferre

  reply	other threads:[~2015-01-12 16:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-05 11:14 [GIT PULL] at91: fixes for 3.19 #1 (bis) Nicolas Ferre
2015-01-05 11:14 ` Nicolas Ferre
2015-01-08 22:41 ` Olof Johansson
2015-01-08 22:41   ` Olof Johansson
2015-01-09  9:02   ` Nicolas Ferre
2015-01-09  9:02     ` Nicolas Ferre
2015-01-11 21:12     ` Olof Johansson
2015-01-11 21:12       ` Olof Johansson
2015-01-12 15:08       ` Nicolas Ferre
2015-01-12 15:08         ` Nicolas Ferre
2015-01-12 15:59         ` Arnd Bergmann
2015-01-12 15:59           ` Arnd Bergmann
2015-01-12 16:52           ` Nicolas Ferre [this message]
2015-01-12 16:52             ` Nicolas Ferre

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=54B3FBE0.6020603@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 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.