The Wrapper Project

[Simo]

On Fri, 2013-11-29 at 19:31 +0100, David Disseldorp wrote:
> On Fri, 29 Nov 2013 12:15:08 -0500
> Simo <simo at samba.org> wrote:

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

Yeah I knew someone would nail me on this one.
I want to explain the general mechanism w/o using the word submodules,
as people seem to not like them and write them off as a matter of
principle.
I do not like submodules either but not because of the mechanism used,
mostly because I expect more from something that is integrated in git.

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

Maybe I shouldn't. I like the idea, but it seem so many are against the
actual implementation ...

Simo.