"Robert Ramey" <ramey@rrsd.com> 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