Sorry for not responding to this in a timely manner. What Gary is describing is precisely what happened to ScopedContext. I developed it to be relatively simple. After seemingly a dozen modifications to address PR concerns I finally gave up as I didn’t have the time and the component was becoming overly complex and bloated. Furthermore, it wouldn’t have even have ended up being part of the API which makes it worthless.
However, this has very little to do with CTR vs RTC. Gary could have applied his patch and then had it vetoed with the same ask. I think the real problem is that sometimes we are being asked to solve for world peace rather than just the one item being focused on. Ralph > On Oct 26, 2025, at 9:22 PM, Christian Grobmeier <[email protected]> wrote: > > Hello, > > On Wed, Oct 22, 2025, at 14:08, Gary Gregory wrote: >> On Wed, Oct 22, 2025 at 8:03 AM Piotr P. Karwasz >>>> A project with one maintainer using RTC would mean that they can >>>> only accept external contributions and are otherwise not allowed to >>>> merge their own code. >>> >>> The key point is *active* maintainer. Under RTC, we only need one active >>> maintainer, plus another committer who occasionally reviews internal PRs. >> >> This is an example of a self-fulfilling prophecy in action. >> >> I am currently not actively contributing because of the absurd request >> in a PR [1] to redo a significant amount of code when all I wanted to >> do was add a simple getter method. > > I looked at the pull request 3855. > > I am growing on the idea of RTC, but this PR gets way too much attention; it > should have been merged already. > > Gary effectively added a getter because it helped him; additionally, he > mentioned that using the path was a good idea anyway. > The response was "do it during work time". > I don't think so: we don't ask anyone to pay for changes, we don't force > committers to do changes during work time. We look at the project's benefits. > > Gary explained further, but even a bigger change was requested. > I know there was no evil intent, but I also see how frustrating this can be. > > It is not going to work this way, and while we need to keep RTC, we need to > open up. > We have started gatekeeping. > > Is a path better than a string? > Move forward, merge. > > RTC is good for security and robust software. > RTC can kill our engagement rate and make this the next single-person person. > Both important. > > I'd suggest the following for minor fixes like this: > > - If a PR of a committer is opened, check if it harms (format, security-wise, > or introduces bugs). Accept it as quickly as possible, even if you disagree > with the long-term goal. > - If unhappy with the PR, bring the topic up on the dev list again, ask for a > revert, improvement, or a discussion on the goal > > For larger patches, we agree that we will all work on a branch first, which > may require more extensive discussion. > > We are a small team, and we must NEVER have a single person who approves or > disapproves of code changes. By default, all code changes must be allowed, > except when they cause harm. > > If you agree, please merge Gary's changes to the dev branch and discuss them > further on the list if needed. > > Cheers, > Christian > > >> >> Gary >> [1] https://github.com/apache/logging-log4j2/pull/3855
