The Wrapper Project

[Jelmer Vernooij]

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]

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.

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

Cheers,

Jelmer
[1] https://lists.samba.org/archive/samba-technical/2013-July/093666.html