I've had at least one PR that hit the bureaucratic wall, I gave up. Gary
On Sun, Jan 11, 2026 at 1:23 PM Robert Middleton <[email protected]> wrote: > > While I don't have hard numbers, it does feel that the number of > messages on the mailing list has gone down since RTC was implemented, > which implies to me that there's less discussion activity. I haven't > seen Matt or Ralph post much lately(although I think Ralph has been > busy). > > It seems like there are two competing forces at play here: on the one > hand, there's the fact that Log4j is a rather important part of the > Java ecosystem, and as such needs to be carefully maintained. On the > other hand, development seems to be mostly on the backs of Piotr and > Volkan at the moment, meaning that there is not a large group of > people who are actively maintaining the project. I don't believe that > anybody is being paid to work on it full-time either even though I > know Volkan and Piotr have both had some level of payment from the > Sovereign Tech Fund in order to work on Log4j2. To Matt's point, > because the process has become much more of a $WORK type of job now > it's harder for him to do anything with it. This could also > potentially push away new contributors. > > Personally I'm not convinced that /required/ reviews are a way of > improving code quality, or that they will help to catch the next > log4shell. It would be bad if enough current maintainers were pushed > away - reviews might help to prevent log4shell, but a lack of > maintainers could lead to the next XZ supply chain attack. Reviews > themselves are still important, but how they get done may need to be > less strict. > > -Robert Middleton > > On Tue, Jan 6, 2026 at 12:10 PM Matt Sicker <[email protected]> wrote: > > > > I have a follow-up message to this topic which I previously shared to the > > private@ list regarding personal context around this situation. > > > > I’ve been contributing to Log4j since 2013. This project has oftentimes > > been my creative outlet for where I can work on problems (or do some > > soothing refactoring such as porting tests from JUnit v4 to v5 or cleaning > > up areas of code identified by static analysis tools as concerning). This > > outlet has come in handy during the various points of my career where I > > would be stuck across multiple parallel lines of work waiting for PR > > reviews in order to make further progress (whether those be from co-workers > > or from upstream OSS projects I contributed patches to), and the only place > > I could work on things without having to wait multiple days or weeks to > > make progress on was Log4j. > > > > However, once we began requiring PR reviews, Log4j became an extension of > > $WORK rather than a passion project. As such, I pivoted to getting buy-in > > at $WORK to contribute to the project. By the time I had all the approvals > > and had started planning on some ideas of what to work on, Log4j had > > reached its current state where there are approximately two maintainers > > active on it, both of whom insist on PR reviews even from committers and > > PMC members. The long time contributors who were extremely active back in > > the early 2010’s have all faded from the project, most of them since about > > a year or two after Log4shell. I suspect that the overly formal code review > > process for committers has contributed to this decline; I know it has had a > > major impact on myself. In fact, over the past couple years, I’ve found > > entirely new hobbies to replace the time I used to spend working on Log4j > > on nights and weekends. > > > > > On Oct 16, 2025, at 12: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). > >
