incubator-triplesoup-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <>
Subject Re: vendor/ing redland?
Date Wed, 21 Feb 2007 23:40:46 GMT
On 2/21/07, Leo Simons <> wrote:
> On Feb 19, 2007, at 11:50 PM, Garrett Rooney wrote:
> > On 2/19/07, Mads Toftum <> wrote:
> >> On Mon, Feb 19, 2007 at 11:31:12PM +0100, Leo Simons wrote:
> >> > How does this look?
> >> >
> >> Like a bad idea? imho pulling in a library like redland really
> >> should be
> >> avoided if you can. Unless you're planning to have a pile of
> >> patches to
> >> redaland that won't go back to the mainline, I don't really see a
> >> heed.
> >
> > +1, unless we're talking about a seriously large number of patches we
> > should just make our build system link to an external redland.  Third
> > party libraries should only be imported as a LAST resort.
> I've heard that many times, but I've never understood why. Maybe
> someone can explain it to me?
> (I know It was sort-of painful with CVS because of not having binary
> diffs or diffs on directories or rollback, but SVN doesn't have those
> problems.)
> To me, vendor branches are just a very convenient way to track (or
> partially track) downstream or upstream software very precisely (oh,
> and you get "working copy semantics" for the "vendor" stuff too,
> always nice when on a plane, and you're not dependent on the third
> party its version control system being up, and you can diff and merge
> across the vendor tree and your own easily, and and and <other stuff>).
> Since I think its likely we'll stay ahead of actual redland releases
> for a while (eg work with its trunk and have nice and fun cross-
> pollination back and forth) and use it directly from SVN, my idea is
> that "just doing it in SVN" is simply easiest.
> I can swap fancy hot-download build systems with the best of them,
> but I don't particularly enjoy using or maintaining them (someone has
> always *just* updated the build to require a new version of a package
> which you can't get because you're on the train, and you svn upped
> just before getting on the train so yo can't roll back to the version
> that works with the previous version so you can't really work test
> first and things break down).

I just guess I don't see what you're trying to solve here.

Vendor branches are generally used if you expect to be changing the
external software a lot.  You pull in the latest version of something
and make your local changes and then every so often you update the
vendor version and merge its changes with your own.  This is, lets be
fair, largely work that's overhead, and unless you've actually got a
substantial amount of local changes that you can't push upstream I
just don't see the point.

It gets even more nuts when you start talking about wanting to work
with redland's trunk.  That means you're just setting yourself up for
even more merges and imports since the trunk of a project is expected
to change often.

I mean heck, the author of redland was on this project's proposal,
wasn't he?  Is it really going to be so hard to get any needed changes
pushed upstream that they need a landing site here first?

I've been working with third party codebases in open source projects
for years, and for the record I can't recall a single time when we
would have actually benefited in any real way from using a vendor
branch.  The gains we might have gotten from being able to quickly
make local changes would have been totally eaten up by the overhead of
repeated imports and merges and the pain-in-the-ass nature of needing
to make sure that the changes you really do depend on are indeed
merged upstream into a released version of your dependency before you
release something that depends on it.

Note that I'm not saying vendor branches are always bad.  I think
they're a great thing for proprietary projects that for one reason or
another do indeed need to make local changes to the projects they
depend on and don't have the requirement of needing releases to work
with released versions of the dependencies or for open source projects
that depend on a third party project that they can't easily get
changes into.  I just think they're more trouble than they're worth
for the vast majority of open source projects, the ones that depend on
third party projects that they actually can get changes into, and I
think that includes this case.

And naturally, if in 2 or 3 or 6 months it turns out that it's a huge
pain in the ass to expect people to either keep triplesoup working
with released redland versions or to expect people to check out
redland's trunk and build it in order to build redland then start
talking about using a vendor branch to simplify life, but do it when
it's proven necessary, not just because you're trying to solve all the
world's problems, even those we don't currently know we have.


View raw message