Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-12-29 01:41:23

On 12/28/2010 9:56 PM, Dean Michael Berris wrote:
> On Tue, Dec 28, 2010 at 10:02 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> On 12/27/2010 11:42 PM, Dean Michael Berris wrote:
>>>
>>> About the review process, the problem with the time limit that I see
>>> is the amount of work required to throughly look at a library usually
>>> doesn't fit in one week. And then the really deeper looks require
>>> quite a bit of discussion to clarify points and make sure that the
>>> reviewer and the library author(s) get to respond to questions and/or
>>> gather feedback regarding the implementation. By making the review
>>> process more of a collaborative development process instead of an "I'm
>>> finished, is it good enough?" thing, you can involve more people and
>>> encourage community building around your library.
>>
>> I agree with you that the time limit for most reviews is too narrow. It
>> barely leaves time for someone to investigate a library and write a good
>> review. I believe any review should last a month or more. At the same time I
>> do not see why more than one review can not go on at any time. If each
>> review lasted a month minimum, perhaps as long as two months, but a number
>> of reviews were going on at the same time, then possible Boost libraries
>> would not languish in the queue so long.
>>
>
> +1
>
> Actually, I'd +2 if you said a review should be open until the library
> gets into the main distribution. And even after that, reviewing the
> quality of the library should be on-going and shouldn't stop at the
> point of inclusion into Boost. ;)

If a review, as it sometimes happens, determines that a library does not 
qualify for Boost but if some things were improved it might, I would 
agree with you that a review could be ongoing if the developer of the 
library is committed to maklng changes that would improve it. But I do 
not see the advantage of keeping reviews open until the library is 
accepted, especially with libraries deemed not of a high enough quality 
for Boost. OTOH nothing keeps a developer from making changes in his 
library and re-submitting it for inclusion into Boost again.

As far as determining the quality of a library on an ongoing basis, 
anybody can currently suggest changes and new features. But I do not 
believe the developer should have to meet those new specs. OTOH I see 
nothing wrong with someone forking the library on his own and producing 
a second, very similar implementation with features he may deem 
necessary added, updated, or changed, and submitting that to Boost. This 
has already been done in some cases, such as signals and signals2, so 
why should not someone feel that it can be done elsewhere with another 
library.