Modular Boost Frequently Asked Questions

Conversion to Git and modular Boost

What is the role, if any, of Ryppl and CMake in the Boost modularization plan?

None. Modularization + the move to Git is a big enough change to be done separately and to stand on its own merits.

What role, if any, does the old Boost sandbox play in modular Boost?

None. The whole need for the sandbox as a part of the boost repository goes away. Proposed libraries that used to go in the sandbox now just go in their own public repositories. They are typically hosted on ​GitHub, but any public host will do. ExtractSandbox shows how to move a library from the old sandbox to GitHub. StartModDev shows how a repository for a proposed library would work.

General Questions

Is it possible to checkout only one library and its prerequisites?

Not automatically. Automatic dependency resolution is planned for the future, but not as a part of the conversion to Git and Modular Boost.

So how do I get a modularized Boost that I can actually use?

See these instructions.

How do I submit fixes to a Boost library owned by someone else?

Short answer: Submit a pull request against one of the repositories at github.com/boostorg.

Long answer: See ​GitHub's description of the process. ​Stackoverflow also covers the topic. This ​video shows how GitHub manages interactions between the submitter and the library owner.

Will we keep using trac for tickets?

There's no immediate plan to change anything about how our issue tracking works.

Library Maintainers

How do I get write access to my library at github.com/boostorg?

See Administrative Privileges for public library repositories.

Will there be a lockdown for individual libraries master branches during the release cycle?

No, as far as we know at this point.

Will there be support branches for particular releases?

Which branches get created depends on who owns the repository in question. Thus, If you are asking about Boost super-project releases, then that is up to the community and the release managers. If you are asking about individual library releases, that is up to the individual library maintainers.

What branches will be tested

Short answer: We don't know yet.

Long answer: We will start with something simple, and then work up to a continuous integration test scenarios. One of the key objectives of modularization, right from the start, has been to facilitate much more responsive testing.

Acknowledgements

Thanks to Andrey Semashev and Antony Polukhin for submitting many of these questions. Dave Abrahams provided many of the answers.

Beman Dawes is maintaining this page.