[PATCH] Fix the last of the defaults and include a test to check them

Michael Adam obnox at samba.org
Tue Feb 4 03:02:20 MST 2014

Hi Garming,

On 2014-02-04 at 17:00 +1300, Garming Sam wrote:
> On 04/02/14 12:42, Garming Sam wrote:
> >
> >git://git.catalyst.net.nz/samba.git  param-wip
> >
> >http://git.catalyst.net.nz/gitweb?p=samba.git;a=shortlog;h=refs/heads/param-wip
> >
> >
> >Just looking through the remaining meta-data patches, it looks
> >like they're all simply the ones which add a function name and
> >were originally marked TODO.
> >
> >I know it's a bit ugly to revert, but I think the only real
> >alternative would be to really get those renames right here and
> >now and so I can fix it all at once.
> I decided it would be better to just get it out of the way and spent
> the time doing the renames.

Great! I think that is the better approach.

I didn't understand your remark about the reverts above anyways..  :-)
I think we should simply skip the metadata-adding-function
patches as far as possible by doing the renames.

> It was scripted and they've been looked over individually.
> Branch full of renames:
> git://git.catalyst.net.nz/samba.git  polished-param5
> http://git.catalyst.net.nz/gitweb?p=samba.git;a=shortlog;h=refs/heads/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

> 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?

> All in all, there's not too many of them left and they can
> easily be done manually.
> With these in, we should be able to get the generation in as well
> without too much hassle.


Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 215 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140204/8c311783/attachment.pgp>

More information about the samba-technical mailing list