While we've never formalized this, on Log4cxx we effectively do what I will call "informal RTC." Basically we always make a PR that stays open for at least 24 hours so that people all over the world can have a chance to review it. If there are no comments in the 24 hours(and the builds all pass) it can get merged. Smaller fixes(e.g. typos) can go through quickly, without waiting the full 24 hours. I find this works pretty well for us, although it's mostly Steven who is working on the code at this point.
-Robert Middleton On Thu, Oct 16, 2025 at 6:33 PM Gary Gregory <[email protected]> wrote: > 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). >
