On Wed, Jul 4, 2018 at 3:48 PM Vinnie Falco via Boost wrote:

On Wed, Jul 4, 2018 at 10:14 AM, James E. King III via Boost wrote:

...

There are 12 PRs for updating the documentation (they are going to have merge conflicts)... who is managing that for this release cycle?

Typically the first person to bring up the subject on the mailing list becomes responsible for merging all the individual pull requests into one new pull request with the conflicts resolved.

:) :) :)

I don't have appropriate privileges to boostorg/website to merge anything, so it won't happen that way. So sad. - Jim

On 07/04/18 21:37, Vinnie Falco via Boost wrote:

On Wed, Jul 4, 2018 at 6:33 PM, James E. King III wrote:

...

I don't have appropriate privileges to boostorg/website to merge anything, so it won't happen that way. So sad. I was half-joking, but you don't need privileges to retrieve the branches locally, merge them into a new local branch, push the local branch to your remote fork (GitHub), and then submit the branch on the remote fork as a pull request. The miracle of Git!

While I appreciate the work to resolve conflicts by "merging" multiple PRs into one, it still feels odd to suggest to inject another task into the pipeline. Wouldn't it be simpler if someone *with* commit privileges would take on the task to do the merging at once ? (And yes, if no-one who already has such privileges is willing or has time to do this, I'd sign up for the job.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 07/04/18 18:42, Mateusz Loskot via Boost wrote:

On 4 July 2018 at 19:14, James E. King III via Boost wrote:

...

There are 12 PRs for updating the documentation (they are going to have merge conflicts)... who is managing that for this release cycle?

https://github.com/boostorg/website/pulls Handling conflicts and merging is a simple task. I think, it's more of an issue there are no reviews from reviewers with write access that would confirm acceptance of the PRs and can "count towards mergeability".

What "reviews" do we expect for release notes ? Don't we trust that library authors know best what release notes they want to submit ? (I'm of course assuming that submitted release notes are signed off by library authors / maintainers.)

The release notes are easy to approve really.

I wouldn't expect the review to be the issue, but merely the (mechanical) work of merging these PRs (including resolving conflicts, should they happen).

But, for instance this one, even if it seems to be based on extensive discussion on the list, still not clear if it is generally approved or not https://github.com/boostorg/website/pull/300 Should there be voting or at least PSC action taken?

That one isn't a release note, so I wouldn't even count in this context. (In my dream world, release notes would be collected per library, and the Boost website would only aggregate or syndicate them, so we wouldn't even have to have this discussion...) Stefan -- ...ich hab' noch einen Koffer in Berlin...