[boost] "peer reviewed" - Rights and responsibilities of maintainers

Subject: [boost] "peer reviewed" - Rights and responsibilities of maintainers
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-10-16 07:59:03

I'm having trouble with a maintainer of a boost library over a PR and am 
seeking for clarification.

Background (may be skipped):
A bug was introduced into the library which I noticed in one of "my" 
(company) projects leading to a reproducible crash. However the scenario 
is not that common (although others have the same problem) so it wasn't 
noticed earlier.
I analyzed the problem and created a minimum working example to 
reproduce this and then opened a PR with a fix. The maintainer did not 
comment on this for multiple months so given it IS complicated, I 
factored out additional PRs with tests I created to show the problem, so 
each PR is fairly small. In the result there were PRs with tests that 
failed on travis and the fix-PR which included the test-PRs and the fix 
and succeeded on travis (and all other CIs) and users reported success 
using this PR.
Still no response from the maintainer on any PR. He then added an own 
test claiming to be enough, while I (as the author of the original 
tests) knew it wasn't as e.g. it didn't fail. (so what's it worth then?)
Furthermore he added a commit changing unrelated stuff and ADDITIONALLY 
changing code I touched in the fix claiming that it would be the essence 
of my patch and fix the problems. Again I (as the author of the original 
patch) know that this is not true especially as the test-PRs still fail 
with his patch applied.

So my point/problem is: Is the maintainer allowed to simply do changes 
as he wishes without any review at all?

My expected procedure is:
- Someone creates a PR
- Maintainer (and optionally the community) reviews (and comments on) it
- It eventually gets merged or rejected with comments why
OR:
- Someones else (including the maintainer) creates a contra-PR fixing 
the same problem
- That author explains, how and why this fixes the same problem and why 
it is superior to the original PR
- This gets reviewed and either PR gets merged

Arguments were made, that this doesn't apply to accepted boost libraries 
as e.g. "it's [the maintainers] heads that got chopped off if something 
gets broken".
I would challenge this by the simple example at hand: This boost library 
IS broken and it crashes MY application (and others). But I see no heads 
rolling.

Furthermore: If the maintainer is allowed to patch and change as he 
wants without ANY review, how can Boost still be called "peer reviewed"?
My trust in Boost stems from the extensive review a library has to 
undergo before it is included in Boost. If afterwards no review is 
happening or reviews are actively avoided (as in the current example), 
then the older a Boost library gets, the less trust I would have in it 
as more and more unreviewed changes get included.

So again: What is the Boost course on reviews of existing libraries and 
the statement on the rights and responsibilities of maintainers?

Thanks,
Alexander Grund