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
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
- 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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk