Re: [PATCH v2 0/8] Second patchset for LPC32xx device tree conversion

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

On Wed, Apr 18, 2012 at 08:06:16AM +0000, Arnd Bergmann wrote:
> On Tuesday 17 April 2012, Dan Carpenter wrote:

> > This probably applies fine (the previous version did a couple days
> > ago), but it's always best to submit patches against linux-next.
> > The 3.4 kernel is in -rc already so this is 3.5 material.

> I disagree. The patches won't get applied on -next, they get applied
> on an -rc release, so they should be submitted against that version
> as well. I agree that it makes sense to test patches against -next
> when there is reason to believe there might be conflicts, but it's
> not mandatory. When you know about conflicts against other patches
> that are already in -next, I suggest listing them in the cover 
> letter (the patch 0/x) and suggest a resolution.

Dan's advice is generally sensible for most subsystems - it's not so
much that you should submit against -next itself but rather that you
should be checking what you're submitting against the latest versions of
the subsystems to make sure that you're up to date with the latest APIs
and best practices.  -next is (or should be) a good proxy for this.

If you know the relevant subsystem and driver are pretty stable then
it's generally not going to be an issue to just use the -rcs but there's
enough areas where there's rapid development of one form or another it's
likely to save you at least one round trip of "that's nice but needs
some updates because it won't apply/won't build/isn't using this new
feature we want to convert everyone to" that it's a good default to
check with -next first.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]