[PATCH] Fix the last of the defaults and include a test to check them
obnox at samba.org
Tue Feb 4 03:02:20 MST 2014
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
> >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
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
> 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...
Size: 215 bytes
Desc: Digital signature
More information about the samba-technical