On Mon, May 07, 2012 at 07:04:59PM +0100, Lee Jones wrote: > On 7 May 2012 17:58, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > This doesn't apply against current regulator code. > It doesn't? I rebased it onto -rc5 which was the latest at time of > submission. This isn't a bugfix that should be rushed into Linus' tree for 3.4! You're missing the best part of a release cycle of development here, including at least one incompatible API change. If you're developing new code you should always submit against the tree it's supposed to be applied to; as a rule of thumb -next is a good approximation though subsystems do things slightly differently, especially in the creation of topic branches. Even where the code will get applied to Linus' tree then merged as a new topic branch you should verify that there aren't any other changes in -next that affect it (eg, an API you rely on having changed or other changes to the same file which conflict with yours). > > Please also at least > > try to use changelogs that match the subsystem you're submitting > > against. > What do you mean? Isn't "drivers/regulator" in the subject line enough? As I said you should use changelogs that match the subsystem you are submitting against. Essentially nothing in the regulator tree uses this, as you should be able to see from inspection of the changelogs: $ git shortlog next/master drivers/regulator | wc -l 1059 $ git shortlog drivers/regulator | grep drivers/regulator | wc -l 6 Generally everything uses "regulator: ". You should always make an effort to do this for whatever subsystem you're working with.
Attachment:
signature.asc
Description: Digital signature