The Wrapper Project

[Andrew Bartlett]

On Fri, 2013-11-22 at 18:49 +0100, Andreas Schneider wrote:
> On Wednesday 20 November 2013 22:58:34 Jelmer Vernooij wrote:
> > On Wed, Nov 20, 2013 at 11:06:08PM +0100, Andreas Schneider wrote:
> > > On Wednesday 20 November 2013 22:17:24 Jelmer Vernooij wrote:
> > > > On Wed, Nov 20, 2013 at 08:41:02PM +0100, Andreas Schneider wrote:
> > > > > On Wednesday 20 November 2013 19:59:35 Jelmer Vernooij wrote:
> > > > > > On Wed, Nov 20, 2013 at 01:23:33PM -0500, Simo wrote:
> > > > > > > Yes the code that originated Andreas projects came from Samba.
> > > > > > > Andreas ran away with to try and see if it could be greatly
> > > > > > > improved.
> > > > > > > 
> > > > > > > For a lot of time it was just hacking around to see if it would
> > > > > > > work.
> > > > > > > 
> > > > > > > Some times that approach works better, and I am certain in this
> > > > > > > case
> > > > > > > did, because it would have been unacceptable to the samba
> > > > > > > community to
> > > > > > > break "make test" to do experiments.
> > > > > > 
> > > > > > Nobody is objecting to Andreas' taking this code and hacking on it.
> > > > > > 
> > > > > > > I really do not see why this is a big deal to be honest. Why does
> > > > > > > it
> > > > > > > make any difference how the code was built ?
> > > > > > 
> > > > > > Andreas is proposing moving a chunk of code out of the Samba
> > > > > > codebase
> > > > > > taking over maintenance of it, removing it from Samba and having
> > > > > > Samba
> > > > > > depend on that code. [1]
> > > > > > 
> > > > > > This means that code to which everybody in the Samba team could
> > > > > > easily
> > > > > > contribute to previously is now harder to edit, harder to follow,
> > > > > > and
> > > > > > changes to it are no longer necessarily audited.
> > > > > 
> > > > > Yes, that was set in stone. No review is allowed by others! Where kind
> > > > > of
> > > > > a
> > > > > game do we play here now? :)
> > > > 
> > > > We're only pointing out the consequences of the proposal we're not
> > > > comfortable with - that those libraries are being developed
> > > > "off-the-record",
> > > > but still proposed for use in Samba.
> > > > 
> > > > Nobody said the way these libraries are developed was set in stone; in
> > > > fact, I think the reason it was mentioned at all was so that it
> > > > hopefully can change...
> > > > 
> > > > > > > What difference does it make if you get a review request of 200
> > > > > > > patches
> > > > > > > that basically reworks completely most of the code or a request to
> > > > > > > review something of equal size with a git tree somewhere else ?
> > > > > > > 
> > > > > > > Sound like you are offended that some code was done on someone's
> > > > > > > own
> > > > > > > without your knowledge, is that the problem ?
> > > > > > 
> > > > > > No, I'm objecting to the suggested changes *to Samba* on the grounds
> > > > > > that it makes it harder for me to make changes to and follow the
> > > > > > evolution of a piece of code that I originally wrote.
> > > > > 
> > > > > And it makes it harder for *me* get them correctly working as
> > > > > pre-loadable
> > > > > wrappers and to propose it to other projects.
> > > > 
> > > > How does it make it harder for you? What is problematic about hosting
> > > > those
> > > > git repositories on git.samba.org, with commit access for and review
> > > > from
> > > > the rest of the team?
> > > 
> > > Hey, I've discussed this already with Volker, likely also on the list,
> > > that
> > > the plan is to put them on git.samba.org and to go back to a mandatory
> > > review once they are considered stable. My work is not finished and I'm
> > > still struggling with some parts. A lot of tests are till missing. Only
> > > nss_wrapper has 75% code coverage. Till now nobody asked me if we could
> > > create repos for the three of them on git.samba.org and create hooks to
> > > get mails while I still work on them and have daily changes of things I
> > > just need to try out. Maybe this would be a start.
> > 
> > Thanks, that's great to hear.
> > 
> > Does that also mean that - once you're done with your improvements in
> > your scratch repos - you're going to propose patches to the existing
> > samba.git code to land your improvements, and then eventually split
> > them out into their own repos?
> 
> I still would prefer that they reside in their own repo and you download, 
> compile and install them like the rest of the free software projects we use.

One of the oddities of Samba is that we don't do that very much at all.
We are very hesitant to rely on external free software projects, for
better or worse. 

In this case, I'm particularly hesitant about the idea of requiring it
to be installed to permit testing, because our build farm, old, unloved
and broken as it is, is a particularly poor environment for requiring
the installation of external software.  

As I've said before, in my previous work on this code, I've found and
fixed some very subtle bugs that show up only in bizarre results in our
make test.  I would want to ensure we had a very strict rule as to
exactly the version of these wrappers that we used against a specific
version of Samba.  I think bundling these like we do popt et al is the
best approach for now. 

The other thing I would miss is the ability to invoke this via CPP
macros.  We removed smb_wrapper because we determined the LD_PRELOAD
approach was determined not to be viable in the long term.  I guess the
difference here is that the socket API is more limited, as because CPP
also can't override libc calls, we have altered all the callers anyway.

It would, even as he has left Samba development, be insightful to ask
for Tridge's view on this, because he has more experience than anyone
else I know on LD_PRELOAD over many years. 

Thanks,

Andrew Bartlett


-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org