Am 23.04.2016 um 11:22 schrieb Sam Kellett:
i see a *lot* of rejected / unfinished libraries that use the boost name with the intentions of one day becoming a boost library. doesn't this affect the brand strength associated with the boost name?
i would have thought that it wouldn't be ok to name your library a boost library before it is officially accepted, but that doesn't seem to be the case? or is it the case but it isn't / can't be enforced?
I am one of those doing that with boost.process. For me as a user of boost, I don't see a problem with that. It is rather obvious which libraries are accepted and which are not, so there's no confusion. Since boost is a open-source library collection, I think it is rather clear, that proposed libraries are already named that. So I don't see a weakening of the boost name there; it's rather a strenghening of the proposed library. That is, I think there should be a boost.process library and I found the existing one and used it. If that would've been named differently, I might never have identified it as a boost candidate and might have gone with something else as a basis. So understanding, that there is an effort to make a boost library really helps in collaboration on those libraries. The boost name gives it publicity which helps to get more people involved. I think the only chance you have to get a library named diffently into boost, would only work if you have a complete library and then rename it into boost. BUT at the point when you would refactor it, it would likely already have users, for which you would break the code. I.e. the current boost.process 0.5 is already used. What could be done, is to require the libraries to be named boost.experimental.*name* (or develop or proposed). Then you could add a macro somewhere (maybe in boost/config), which just pulls everything from the corresponding namespace into the boost namespace. That way one could use it before it's approved and then later on, without renaming everything in the user-code.