third_party (ex-lib_3p) now ready for review.
abartlet at samba.org
Thu Jul 24 16:23:05 MDT 2014
On Thu, 2014-07-24 at 13:45 -0700, Jeremy Allison wrote:
> On Thu, Jul 24, 2014 at 08:39:15AM +0200, Stefan (metze) Metzmacher wrote:
> > Yes, I also prefer that. Having a 2nd git repository just makes sure
> > things get our of order.
> > Removing third-party/ from master gets a clear NACK from me.
> NACK on that NACK :-). I don't see any good
> technical reasons behind it. Especially as
> you propose a technical solution I agree
> with below :-).
> I think it's very important to remove third_party/
> from the tree. Removed code cannot be compiled in by
> error. Remember, the goal is to get Samba out
> of the third-party maintanence business (as
> we're just not doing it).
What I propose (having the tarball creation process strip these out)
also achieves the same goal.
> It isn't as though we're maintaining or updating
> that code. Having it available as a separate
> git repository that people can pull, or as a
> separate tarball that we fetch is enough.
> > We can have the release script create an additional
> > samba-A.B.C-third-party.tar.gz
> > I think we should also have an autobuild target using
> > --bundled-libraries=ALL
> > to make sure we force the use of the third-party libraries to make sure
> > they're usable.
> +1 on having an autobuild target that fetches
> and builds against the samba-A.B.C-third-party.tar.gz
> libraries to ensure we will always build against it, but
> I *really* want these out of our tree.
The way I see it, if autobuild is still using it, if the build farm is
still using it, then it isn't out of our tree - it might be in a
different git repository, but we are still involved in work to ensure
they build, specifically including Samba wscript files.
If we are still involved, then putting it in a distinct GIT repo only
creates work, and means we have to keep two different git repositories
What problem does moving these to a distinct git repo, that we still
have to maintain, solve?
The arguments you make seem to be the arguments for just totally
removing all these external libs, including the build rules and
everything. I see this as a distinct step, and one that still needs
some support for the build farm.
Finally, it seems we are putting far more effort into this than we ever
put into maintaining these libraries in the first place.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical