The Wrapper Project

[Simo]

On Fri, 2013-11-29 at 19:51 +0100, Stefan (metze) Metzmacher wrote:
> Hi David,
> 
> >> On Fri, 2013-11-29 at 14:09 +1300, Andrew Bartlett wrote:
> > ...
> >>> The way I see it is this:  Either the wrapper project is complete, and
> >>> so won't need updates in-tree, or we will need to manage updating the
> >>> build farm, user and developer instances.  Those updates will need to
> >>> strictly (presumably by pkg-config tests strictly checking version
> >>> numbers) match new revisions at exactly the same point where the
> >>> matching change is made in Samba.  
> >>
> >> This is easy to do, all these projects are using git, so we can simply
> >> have a file with the git commit you 'standardize on' until the next
> >> wrapper fix. In the buildfarm you pull those git trees, then checkout to
> >> the 'tested' commit hash (probably a version tag anyway) and always
> >> build that specific version of the wrappers, until you need a newer
> >> version due to a fix.
> > 
> > What you're describing here is pretty much exactly what git submodules
> > offers. You have a "link" in the tree which refers to an external repo
> > at a specific revision (the 'tested' commit hash).
> > 
> >>> I'm particularly nervous about this in a 'git bisect' scenario. 
> >>
> >> If you *really* care about bisect of samba then you really do not want
> >> to have changing libraries in the tree, because then during the bisect
> >> you *will* have too many moving parts. Not only the samba code you want
> >> to bisect changes, but also the wrapper libraries and many other things.
> >>
> >> Actually if you really cared about bisect you should ask for splitting
> >> more stuff out into separate trees, even tests would have to move out,
> >> so you always use the same tests while bisecting ...
> >>
> >>>> Last heimdal update: July 2011 (Heimdal last release was done 2012-01-11)
> >>>> Quick copy: 68 files changed, 6750 insertions(+), 3142 deletions(-)
> >>>>
> >>>> Last zlib update: before 2008 (moved to lib/ in 2008)
> >>>> Last iniparser update: before 2010 (moved to lib/ in 2010)
> >>>> Last popt update: before 2010 (moved to lib/ in 2010)
> >>>
> >>> I'm not sure what you point is here. 
> >>
> >> The point is that we are not good at maintaining external code once you
> >> suck it in the tree.
> >>
> >> Instead of embedding the whole code, we should just have a file with a
> >> list of upstream trees (or auto-syncing copies of those trees on
> >> git.samba.org) and then just put a commit hash in the build system. At
> >> least this integrating fixes is only a matter of changing a hash in a
> >> file, and people are not tempted to do one-off fixes in our forked
> >> version and never push it upstream.
> > 
> > I don't quite understand why you oppose using git submodules, as I see
> > it you're proposing exactly the same workflow. E.g:
> > 
> > ddiss at f163:~/isms> git clone git://git.samba.org/samba.git samba
> > ...
> > ddiss at f163:~/isms> cd samba
> > ddiss at f163:~/isms/samba (master)> git submodule add git://git.samba.org/nss_wrapper.git lib/nss_wrapper_sm
> > ...
> > ddiss at f163:~/isms/samba (master)> cd lib/nss_wrapper_sm
> > ddiss at f163:~/isms/samba/lib/nss_wrapper_sm (master)> git checkout fac1cd1f96a0f2d6d899946850847f177cfc3160
> > ...
> > ddiss at f163:~/isms/samba (master)> git commit -a -m "add nss_wrapper submodule link"
> > ...
> > ddiss at f163:~/isms/samba (master)> git show
> > commit 081fba8465b8807b3e824606267ebdcc186ba171
> > Author: David Disseldorp <ddiss at suse.de>
> > Date:   Fri Nov 29 19:20:46 2013 +0100
> > 
> >     add nss_wrapper submodule link
> > 
> > diff --git a/.gitmodules b/.gitmodules
> > new file mode 100644
> > index 0000000..18fcc20
> > --- /dev/null
> > +++ b/.gitmodules
> > @@ -0,0 +1,3 @@
> > +[submodule "lib/nss_wrapper_sm"]
> > +       path = lib/nss_wrapper_sm
> > +       url = git://git.samba.org/nss_wrapper.git
> > diff --git a/lib/nss_wrapper_sm b/lib/nss_wrapper_sm
> > new file mode 160000
> > index 0000000..fac1cd1
> > --- /dev/null
> > +++ b/lib/nss_wrapper_sm
> > @@ -0,0 +1 @@
> > +Subproject commit fac1cd1f96a0f2d6d899946850847f177cfc3160
> 
> When you would push that and then I'd just do a
> 
> mkdir samba-work
> cd samba-work
> git init
> git remote add origin git://git.samba.org/samba.git
> git remote update
> then disconnect from the network. Would I be able to do
> 
> git checkout 081fba8465b8807b3e824606267ebdcc186ba171
> 
> without network access and have everthing I need?

Metze,
would it be too hard to instead use a shell alias or script that pulls
all the needed git trees if that doesn't work ?

I already use an alias I call git-get to pull from git in my day to day
work, I wouldn't find it particularly problematic if I had to modify it
to list and pull submodules too..

Simo.