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:
signature.asc
Description: Digital signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
