[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201204181100.40123.arnd@arndb.de>
Date: Wed, 18 Apr 2012 11:00:39 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Roland Stigge <stigge@...com.de>, devel@...verdev.osuosl.org,
srinivas.bakki@....com, linux-usb@...r.kernel.org,
broonie@...nsource.wolfsonmicro.com, gregkh@...uxfoundation.org,
thierry.reding@...onic-design.de, linux-kernel@...r.kernel.org,
kevin.wells@....com, marek.vasut@...il.com, arm@...nel.org,
linux-input@...r.kernel.org, axel.lin@...il.com,
dmitry.torokhov@...il.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/8] Second patchset for LPC32xx device tree conversion
On Wednesday 18 April 2012, Dan Carpenter wrote:
> I'm not sure I understand. I thought everyone used the develop
> against linux-next and backport the fixes model. Are we going to
> try merge these in 3.4? It will still spend some time in linux-next
> before we submit it, right?
Correct, but the point is that you cannot add patches on top of -next
and have them included in a future -next version, because they never
merge cleanly.
The ideal workflow is:
1. develop on -rc
2. merge with latest -next, test and make sure it works there
3. submit for review against -rc
4. have patches included in -next once reviewed, but based on -rc
5. when merge window opens, have patches sent for upstream inclusion
The last two steps are slightly different for your own subsystem
compared to someone else's subsystem: In this case, Roland is the
author and sends the patches to me to have them included in -next
and I send them to Linus in the next merge window.
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