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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Apr 2012 11:45:43 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	Roland Stigge <stigge@...com.de>, arm@...nel.org,
	linux-arm-kernel@...ts.infradead.org,
	thierry.reding@...onic-design.de, gregkh@...uxfoundation.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org, dmitry.torokhov@...il.com,
	axel.lin@...il.com, marek.vasut@...il.com,
	devel@...verdev.osuosl.org, kevin.wells@....com,
	srinivas.bakki@....com
Subject: Re: [PATCH v2 0/8] Second patchset for LPC32xx device tree conversion

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.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)