- Boost - lists.boost.org

RFC: Community maintained libraries
by Beman Dawes 11 Dec '13

11 Dec '13

Boost libraries have always been maintained by an individual maintainer, or perhaps a small number of individuals. That works very well most of the time, and there is no need to change that approach for libraries that continue to have active maintainers. Where we have a problem is libraries that don't have active maintainers. Someone else has to step in from time-to-time to apply patches and perform other routine maintenance. That was easy to do for our svn repo because write permissions were global. GitHub gives us some additional tools; write permissions are given at the Team level, and a team can have permissions across multiple specific repositories. Strawman Proposal ------------------------- For Boost libraries where there is no library maintainer available, turn maintenance over to a "Community" team. Initially the team members would be volunteers who are already known as experienced maintainers or patch submitters. New volunteers for team membership would establish themselves by submitting patches and pull requests. At least to get things started, the release managers could OK requests for team membership. We might seed the list of libraries being community maintained by contacting some current maintainers who have not been active for years. If we can't even contact the maintainer, that's an indication the library is a candidate for community maintenance. Patch submitters who haven't gotten any action can request a library be added to community maintenance. At least to get things started, the release managers could OK requests for community maintenance. Comments? --Beman

14 40

Re: [boost] Branch names?
by Michael H. Cox 11 Dec '13

11 Dec '13

1 0

[variant] Warning: variadic templates in boost::variant
by Antony Polukhin 11 Dec '13

11 Dec '13

Development version of Boost.Variant library now uses C++11 variadic templates when possible. This leads to more compact binaries, more readable compiler error messages and faster compilation times. However this: * breaks ABI (now variant is declared as `template <typename T0, typename... TN> class variant`) * breaks user code that was explicitly using BOOST_VARIANT_LIMIT_TYPES Code that was using BOOST_VARIANT_ENUM_PARAMS and BOOST_VARIANT_ENUM_SHIFTED_PARAMS macro *must* work correctly without any modifications. To disable variadic templates usage in variant define BOOST_VARIANT_DO_NOT_USE_VARIADIC_TEMPLATES. When all the tests will pass successfully changes will be merged to master branch, so there is a high chance that variadic templates will be supported by Boost 1.56. In case of appearance of hard to fix variadic templates errors in Boost libraries dependent on Boost.Variant - report them in this letter and I'll help in resolving issues. -- Best regards, Antony Polukhin

6 21

[build] Default compiler options for a toolset
by Edward Diener 10 Dec '13

10 Dec '13

How are the default compiler options for a toolset chosen ? Is it in the .jam file for the compiler toolset and, if so, where is it specified ?

6 35

[Boost.Range] missing set insertion
by John M. Dlugosz 10 Dec '13

10 Dec '13

Something like this works when my destination is a vector: boost::range::push_back (destV, some_range); but there doesn't seem to be anything to use when the destination is a set. The obvious boost::range::insert (destS, some_range); complains that I don't have enough arguments for insert. Looking at the implementation in range/algorithm_ext/insert.hpp, it seems like an overloaded function without the "before" argument ought to work on any container that has a .insert(InputIt first, InputIt last ); member function, specifically including std::set and boost::container::flat_set. Is there some technical reason why this isn't supported? If not, I'd like to see what it takes to get it added. —John

2 1

[git] missing submodule references
by Peter A. Bigot 09 Dec '13

09 Dec '13

Updating my local git workspace I've run into this problem after git pull on master: llc[214]$ git submodule update fatal: reference is not a tree: 38039b3763f4457f913a006ad1621a476f9a721c fatal: reference is not a tree: 76b3d49e648da6dec2070d36a709129d114615ef fatal: reference is not a tree: 7fbe180e8dc1104195e652aa8a5a7cb1cd48e506 fatal: reference is not a tree: 0c0036aaf02b59b8d0dec631aa013627fb839dcd Unable to checkout '38039b3763f4457f913a006ad1621a476f9a721c' in submodule path 'libs/any' Unable to checkout '76b3d49e648da6dec2070d36a709129d114615ef' in submodule path 'libs/circular_buffer' Unable to checkout '7fbe180e8dc1104195e652aa8a5a7cb1cd48e506' in submodule path 'libs/conversion' Unable to checkout '0c0036aaf02b59b8d0dec631aa013627fb839dcd' in submodule path 'libs/variant' I've confirmed for libs/any that the referenced commit is present on github, but it isn't retrieved by "git fetch" in the submodule workspace, suggesting that it's no longer reachable from any head. I'm guessing this might be related to the "hidden ref" part of the "free to delete old branches" discussion, or maybe there just needs to be another submodule update for these modules. Peter

2 1

Re: [boost] [git] Near future.. How do we deal with git-native libraries?
by JOAQUIN M. LOPEZ MUÑOZ 09 Dec '13

09 Dec '13

-----Mensaje original----- De: Boost [mailto:boost-bounces@lists.boost.org] En nombre de Daniel James Enviado el: jueves, 05 de diciembre de 2013 0:57 Para: boost(a)lists.boost.org Asunto: Re: [boost] [git] Near future.. How do we deal with git-native libraries? On 4 December 2013 21:49, Joaquin M Lopez Munoz <joaquin(a)tid.es> wrote: > > Being both the author of Boost.MultiIndex and a total Git neophyte, > > could you please explain to me how this lack of ref commits affect me > > and whether I can fix it myself? > > It means that when someone checks out the master project they don't get > the latest versions of the submodules. I'm just updating the master project now. I understand this is https://github.com/boostorg/boost/commit/66b6e0b0dcff397010815624ce02c1d1c9… Excuse my ignorance but: does this mean syncing between the master project and submodules need be done manually? I was assuming that somehow updates to a submodule automatically propagate to checkouts of the master project. Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 5

[Thread] Looking for co-maintainers
by Vicente J. Botet Escriba 09 Dec '13

09 Dec '13

Hi, I have maintained Boost.Thread during 2 years, fixing a lot of issues and adding a lot of new features. Unfortunately due to personal reasons I would have less time to maintain the Boost.Thread library in the near future. To avoid that the list of issues increase instead of decrease I would like to know if there are candidates that want to try to fix some of the current or future issues and provide patches for them. Best, Vicente

4 8

Boost logo
by Adam Wulkiewicz 09 Dec '13

09 Dec '13

Hi, Where could I find currently used Boost logo in vector format? The one in http://svn.boost.org/svn/boost/website/workplace/logo/ is different. Regards, Adam

2 2

Git: maintaining super-project
by Vladimir Prus 09 Dec '13

09 Dec '13

I am not sure how maintenance of subproject references in the super-project will work. - For 'master' branch, I assume that as developers update 'master' branch in their libraries, they would submit pull requests, so that the super-project points at new commits. That shall work, except that pull requests like this are hard to examine. E.g: https://github.com/boostorg/boost/pull/4 If I did not specify direct links to commits, I don't know how anybody would decide whether new revision is OK or not. - For 'develop' branch, I certainly don't think that for every change to 'develop' branch of any library, there will be a pull request on superproject? Doing so would create a lot of administrative overhead, and not doing that means that checking out 'develop' branch of the superproject does not necessary pull heads of 'develop' branches of each library. Am I missing something? Thanks, Volodya -- Vladimir Prus CodeSourcery / Mentor Graphics http://www.mentor.com/embedded-software/

14 40