To me, this is simple: - Let's go back to CTR - Sometimes a PR is appropriate
Forcing PRs for everything is just process over people, and Apache is "community over code". Gary On Wed, Jan 14, 2026 at 1:28 PM Tim Perry <[email protected]> wrote: > > Is the problem RTC? Or has better become the enemy of good enough in the > reviews? I know I'm walking a fine line, but sometimes the best way to > handle issues discovered in a code review is to open a separate ticket for > that work. For me, the request to change the handling of paths as strings > that was mentioned earlier falls into that category.... Sure, the person > trying to change the code could clean up issues in the surrounding code, > but must they? Seems like a high hurdle. > > > On Wed, Jan 14, 2026 at 9:41 AM Matt Sicker <[email protected]> wrote: > > > RTC is an abject failure at work, too. The same culture of “all the > > existing code is sacrosanct but we’ll make sure to nit pick future PRs” > > leads to a drop in code quality, proliferation of technical debt, and > > pushes people to start new projects entirely to replace the legacy system > > nobody wants to approve changes on anymore. > > > > The way it looks now, every subcomponent of this PMC has less than three > > active maintainers. That’s essentially an Attic project. > > > > > On Jan 12, 2026, at 2:51 AM, Volkan Yazıcı <[email protected]> wrote: > > > > > > Hey Robert, > > > > > > I think you've touched an important point below, and allow me to address: > > > > > > On Sun, Jan 11, 2026 at 7: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. > > >> > > > > > > Unless it is necessary, I personally don't carry any development-related > > > discussion to the mailing list anymore, and one can see this has > > > already been like this before 2024 ― recall that RTC was introduced on > > > 2025-04-10. That is, even when Piotr and I were full-time funded on Log4j > > > in 2024, we were only bringing necessary discussion to the mailing list. > > > Because, IMO, I don't see anybody helping besides us two. Christian and > > > Piotr at some point thought we were overwhelming other non-paid > > > maintainers, and this is the reason behind the friction between two > > groups, > > > let's introduce some sort of newsletter for our STF-funded development > > > efforts. Guess what happened? Other maintainers did not even react, and > > > Piotr and Christian rightfully stopped with the newsletter after a couple > > > of attempts. In short, yes, the mailing list traffic has decreased, but > > > this is not correlated with RTC. I think the right metric is triaged > > issues > > > and pushed commits, and these are stable, see my earlier response > > > <https://lists.apache.org/thread/wl1y76q7bhfl1sv9sh2g964bc57llytm> for > > > exact figures. > > > > > > AFAICT, the bottom line is, people who are actively contributing have no > > > problem with RTC; on the contrary, they support it wholeheartedly. On the > > > other hand, there is this other group of maintainers, whom contribute > > > seldom, have PRs pending for their attention to reviews, (almost) never > > > help with external PRs/Issues, they just want to push two lines of code > > for > > > their weekend projects, and return back to their $dayjobs. > > > > > > I am also not able to understand the "$WORK type of job" argument. You do > > > RTC at work for a reason, right? Doesn't that reason apply to Log4j? > > Log4j > > > is probably more important than any piece of software we deliver in our > > > $dayjobs. Doesn't it deserve to be developed with software development > > best > > > practices? > > > > > > I'm tired of hearing "bureaucratic wall" blah blah. Do you want to help > > > with the Log4j development? Great! There are dozens of tasks waiting for > > > your attention in here <https://github.com/apache/logging-log4j2/issues> > > > and here <https://github.com/apache/logging-log4j2/pull>. > > > >
