[PATCH] Second chunk of parameter internal variable renames

[Jeremy Allison]

On Sat, Jan 25, 2014 at 01:10:27PM +1300, Andrew Bartlett wrote:
> On Fri, 2014-01-24 at 15:51 -0800, Jeremy Allison wrote:
> > On Sat, Jan 25, 2014 at 12:24:32PM +1300, Andrew Bartlett wrote:
> > > On Fri, 2014-01-24 at 15:14 -0800, Jeremy Allison wrote:
> > > > On Fri, Jan 24, 2014 at 10:09:30PM +1300, Andrew Bartlett wrote:
> > > > > Alexander or Christian (or anyone else on the team interested),
> > > > > 
> > > > > Could you possibly review this second chunk of internal loadparm rename
> > > > > patches for me?
> > > > > 
> > > > > These patches are part of our branch at
> > > > > git://git.catalyst.net.nz/samba.git polished-param2
> > > > 
> > > > Hi Andrew,
> > > > 
> > > > I really tried hard to review+push these for you
> > > > ('cos the look completely boilerplate and safe
> > > > to me) but unfortunately this first one depends
> > > > on a missing patch - the patch matching algorithm
> > > > fails in lib/param/param_functions.c as the
> > > > FN_LOCAL_XXXX text doesn't match on the first
> > > > change. The second and subsequent patchsets
> > > > then have the same problem :-(.
> > > > 
> > > > Can you split out all the changes to the
> > > > CamelCase -> camel_case parameters into
> > > > one (large) set of patches patchset and
> > > > I'll review them all in one go. I think
> > > > that's the easiest way to stop running
> > > > into silly gotcha's like this and get
> > > > the rename in.
> > > 
> > > Certainly.  You probably didn't get the one I send Nadya, and it all
> > > fell down from there.  See attached for the full patch. 
> > 
> > Thanks. This LGTM. Let me pass it through a make
> > test then I'll push (might not be until Monday,
> > sorry).
> 
> Thanks.  Attached is a corrected patch due to a compile failure.  It
> looks like the szPrinterName patch I included (which we did later than
> the rest) depended on another patch elsewhere in the series.  This
> series excludes that patch, we can handle szPrinterName case later with
> the actual semantic changes. 

Yep. I'd discovered that and was in the middle of tracking
it down.

Thanks for the corrected fix :-).

Jeremy.