From: Beman Dawes (beman_at_[hidden])
Date: 2000-05-07 12:19:32
At 10:07 AM 5/7/00 +0100, Paul Baxter wrote:
>1) Since we are discussing submissions, I was wondering whether
>any criteria regarding the content or style of a submission that are
>to affect its submission.
>For instance, a specialist library with excellent coding style and
>but with a limited audience. Does this get rejected (or not
>because it is not generally relevant?
>Perhaps this would work itself out if few people come forward to
>I just think it may save potential applications some time if they
>front whether acceptance were likely (it takes a while to 'Boostify'
Let's assume by "specialist library" you mean a library useful only
within a fairly narrow problem domain, rather than useful across
multiple problem domains. (Although it could be clearer in the
library guidelines, boost has always discouraged libraries that are
"specialist" in the sense of operating system specific.)
One trouble with libraries which apply only to a narrow problem
domain is what I call the valarray effect. If there are only one or
two experts in the problem domain participating in boost, and those
experts wander off, then we are left maintaining a library most of us
neither understand nor care about.
>Perhaps a line or two in the library submission guidelines that
>should be generally applicable and this would be judged by brief
>on the mailing list before submission. (or alternatively a line
>everything is welcome given licensing and coding style constraints.)
Agreed. As we refine the procedures, I will update the boost library
guidelines page. (see below)
>2) Are libraries that ONLY propose an interface (and perhaps partial
Yes, IMO, but there can't be any restriction on writing
implementations based on that proposed interface. Also I wouldn't
want any restrictions on the proposal text itself that prevented it
from being copied such as when the boost site is mirrored.
> I'm thinking here of say the graph work where
>the license in the vault is for non-commercial use only, a
>preventing the code from being submitted formally. (at present, at
>Something like the graph discussions were extremely valuable and
>al. are to be congratulated, but what now becomes of this work?
>We could (I assume?) place the documentation with Boost and provide
>the Notre Dame content, or we could just leave it out of Boost all
>and place a link to the ggcl project.
>Perhaps it would be better to clarify up front what the license
>for a proposal would be to avoid taking up a lot of bandwidth on
>that ultimately couldn't be part of Boost.
>Personally I gained a tremendous amount from the discussions but can
>danger in future if we discuss/debug libraries that are never likely
>part of Boost. Intellectually of course I want to judge on a case by
>basis, but my judgement and those of others on this list may not
>the matter, what then?
>Note I'm happy to accept say, Beman as the 'arbiter of good sense'!
Thanks for the vote of confidence!
Let me try a quick first cut at added wording for the Boost Library
Guidelines page at http://www.boost.org/more/lib_guide.htm:
--- start wording ---
(Change page title to "Boost Library Requirements and Guidelines"
To avoid the frustration and wasted time of having your proposed
library rejected, make sure it meets these requirements:
* Has a license that allows unrestricted use, including commercial
use. Restricted licenses like the GPL and LGPL are not acceptable.
* Is generally useful and not restricted to a narrow problem domain.
* Is portable and not restricted to a particular compiler or
* Comes reasonably close to meeting the Guidelines below.
* You are willing to participate in discussion on the mailing list,
and make changes in your library accordingly.
There isn't any absolute requirement that you read the mailing list
long enough before a submission to get a sense of what boost is all
about. It has been noted, however, that submissions which being "I
just started to read this mailing list, but ..." seem to fail, often
(Guidelines unchanged from current text.)
--- end wording ---
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk