Re: [boost] Divergent Paths in Boost?

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-10-30 14:04:55

From: "Peter Dimov" <pdimov_at_[hidden]>
> 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.

I'm not certain that follows.  Individual libraries are
maintained by individuals.  There is a certain amount of
formality needed to ensure solid libraries become part of
releases, but that doesn't mean that the librarians need to do
things terribly formally -- at least not under the control of
Boost.  That is, the regression tests help to prove solidity
before a release, but how the libraries reach that state is left
to the librarians and doesn't have to be made formal.

OTOH, by maintaining an issues list for each library, accessible
from that library's main page at boost.org, would avoid the need
to search the list archives or duplicate discussions on problems
already visited.  Thus, an issues list may make things nicer for
the list and library users but I'm not sure that makes them
necessary.

> >> 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
                     ^^^^ form
> > 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.

You misunderstood me here.  I was saying that the maintainers
have their own To Do list of things that have been requested,
bugs to fix, etc.  An individual may apply great formality to
that process unbeknownst to Boost.

I wasn't trying to imply that there is such an issues list
managed by Boost, but I was acknowledging that one could be
started.

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

My impression has been that the talk of standardization and the
number of folks thinking in terms of eventual standardization of
code have increased.

> General purpose libraries will always receive more attention than
> domain-specific libraries. Submissions that are considered a possible

Of course.

> candidate for standardization (or that target an area in which the standard
> library is perceived to be lacking) are naturally judged by stdlib standards

A library can be made worthy of standardization in isolation, but
much more is learned by its exposure to others.  That's part of
what the reviews do now.  However, raising the bar too high makes
the cost of entry too high for many.

I'm advocating an initial review to ensure reasonable quality
such that the library can enter into a period of widespread use
and critique.  A subsequent review for final acceptance can be
demanding, but the initial review need not be so.  Concerns wrt
standardization can be softened for the initial review, for
example.

It is easiest if a library's design is standardization-friendly
from the start, of course.  To encourage designs and approaches
that could be standardized relatively easily, Boost can capture
best practices that all libraries should use whenever applicable.
There is a start in Boost Library Requirements and Guidelines,
but it doesn't focus on standardization issues except for
naming.  If there are codified issues a library submitter can use
to evaluate a new library before submission, less controversy
should arise during a review.  Of course, each time something new
wrt standardization comes up in a review, it can be added to the
best practices guide to benefit subsequent submissions.

> (pardon the pun). And finally, experimental libraries with no significant
> history and user base will naturally be viewed with more suspicion.

Isn't that just the type of library that should be accepted into
Boost?  That gives such libraries wide exposure so folks can gain
experience with the ideas and design of them.  Andrei garnered
great interest in Mojo without Boost's aid, but how many are
there in the C++ world with the same name recognition?  Boost
shouldn't accept just any library that comes along, but is it
necessary to be fully critical from the outset?

Maybe there should be two kinds of acceptance: experimental and
full.  (Pick better names if you like.)  The former means a
library is too new or controversial to gain the full faith and
confidence of Boost, but it looks promising, is well designed and
documented, and deserves exposure.  The latter means a library
has garnered wide use and has a proven design and implementation,
and is thus worthy of the full faith and confidence of Boost.

Experimental libraries can be listed on a separate web page which
can describe why libraries are so labeled in order to highlight
their different status and to warn away those not willing to
invest the time in a library that may change dramatically or die
altogether.  Obviously, an experimental library can change
dramatically, even without review, as it matures.  Once it
reaches sufficient maturity, the librarian may wish to submit it
for full review.

Neither the sandbox CVS nor Yahoo serve the "experimental"
purpose.  The Yahoo files area is a place where lots of code
languishes and there is no visibility on the web site for the
individual files/libraries in either the files area or the
sandbox CVS.  (Not that there should be for all that's found in
those places.)

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

That is a something that deserves attention, too.  Bug fixing,
refactoring of implementation details, most documentation
updates, etc. don't usually warrant reviews.  Interface changes,
at least those of any significance, and significant documentation
changes, OTOH, do warrant reviews.

The current process is to hammer the design and documentation
really hard up front and cross your fingers that the ideas are
indelibly imprinted on the submitter's mind so subsequent
redesigns, refactorings, and other updates won't deviate too far
from the goal.  However, with no verification, too many library
users will just "go with the flow" and accept what comes unless
they are "forced" into a review mindset or they just wake up one
day and realize things have gone awry.

> > 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. ;-)

Right, but there should be, and making the initial review
demanding doesn't mean subsequent revisions of a library will
continue to meet the same standard.

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

There are only two answers to the question: yes or no.
Individual libraries can still be judged on merit and subjective
quality, but that doesn't preclude answering the question.

If there are to be criteria for inclusion, they must be clearly
stated.  The current criteria given in Boost Library Requirements
and Guidelines leave a lot of room for misinterpretation (one
person's "quality programming practices" are not necessarily
another's, for example).

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

This was raised in the context of initial documentation in which
I stated that less stringent requirements should be imposed until
a library has been accepted.  That defers the close scrutiny
required to get "a reasonably tight definition" until the
interfaces have been hammered out and the implementation details
are solid so that specific promises can be made.  Doing that
before a review is wasted time, given the liklihood of changes
arising from the review.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;