Re: [boost] Divergent Paths in Boost?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-28 07:01:21

Rob Stewart wrote:
> From: "Peter Dimov" <pdimov_at_[hidden]>
>> Rob Stewart wrote:
>>>
>>> One of the valuable services Boost offers is to codify
>>> state-of-the-art approaches and facilities for C++.  Imposing
>>> the rigidity required to be a "sandbox LWG" will severely hamper
>>> that benefit.
>>
>> In the case of the real LWG, the "rigidity" is there for a reason.
>> Once you get past a certain stage, it becomes necessary to establish
>> formalities in
>
> Of course.  I didn't suggest otherwise.
>
>> order to even be able to move forward. Boost will reach that stage,
>> if it hasn't already.
>
> I disagree.  Select libraries within boost have reached or will
> reach that stage.

What I meant by "Boost will reach..." was that in my opinion, "Boost the
organization / Boost the community" will soon reach the critical mass that
calls for a more formal mode of operation.

I don't see how to interpret your answer in this context, sorry for being
unclear.

>> For example, there is a well known way to make the LWG review a
>> question/issue and make a decision - the LWG issues list. Boost
>> doesn't have such a formal procedure. One posts to the list and
>> hopes for the best. There is no entry barrier, but at the same time
>> there is no guarantee that someone will pay attention. And there is
>> no paper trail apart from the list archives.
>
> Right.  Such an issues list could well be instituted here; indeed
> they are in some for or other by the library maintainers based
> upon list participation.

No, such a procedure is not currently available in any shape or form. There
is no established way to invest a significant amount of your time (by
writing a short paper, for example) in order to _ensure_ that your
suggestion will receive any attention.

>>> I agree that a "sandbox LWG" would be beneficial, and Boost seems
>>> to be *stretching* in that direction, but I don't think the two
>>> can coexist.  The expectations are widely separated and neither
>>> should be lost.
>>>
>>> Given that Boost has only recently migrated toward the more
>>> rigid, LWG-focused mindset,
>>
>> I'm not sure that this statement is true. What has made you think so?
>
> Every review of late seems harsher than the one before wrt
> documentation, for example.  More and more discussion centers
> around how the proposed idea will look when moved to namespace
> std.  (That's always been in the back of many folks' minds around
> Boost, but it is quite upfront now.)

The std-centric focus has always been quite upfront, actually. I agree that
the reviews seem progressively harsher, but I don't think that "stdism" is
the only reason.

General purpose libraries will always receive more attention than
domain-specific libraries. Submissions that are considered a possible
candidate for standardization (or that target an area in which the standard
library is perceived to be lacking) are naturally judged by stdlib standards
(pardon the pun). And finally, experimental libraries with no significant
history and user base will naturally be viewed with more suspicion.

Add to that that the Boost way is to accept once and then grant the author
almost free reign to modify the library without subsequent reviews, and that
Boost the library / the download has already grown to the point where we are
forced to put more emphasis on quality over quantity.

[...]

> Reviews of later versions should, rightly, be demanding, but that
> seems to apply to all reviews anymore.

Except that there are no reviews of later versions. ;-)

>> If a library meets the highest standards, how can it not be "LWG
>> ready"?
>
> Fine.  I overstated my case.  s/highest/high/
>
> There are many libraries that are *high* quality, usable, largely
> portable, and reasonably well documented that are not LWG ready.
> Should that preclude them from submission to Boost?

There is no single correct answer to that question.

> Besides, doesn't "LWG ready" imply formal language that is not desirable
> for "normal" documentation?

In my opinion, a reasonably tight definition doesn't necessarily imply
formal language, although formal language makes the task considerably easier
for non-native speakers, at least. In other words, informal descriptions are
acceptable as long as the informality isn't used to avoid doing the work.