The Wrapper Project

Andreas Schneider asn at samba.org
Wed Nov 20 12:41:02 MST 2013


On Wednesday 20 November 2013 19:59:35 Jelmer Vernooij wrote:
> On Wed, Nov 20, 2013 at 01:23:33PM -0500, Simo wrote:
> > On Wed, 2013-11-20 at 19:09 +0100, Jelmer Vernooij wrote:
> > > On Wed, Nov 20, 2013 at 10:55:12AM -0500, Simo wrote:
> > > > On Wed, 2013-11-20 at 15:16 +0100, Jelmer Vernooij wrote:
> > > > > On Wed, Nov 20, 2013 at 03:14:34PM +0100, Andreas Schneider wrote:
> > > > > > On Wednesday 20 November 2013 15:04:00 Jelmer Vernooij wrote:
> > > > > > > On Wed, Nov 20, 2013 at 02:57:11PM +0100, Andreas Schneider 
wrote:
> > > > > > > > On Wednesday 20 November 2013 14:46:44 Jelmer Vernooij wrote:
> > > > > > > > > On Wed, Nov 20, 2013 at 02:35:38PM +0100, Andreas Schneider 
wrote:
> > > > > > > > > > On Wednesday 20 November 2013 13:24:59 Michael Adam wrote:
> > > > > > > > > > > I really like the idea of making these wrapper libraries
> > > > > > > > > > > generally useful and publish them separately for other
> > > > > > > > > > > projects
> > > > > > > > > > > to use for testing in other projects.
> > > > > > > > > > > 
> > > > > > > > > > > What I don't like at all is the approach to first rip
> > > > > > > > > > > them out
> > > > > > > > > > > of the samba tree, work on them completely off-record
> > > > > > > > > > > and then
> > > > > > > > > > > change samba to use these augmented external copies once
> > > > > > > > > > > they
> > > > > > > > > > > are ready.
> > > > > > > > > > > 
> > > > > > > > > > > I would have argued that our usual mode for development
> > > > > > > > > > > of
> > > > > > > > > > > features should have been applied: prepare stuff in a
> > > > > > > > > > > personal
> > > > > > > > > > > samba git repo/branch, present the patches for review,
> > > > > > > > > > > bring
> > > > > > > > > > > the changes into samba (so samba uses the new features
> > > > > > > > > > > internally
> > > > > > > > > > > as early as possible), have the improved system mature
> > > > > > > > > > > inside
> > > > > > > > > > > samba and then make an independent release. Maybe as the
> > > > > > > > > > > very
> > > > > > > > > > > last step externalize the source tree.
> > > > > > > > > > > 
> > > > > > > > > > > ...Just like for talloc, tevent, tdb, ...
> > > > > > > > > > > We have recently even decided to not externalize the
> > > > > > > > > > > code
> > > > > > > > > > > repositories of these three libraries, even though at
> > > > > > > > > > > least
> > > > > > > > > > > some of them can be considured mature enough and all of
> > > > > > > > > > > them
> > > > > > > > > > > are released separately and shipped with many linux
> > > > > > > > > > > distros.
> > > > > > > > > > 
> > > > > > > > > > As you know I don't agree to have them in the Samba tree
> > > > > > > > > > but this is a
> > > > > > > > > > different topic.
> > > > > > > > > 
> > > > > > > > > Including them in the Samba tree is different still from
> > > > > > > > > hosting them
> > > > > > > > > elsewhere, where other Samba developers can not easily
> > > > > > > > > contribute to
> > > > > > > > > them
> > > > > > > > > and using other technologies than we use elsewhere in Samba.
> > > > > > > > > 
> > > > > > > > > I can see the point in having separate git trees, but I'd
> > > > > > > > > like to see
> > > > > > > > > them
> > > > > > > > > hosted on git.samba.org, with reviews on samba-technical at .
> > > > > > > > 
> > > > > > > > As I said before I don't have a problem with that and would
> > > > > > > > like to host
> > > > > > > > them on git.samba.org. At the moment they are still work in
> > > > > > > > progress. I
> > > > > > > > still need to work on them without a blocking review and I
> > > > > > > > want more
> > > > > > > > tests for them.
> > > > > > > 
> > > > > > > It's fine to have a personal tree for your work in progress, but
> > > > > > > your
> > > > > > > repositories have all the looks of being the main project
> > > > > > > repositories.
> > > > > > > The wrapper libraries are already fairly mature, and we'd like
> > > > > > > to have
> > > > > > > external folks use them - those are good reasons for requiring
> > > > > > > peer review.
> > > > > > > 
> > > > > > > > > > > I think this approach would also have given you much
> > > > > > > > > > > more and
> > > > > > > > > > > earlier feed-back and contributions by samba-developers.
> > > > > > > > > > > And
> > > > > > > > > > > I don't buy the argument that externalizing makes it
> > > > > > > > > > > easier
> > > > > > > > > > > for others to contribute. I don't believe this.
> > > > > > > > > > 
> > > > > > > > > > Your late email shows the opposite, doesn't it?
> > > > > > > > > 
> > > > > > > > > I disagree. It show the development on the wrapper libraries
> > > > > > > > > is
> > > > > > > > > happening
> > > > > > > > > invisible to samba-technical, apart from the e-mail you sent
> > > > > > > > > to the
> > > > > > > > > list.
> > > > > > > > 
> > > > > > > > So you check each samba developers personal git tree on
> > > > > > > > git.samba.org
> > > > > > > > every
> > > > > > > > few days? I don't think so :)
> > > > > > > 
> > > > > > > They should not be a personal tree, but rather a tree that all
> > > > > > > Samba
> > > > > > > team members have access to. Including review mails to
> > > > > > > samba-technical@ and
> > > > > > > commit notifications to samba-cvs at .
> > > > > > 
> > > > > > The changes are not just small changes. uid_wrapper is more or
> > > > > > less is a major rewrite I've just finished last week after having
> > > > > > tests for the code.> > > > 
> > > > > That's not a reason not to have review. I don't see why there should
> > > > > be
> > > > > different standards here than for the rest of the Samba codebase.
> > > > 
> > > > Because originally the project Andreas built was not a Samba codebase
> > > > project ?
> > > > 
> > > > Andreas is offering that code 'back'.
> > > 
> > > This is all code that originally comes from the Samba codebase.  That's
> > > also not how the original e-mail frames it. It suggests removing this
> > > code from the samba source tree and relying on the external copies.
> > 
> > Yes to reply to you and Adam at the same time.
> > 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.
> 
> > Besides Andreas goal was also to make this code stand on its own, and
> > that's certainly easier if you develop it on its own.
> > 
> > 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]

Hey,

you found out what I'm *proposing*.
 
> 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? :)

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

Should we continue ...


	-- andreas


P.S.: I hope you find the sarcasm. You could continue and complain more and 
more and maybe frustrate me in the end. The other possibility would be to find 
a compromise.
 
-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org



More information about the samba-technical mailing list