[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8332277.8EH8fqiOd7@wuerfel>
Date: Mon, 12 Jan 2015 16:59:27 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Nicolas Ferre <nicolas.ferre@...el.com>
Cc: Olof Johansson <olof@...om.net>, arm@...nel.org,
Linux Kernel list <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
Boris BREZILLON <boris.brezillon@...e-electrons.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Linus Walleij <linus.walleij@...aro.org>,
Ludovic Desroches <ludovic.desroches@...el.com>
Subject: Re: [GIT PULL] at91: fixes for 3.19 #1 (bis)
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 ;-)
> > 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.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists