Re: [poll] Use Commit Then Review (CTR)

On Mon, Oct 27, 2025, 09:35 Piotr P. Karwasz <[email protected]>
wrote:

> 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.
>

It means Commit Then Review, nothing more, nothing less.

Gary


> 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
>