Boost logo

Boost :

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-01-29 02:55:21


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

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. Further,
this place is jointly updated by every boost developer.

What you propose breaks this useful thing, because:

- Only release managers "pull" into the unified thing
- Release managers only pull "releases", 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
- In practice, release managers will only pull a week or two before the release,
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.

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.

Thanks,

-- 
Vladimir Prus
Mentor Graphics
+7 (812) 677-68-40

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk