Hi Gary,
On 27.10.2025 12:25, Gary Gregory wrote:
> This is a poll to gauge the waters for CTR.
>
> There is way too much Byzantine bureaucracy in this project.
Before jumping into a poll, can you clarify what CTR means in this
context? Past CTR vs RTC discussions have usually mixed together
multiple questions, so I want to be sure we are talking about the same
thing.
>From my perspective:
- The real debate is not about the *order* of merge vs review. It is
about whether a review is required before merging, or whether a “merge
now, review maybe later” approach is acceptable.
- In Matt’s PR #3884 [1], the core question was:
“If a PR sits too long without review, is it acceptable to merge
unreviewed?”
- In your PR #3855 [2], the situation was different. Reviews happened
quickly, but there was disagreement. The question there was:
“If I disagree with review feedback, can I merge anyway?”
These are two entirely different situations. Labeling both as a CTR vs
RTC problem misses the point: the real issue is not the policy, it’s how
we handle disagreement and reach consensus.
## The actual problem: not CTR vs RTC, but stalled consensus
What seems to be failing lately is not the merge policy, but the way we
resolve differences. Too often we get stuck in slow, frustrating loops
that turn reviews into personal tension rather than progress. When that
happens, people burn out and step back.
I’ll use two examples, not to attack anyone, but to highlight patterns
we should improve.
Gary, I’m using PRs involving both of us simply because we have enough
shared context to speak openly.
## Example 1: PR #3855 (Log4j) – disagreement -> stalemate
What happened:
- A new API method was proposed.
- A request was made to expand the scope for consistency.
- Expectations were not aligned, and the discussion stalled.
- Months passed, frustration grew, and no progress was made.
What should have happened:
- Clarify scope and expectations early.
- Negotiate a minimal acceptable first step.
- Commit to explicit follow-up work.
- Merge iteratively instead of stalling.
## Example 2: PR apache/commons-io#801 – disagreement -> merge-then-fix
What happened:
- There was technical disagreement, but it was not clearly communicated
during the review.
- The PR was merged despite unresolved design concerns.
- Follow-up commits were pushed as “trivial” CTR cleanups.
- Those follow-ups broke the original design and a follow-up PR was
needed (#804 [4]).
What should have happened:
- Make disagreements explicit before merging instead of assuming they
can be fixed later.
- Avoid merge-first, clean-up-later approaches that introduce
instability.
- Keep PRs stable and complete to prevent regressions and follow-up
churn.
## Proposal
Instead of switching policies again (CTR <-> RTC), we should improve how
we build consensus. Some practical steps we could adopt:
- When there is disagreement: align on scope first before arguing
details.
- If a PR grows too large: split it into agreed steps with follow-up
tasks.
- Avoid both “merge-by-frustration” and “silent blocking”.
- Use time-boxed review cycles: if stuck after X days, escalate to a
dedicated thread or short sync rather than stalling.
If we improve these habits, the choice between CTR and RTC matters much
less.
Piotr
References:
[1] https://github.com/apache/logging-log4j2/pull/3884
[2] https://github.com/apache/logging-log4j2/pull/3855
[3] https://github.com/apache/commons-io/pull/801
[4] https://github.com/apache/commons-io/pull/804
