I'm +1 to going to CTR, removing the blocking rule for PRs, or both. Gary
On Thu, Oct 16, 2025, 13:43 Matt Sicker <[email protected]> wrote: > When we decided to try out RTC, I had accepted the idea with the caveat > that I’d only be alright with it if there is prompt PR review. Some of my > PRs since then have indeed been reviewed or approved within a day or two > (good), but some of them have sat for months without a single comment. > Seeing as how we’ve disabled committing to main and 2.x directly, I can’t > merge my own PR. I’m bringing this issue up once again to see if we can > resolve it. > > This makes it much harder to make simple code changes such as typo fixes, > documentation updates, small refactoring, and similar chore work simply too > complicated with unnecessary procedures. There are some other reasons why > this RTC flow doesn’t seem to match this PMC: > > * RTC tends to be used in highly active codebases with dozens or hundreds > of regular contributors. > * RTC works best when reviewers have sufficient time available every week > (estimate; thinking of the 72-hour style feedback window at ASF). > * RTC can technically be accomplished by having a coworker review the code > before making a PR (assuming both are on the same PMC), which gives undue > advantage to full-time contributors compared to part-time contributors. > * RTC seems to think that the ideal time to go over architectural design > and other planning details is at the time of proposing the code change; > ideally, non-trivial changes will document and discuss the proposed feature > via mail and issue tracking. > * RTC is a flow optimized for accepting contributions from third parties; > being invited to be a committer is supposed to trust that person with the > responsibility to know what they feel comfortable committing directly > versus what may benefit from peer review ahead of merging. > > If you wonder how it is or was possible to manage this project using CTR, > I point to the past when it was CTR. Before we enabled Dependabot, I used > to be able to follow the commits@ mailing list where I could > asynchronously review code as it was added to a main branch. Replying to > those emails would default to dev@, so the conversation went somewhere > meaningful. When we used CTR, I would oftentimes post to dev@ with > details about what I was planning to implement or change. We had also > configured CI to post an email about test failures in the main branch(es) > so that if they were broken, we were alerted to the need to fix it right > away (which was even more useful in the past when our build/test time was > much longer than it is now).
