Re: [boost] RE process (prospective from a retired FreeBSD committer)...

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-30 08:07:59

At Sat, 29 Jan 2011 10:55:21 +0300,
Vladimir Prus wrote:
> 
> Dave Abrahams wrote:
> 
> > However, my vision for Boost is a bit different:
> > 
> > * each library has its own Git repo
> > 
> > * each library maintainer tests and produces versioned releases of
> > that library on his/her own timetable
> > 
> > * the latest release of a library is tagged "STABLE"
> > 
> > * When assembling a new Boost release, the release manager marks the
> > "STABLE" revision from each library and begins boost-wide
> > integration/interoperability testing on those revisions
> 
> I am rather sceptical about this approach. The goodness of what we have
> now is that there's a single trunk that holds code that is:
> 
> - supposedly not worse in test results in all other code,
> - is the newest one satisfying the above constraint

First of all, I don't think there's general agreement that trunk
should hold code "supposedly not worse in test results."  That's one
reason our trunk test results are not all that useful.  Some people
like to use trunk for "TDD," which apparently means checking in tests
that are known to be broken and fixing them incrementally.

Secondly, I don't see having "a single trunk" with these properties as
bringing with it any particular "goodness."  If you're looking for a
fix you still need to know which code to look at.  So just go to that
library's GitHub repo.

> Therefore, if I wish to make sure my code works with new release of
> Boost, of if I wish to check if some bug is fixed, that is the place
> to go. 

But in reality, it doesn't tell you anything about the next release of
Boost, because things don't always get moved from trunk to release.
Trunk 

> Further, this place is jointly updated by every boost developer.

That's a problem right there, not an advantage.

> What you propose breaks this useful thing, because:
> 
> - Only release managers "pull" into the unified thing

Not really.  The individual library developers determined which
versions will be *automatically* pulled into the unified thing by
tagging their individual releases as STABLE.

> - Release managers only pull "releases", 

Which can be much more frequent than what we do at Boost.

> which, together with delays added by release managers, means that a
> fix to a component will be added to the unified thing after
> considerable delay

I don't see where the delay comes from.

> - In practice, release managers will only pull a week or two before
> - the release,

No, a collection of the latest STABLE versions will be continuously
and automatically tested.

> therefore the unified thing we have now will no longer exists, and
> two weeks before the release we'll get a frankenstein creature that
> might technically pass all tests (though I doubt that), but won't be
> tested by any users in real projects.

Welcome to the real world.  That's how every OS distribution and every
other collection of semi-independent modules works, and works well.
No sane user of a real project is going to slow down his development
by regularly testing against an unSTABLE Boost trunk, and that's
increasingly true as Boost grows.

> So, to reiterate, no matter what tools are proposed, I strongly
> thing that there should always be UNIFIED in-development tree of
> ENTIRE BOOST to which all library maintainers can add changes
> without coordination with release managers.

I would want to opt out of adding changes to such a tree because it
seems to me like a giant waste of everybody's time.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com