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

Subject: Re: [boost] RE process (prospective from a retired FreeBSDcommitter)...
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-01-28 16:24:38

Dave Abrahams wrote:
> At Thu, 27 Jan 2011 11:24:30 -0800,
> Sean Chittenden wrote:

>
> However, my vision for Boost is a bit different:
>
> * each library has its own Git repo

right - but if each library has it's own repo - they don't all have to use
the same system.

> * each library maintainer tests and produces versioned releases of
>  that library on his/her own timetable

yep

> * the latest release of a library is tagged "STABLE"

or merged into the "current release"

> * 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

yep.

> * When a library release fails integration testing, the release
>  manager has several options:
>
>  * Give the library maintainer a time window in which to produce a
>    new STABLE release that passes integration testing
>
>  * Use an earlier STABLE release of the library

This is the one!

>  * Withold the library from the next Boost release (drastic)

with the above option, (use earlier release), this should never be 
necessary.

>  * If the failures appear to be due to breakage in another library,
>    the release manager can apply these procedures to the culprit
> library

This would almost never occur if each library were testes against
all the other libraries makred "STABLE" rather than all the other
libraries on the trunk as we do now.

> One idea behind this process is that it allows individual libraries to
> "officially release" fixes and updates without forcing Boost's release
> managers to coordinate a Boost-wide point release.

Halleluhah

> having a contrib/ directory is an interesting idea for Boost.  That'd
> be very different from the sandbox.  But who's responsible for
> maintaining that code?

Ahhh - see my "boost candidate proposal" at bootcon 2010

>> At present it seems like boost-*.tar.bz2 is on track to including
>> boost/kitchen/sink.hpp and boost/bath/water.hpp and that's something
>> that is a bit concerning to me on the long-term scale.

> That seems like a semi-random fear that I don't see being addressed by
> a contrib/ directory.

eventually the whole issue will disappear when I can go to website
and check off all the libraries I'm interested in and have the "package"
made to order and download it all in one operation. Or better yet
update my local system just like Cygwin does now.

The only difference between "official and/or certified" boost libraries
will be the "official certification" which boost and only boost will be
able to confer.  Issues of critique, valueation, assessment, maintainence,
etc., etc. would be at the library level in the hands of the library
developer/maintainer.

Unmaintained/obsolete libraries will die a natural death as demand
atrophies while users migrate to better replacments.

Robert Ramey