Re: I do not think this RTC workflow is appropriate for us

[Matt Sicker <ma...@musigma.org>]

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 <ma...@musigma.org> 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).

Re: I do not think this RTC workflow is appropriate for us

["Piotr P. Karwasz" <pi...@mailing.copernik.eu>]

Hi Matt,

On 6.01.2026 18:10, Matt Sicker wrote:
> 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.


Sorry for the delayed response. I encouraged you to share this
perspective on dev@logging, because I genuinely find it interesting and
valuable, but the last two weeks were exceptionally busy, and I didn’t
have the time to respond properly.

As you know, I started contributing to Log4j in January 2022. Like all
external contributors, I began with PRs and, for the most part, I’ve
continued working that way. At the time, I didn’t have peer review in my
day job, so the PR-based workflow felt constructive and even motivating.

Because Log4j evolved very rapidly in earlier years (largely using CTR,
as you described), there are areas where coherence is lacking: subtle
differences between components, patterns that drifted over time, and so
on. Addressing those issues was one of the things that initially drew me
in. For me, RTC helped ensure I wasn’t missing something important or
introducing yet another variation by accident.

Even when my PRs stayed open for weeks, I personally never ran out of
independent issues to work on and that pool is still far from empty. I
also don’t fully share the view that PRs necessarily interrupt creative
flow. Once a PR is opened, most of the creative work is done, and it’s
possible to move on to another task while someone else reviews it. When
feedback does come in, it can be useful to reassess earlier decisions:
enthusiasm and momentum are great, but they aren’t always the best
guides for long-term maintainability.

In this thread, both you and Gary are strongly advocating for the
ability to merge your own PRs.

- In principle, I could be persuaded, but I honestly struggle to see
  what the concrete gain would be in your case. Yes, it would allow you
  to land changes directly on `2.x` rather than a branch, and reduce the
  duration of interaction around a change. However, given your long
  history with the project (since 2013), I don’t see prolonged
  engagement as an unreasonable burden.

- On the other hand, I’m not comfortable with allowing PRs to be merged
  while reviewer comments remain unaddressed. As I’ve said before,
  “addressing” feedback doesn’t mean accepting it: it’s perfectly fine
  to explain why a suggestion doesn’t apply or isn’t appropriate. What
  matters to me is that the discussion is acknowledged and closed.

Where I think we may have a deeper issue is in defining what is and
isn’t appropriate to ask for during a review:

- Asking for tests is generally accepted.
- Asking to expand the scope of a PR for broader consistency, as in
Gary’s example, seems to be received much less positively. ;-)

Perhaps this is an area where clearer, shared expectations would help.
There are established review standards (for example, Google’s [1]) that
might be worth looking at as a reference point, even if we don’t adopt
them wholesale.

Piotr

[1] https://google.github.io/eng-practices/review/reviewer/standard.html

Re: I do not think this RTC workflow is appropriate for us

[Gary Gregory <ga...@gmail.com>]

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 <rm...@apache.org> 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 <ma...@musigma.org> 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 <ma...@musigma.org> 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).
> >

Re: I do not think this RTC workflow is appropriate for us

["Piotr P. Karwasz" <pi...@mailing.copernik.eu>]

Hi Tim,

On 14.01.2026 19:26, Tim Perry 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.


Regarding PR 3855 [1], I had several discussions with Gary about it (for
example, [2]). My final proposal was not to block the feature itself,
but to ask for a small generalization: adding the same `getPath` method
to `RandomAccessFileManager` and `MemoryMappedFileManager`, so that all
file appender implementations retain feature parity, not just the one
Gary happens to use most often.

Looking back, I think there were missteps on both sides in how this
played out:

- I initially misunderstood the context and assumed the feature was
  directly required by Gary’s employer, which led me to ask whether a
  broader change, more useful to the community, could be contributed
  instead.
- Gary, on the other hand, did not escalate the disagreement to this
  mailing list and instead disengaged from the discussion.

Ultimately, we’re a consensus-seeking (or at least majority-seeking)
community. Apache Logging Services has 47 committers whose opinions all
carry weight, and decisions aren’t made by any single reviewer. In this
case, the PR received reviews from Volkan and myself, but no others. I
don’t think it’s reasonable to blame us for the lack of other reviews.

Piotr

[1] https://github.com/apache/logging-log4j2/pull/3855
[2] https://lists.apache.org/thread/8xpg47q7wqvvhw9myqh6fzc8lmotgsz6

Re: I do not think this RTC workflow is appropriate for us

[Gary Gregory <ga...@gmail.com>]

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 <ti...@gmail.com> 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 <ma...@musigma.org> 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ı <vo...@yazi.ci> 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 <rm...@apache.org>
> > > 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>.
> >
> >

Re: I do not think this RTC workflow is appropriate for us

[Tim Perry <ti...@gmail.com>]

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 <ma...@musigma.org> 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ı <vo...@yazi.ci> 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 <rm...@apache.org>
> > 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>.
>
>

Re: I do not think this RTC workflow is appropriate for us

[Matt Sicker <ma...@musigma.org>]

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ı <vo...@yazi.ci> 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 <rm...@apache.org>
> 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>.

Re: I do not think this RTC workflow is appropriate for us

["Piotr P. Karwasz" <pi...@mailing.copernik.eu>]

Hi Matt,

On 20.01.2026 19:17, Matt Sicker wrote:
> The image wasn’t uploaded to the list, so I can’t see it.

You can see the data Volkan was referring to at the following link:

https://github.com/apache/logging-log4j2/graphs/contributors

Looking at that history, Ralph is the only contributor who has been
continuously active since the project’s early days without any extended
breaks. For Gary, Remko, Carter, and yourself, the bulk of contributions
largely tapered off around 2022. Volkan has been active from 2020 to the
present, and I started contributing in 2022 and remain active on a daily
(sometimes weekly) basis.

I’m not bringing this up to diminish anyone’s past contributions: those
were and remain hugely valuable. Rather, it raises an important question
about what we’re really discussing: is this primarily about the adoption
of RTC in May 2025, or about how we make it easier for long-time
contributors to return and make occasional changes after longer periods
of low activity?


> Anyways, I can see that this conversation is going nowhere. I’m 
> convinced that this PMC has become property of Volkan and Piotr.


I don’t think that characterization is accurate. The project’s
governance rules haven’t changed. We’re not preventing discussion or
proposals around alternative review models; we simply don’t agree with
the changes being proposed, and so we vote accordingly. That’s how
consensus (or majority) decision-making works.

At no point has a blocking majority been formed by two individuals:
decisions still rest with the PMC as a whole, just as they always have.

Piotr

Re: I do not think this RTC workflow is appropriate for us

[Matt Sicker <ma...@musigma.org>]

The image wasn’t uploaded to the list, so I can’t see it.

Anyways, I can see that this conversation is going nowhere. I’m convinced that this PMC has become property of Volkan and Piotr.

> On Jan 15, 2026, at 2:01 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> Matt, the following is your `apache/logging-log4j2` commit activity <https://github.com/apache/logging-log4j2/graphs/contributors> I copied from GitHub. 
> Given this graph, and the fact that RTC was introduced on 2025-04-10, are you telling me that your inactivity since late 2017 was due to RTC?
> 
> 
> On Wed, Jan 14, 2026 at 9:42 PM Matt Sicker <matt@musigma.org <ma...@musigma.org>> wrote:
>> I should also note the below quote:
>> 
>> > On Jan 12, 2026, at 2:51 AM, Volkan Yazıcı <volkan@yazi.ci <ma...@yazi.ci>> wrote:
>> > 
>> > 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.
>> 
>> Of course it would look like that. The ones who agree to the policy work with it, and those who disagree have stepped back. That begs the question.

Re: I do not think this RTC workflow is appropriate for us

[Volkan Yazıcı <vo...@yazi.ci>]

Matt, the following is your `apache/logging-log4j2` commit activity
<https://github.com/apache/logging-log4j2/graphs/contributors> I copied
from GitHub.
[image: image.png]Given this graph, and the fact that RTC was introduced
on 2025-04-10, are you telling me that your inactivity since late 2017 was
due to RTC?


On Wed, Jan 14, 2026 at 9:42 PM Matt Sicker <ma...@musigma.org> wrote:

> I should also note the below quote:
>
> > On Jan 12, 2026, at 2:51 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >
> > 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.
>
> Of course it would look like that. The ones who agree to the policy work
> with it, and those who disagree have stepped back. That begs the question.

Re: I do not think this RTC workflow is appropriate for us

[Matt Sicker <ma...@musigma.org>]

I should also note the below quote:

> On Jan 12, 2026, at 2:51 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> 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.

Of course it would look like that. The ones who agree to the policy work with it, and those who disagree have stepped back. That begs the question.

Re: I do not think this RTC workflow is appropriate for us

[Volkan Yazıcı <vo...@yazi.ci>]

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 <rm...@apache.org>
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>.

Re: I do not think this RTC workflow is appropriate for us

[Robert Middleton <rm...@apache.org>]

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 <ma...@musigma.org> 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 <ma...@musigma.org> 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).
>