Re: [boost] Core libraries should separated from experimentallibraries

Subject: Re: [boost] Core libraries should separated from experimentallibraries
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2009-11-25 11:11:00

2009/11/25 Thomas Klimpel <Thomas.Klimpel_at_[hidden]>:
>
> Is this the only complaint you have with respect to this side, or will you come up with the next complaint after somebody spend some days work to solve this SSL issue?
>
> After all, this was a discussion about content, not about a specific technical problem that man be important or not, but seems to distract from the main points of the discussion at the moment. Could we just assume that it may be possible to solve this specific technical issue, if it is really important?
>

Sorry, you're right, that was overly curt of me.

I suppose my real issue is that so long as there's a "real" boost
website, anything on the trac wiki feels like an implementation
detail, and the SSL issue reinforces that view.  I do, like I expect
most others on the list, have an exception for it already.  But then,
where the page is hosted is again a technical issue, and not what
you're asking about.

As a user, I'm used to http://boost.org/libs/ having everything, and
anything that's not easily findable from there I doubt I'd see.  The
page does help a bit, but doesn't give me much confidence that most of
the libraries would be usable.  For instance, what's the difference
between "quite stable" and "stable"?

Looking at the Submission Process, perhaps the "Preliminary
Submission" could be made official in some way?  Allow a sort of straw
poll on usefulness of some sort (but not design or implementation) to
get library ABC into boost/proposed/ABC, and add them into the main
boost system, with *PROPOSED* warning tags where appropriate.  While
there, anyone interested could submit a review, with the formal review
-- to remove remove the preliminary tag -- starting once a sufficient
surplus of positive reviews were received.  That would give people a
concrete way to contribute to getting a proposed library into main
even without a manager or scheduled date.  The library would also have
been out in the wild for a release cycle, and that copy -- that
everyone has installed and had the opportunity to use -- would be the
one reviewed.  It would also reduce the pressure on the formal review
manager, as a "no" is less severe, since it's still out there for
those interested to use.  It feels like the results are often "yes,
but you have to address [2 pages of requested changes]" recently that
would be clearer as a "no, but we're interested" if not for the
negative connotations.

I also like the idea of a core set of some sort, granted through
interface and implementation stability and by other libraries.

That's enough musings for now, I guess.