TL:DR, was AI used to generate this? Gary
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. > > 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 >
