On 09/07/17 22:07, James E. King, III via Boost wrote:

Could someone point me to documentation on management of the master and develop branches for committers?

I'm not sure if there is any document for git; I've only found the outdated version from the svn days: https://svn.boost.org/trac10/wiki/DeveloperChecklist It mostly applies if you replace trunk -> develop and branches/release -> master. So your development typically happens in your branches or develop (for smaller changes). The develop branch gets tested, you can see the results here: http://www.boost.org/development/tests/develop/developer/summary.html When your changes are thoroughly tested in develop (i.e. the tests detected no regressions) you can then merge them to master. Master is also regularly tested: http://www.boost.org/development/tests/master/developer/summary.html Note that if your changes depend on changes in other libraries, you should generally check that those changes were merged to master before merging yours. If they are not merged for a long time you can ask the maintainers to merge them (usually through a PR on GitHub). Boost releases are made from the master branches of all projects. The master branch is frozen during the preparation of a release, which is usually announced on the ML. You should avoid merging develop to master during the freeze.

boostorg/uuid master ends at Jan 11. boostorg/develop has a bunch of stuff in it starting on August 3, 2017. Who is responsible for merging develop into master and when should that happen?

The library maintainer is responsible for the merges.

Some of the issues are already marked resolved with a milestone of 1.66.0 but they are not in master, only develop.

If they have passed testing, they can probably be merged to master.

Should pull requests on github go directly into master?

No, all pull requests (PRs) should only go to develop. As do all your own changes. Only after being tested in develop they can go into master.

I find it confusing to have both and would prefer if there was only one possible destination for pull requests on github. If there are two, someone has to keep one of them updated and that isn't very efficient.

The reason for having develop as the bleeding edge is to keep master as stable as possible and always ready to release. It is nearly impossible to release more than a hundred libraries in a Boost release if active development happens on master. Therefore always merge PRs to develop, never into master. Only merge develop into master, after testing is done.