I'm sorry to hear about these maintainer frustrations due to RTC. Our development workflows should enable maintainers to produce high-quality solutions, efficiently, not block them from doing so.
Let's try to make the problem more tangible. *There is only one review-pending PR* from Matt (#3884 <https://github.com/apache/logging-log4j2/pull/3884>), which is addressed by Piotr in an earlier post. There are 3 other PRs from him (#3953 <https://github.com/apache/logging-log4j2/pull/3953>, #3877 <https://github.com/apache/logging-log4j2/pull/3877>, #3869 <https://github.com/apache/logging-log4j2/pull/3869>), which were reviewed and awaiting his attention. Gary also has an open PR (#3855 <https://github.com/apache/logging-log4j2/pull/3855>), which was reviewed and awaiting his attention. The RTC workflow was introduced on 2025-04-10 – see the vote result <https://lists.apache.org/thread/rx2hgc5mwql06yzwz2j8wkp8z6nmdcqk>. Since then 97 non-Dependabot `logging-log4j2` PRs <https://github.com/apache/logging-log4j2/pulls?page=4&q=is%3Apr+is%3Aclosed+-author%3Aapp%2Fdependabot> were reviewed & processed, all by 2 maintainers. If we include every interaction – YesWeHack; Issues; Discussions; Dependabot, Log4j Kotlin, Log4j Samples, Logging Parent, Dependabot PRs; etc. – this number can easily exceed 300. I think that is a fantastic achievement given there are only 2 maintainers actively participating in reviews in their personal time. These figures are far from indicating an RTC problem. On the contrary, I observed several advantages of this workflow: - RTC allows one to raise concerns before a piece of code is in, and converge to a state where all participating parties' objective concerns are addressed. This results in very *high quality code* that would not be possible otherwise. - RTC reinforces our *public stance*. Log4j has been praised in many public circles (ASF, STF, Tidelift, OSE, GitHub, etc.) with having best of its class development practices. AFAICT, the most concerning issue is the number of people participating in maintenance duties: processing of PRs, Issues, Discussions, and vulnerability reports. I would be really happy to see other maintainers, besides Piotr and myself, giving a helping hand. On Thu, Oct 16, 2025 at 7:43 PM 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).
