[boost] Re: 1.32 release preparation

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 11:17:09

"Robert Ramey" <ramey_at_[hidden]> writes:

> Johannes Brunen wrote:
>
>>> And if there are a large
>>> number of new things left out by that approach then we should plan 
>>> another release sooner rather than waiting 4 months.
>>However, then you need new volunteers which have to spend the time for the
>>whole procedure again.
>
> The release procedure is too onerous.  This isn't the problem, it's
> a symptom of a more subtle problem. If the source of this difficulty
> can be found can corrected, then releases can occur more frequently.
> My personal view is that it's a symptom of a development process
> that couples otherwise independent/orthogonal efforts.  This is due
> to the fact that we're all working against a development tree that
> has experimental code in it.

Wait; we are??  What "experimental code" is on the main trunk?
That's not supposed to happen.  If it has, it should be rolled back.

> So minor issues ripple across all efforts.

Robert, I'm very happy to have your contributions in this discussion,
but it's hard to take your diagnosis of where the problem lies all
that seriously when you haven't even been through a single Boost
release with a library of your own!

>>I could think of a review process which accepts a library only after
>>the list of requested changes has been made.
>
>> I would prefere a review process which leads to final acceptance
>> only after a library is 'CVS' compatible i.e. does not yield to any
>> (known) regressions of the existing pool libraries and is equipted
>> with a working testing facility.
>
> The review process qualifies submissions for inclusion into boost.
> I don't think there are any libraries that have been accepted then
> suffered changes which made them unacceptable.  It's not fair to ask
> a submitter to require that that he totally "finish" the package
> before submission when it cannot be guaranteed that it will be
> accepted.  The review process isn't the problem, its working quite
> well.

I agree with that.

> It's just that there is more effort than first meets the eye between
> the time a library is deemed acceptable and the time it is ready for
> inclusion into boost.  The serialization library including code,
> headers, tests, html, jamfiles, *.bat, and shell scripts is has
> passed 25,0000 lines. This takes time and no changes in the review
> or release procedure can change that.  There is the review package
> which seems to work pretty well.  But I would be reluctant to check
> it in as it doesn't match the review acceptance conditions and I'm
> concerned about trying to maintain a package which I have now moved
> beyond.

Did the review manager really make acceptance conditional on support
for a particular compiler?  That would surprise me.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com