Rename remaining lp variables and functions to be more consistent with their parameter name

Garming Sam garming at
Thu Feb 6 14:32:47 MST 2014

On 05/02/14 10:55, Garming Sam wrote:
> On 04/02/14 23:02, Michael Adam wrote:
>>> It was scripted and they've been looked over individually.
>>> Branch full of renames:
>>> git://  polished-param5
>> I will try to get around to reviewing them soon.
>>> The remaining meta data patches either somehow caused conflicts,
>> Should be easy to resolve these.
>> I can't currently imagine how they should cause conflicts.
>> Other patches must have been made to the same files in
>> the meantime. That has happened e.g. for the renames
>> I already did: firstly, I moved the type fixes in before
>> the metadata patches. There I already resovled all conflicts
>> in my master-param branch (the TODO patches on top...)
>> That's why I posted that branch in the first place.
>> Secondly for some of the renames, the corresponding
>> metadata patch not only added "function" but also
>> "parm" or "constant". So I modified those patches.
>> But again, these conflict resolutions should be rather straight.
>> I can help if you point me to a sepcific patch that is causing
>> problems.
>>> or the original name seemed more preferable, so opinions on those would
>>> be good. In some of the cases where the primary name for the
>>> parameter is less descriptive or more ambiguous, I would propose
>>> changing the name and using the old one as a synonym.
>> Sounds very reasonable in principle.
>> We need to decide that for each parameter individually.
>> Do you have a list? Or proposed patches with these
>> parameter renames?
> Just updated the branch with a fix to one of the patches, 'follow 
> symlinks' which I managed to catch with the new test.
> To be more clear about some of the ones left over, they're the ones 
> which caused unintended consequences with the scripted renames.
> The remaining meta data patches are:
>     disable spoolss - this one was a leftover parameter prefixed with _
>     default service - there is already an existing lpcfg_default_service
> These need to be done by hand:
>     log file
>     debug timestamp
> These are the ones where the rename seems to reduce clarity:
>     preload                        auto_services
>     wins support                we_are_a_wins_server
>     wins server                  wins_server_list
>     dns proxy                     wins_dns_proxy
> If we could get these existing patches in while we discuss the 
> remaining ones, that would be ideal.
> Cheers,
> Garming Sam

I've updated the polished-param5 branch to deal with a conflict and 
renamed a few of the patches (where the meta data is inserting a 
function name).


Garming Sam

More information about the samba-technical mailing list