From: Jeff Garland (jeff_at_[hidden])
Date: 2004-06-27 16:06:35
On Sun, 27 Jun 2004 16:35:15 -0400, David Abrahams wrote
> "Jeff Garland" <jeff_at_[hidden]> writes:
> > I think there are 2 factors here. One is that we have been reviewing and
> > accepting a large number of libraries recently. So, many of these have been
> > accepted in the last couple months. The other thing that seems to be a
> > pattern is that libraries get accepted, then authors get a list of changes to
> > make. If they get busy it often takes months to get these done and then
> > finally they check into CVS. So a release tends to trigger the evaluation of
> > anything that is in that multi-month pipeline.
> Should we have accepted libraries checked in immediately (on a
> branch, maybe?), and then only added to the libs page when the
> authors deem them ready?
I think that's an excellent suggestion. The only time we might not want to do
that is if major file renaming is required -- that is a bit clunky with CVS.
But in general, I think most of the recent submissions have been developed
with boost guidelines up-front and so will just drop in.
As for the branch, that complicates the process a bit, but it has the
advantage that none of the new library files would appear in the release if
they aren't ready. I can imagine a couple of ways: 1) an alpha_lib branch
which covers all accepted, but not ready for prime-time libs or 2) one branch
per library. Nice thing about the second approach is that the branch
naturally obsoletes when the library is put on the trunk. But it does make it
harder to get all the 'alpha libs' checked out into a tree.
> If they're checked in on the trunk they can even get the benefit of
> regression testing while the authors whip them into shape.
Yes, this is a big advantage -- fixing platforms / compilers you don't have is
a slow process. If we use a branch, maybe we could get the regression folks to
include some alpha libraries when we aren't in the release shakedown phase.
But, honestly, I think we should go for it either way. I've been using some
of these alpha-libraries so it would make my life easier if they were in the
One last thought. If we make this the policy we could go ahead and put some
of these libraries in the tree before the 1.32 release. If they are
sufficiently stable (which I expect some like circular_buffer to be -- I'm
using it on 3 platforms now) they can go in the release. If they aren't we
can just leave them out.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk