2009/11/25 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:
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.