What if RTC only applied to the primary branch, release-2.x? We've had changes like this[1] which I discovered after the fact and wish we'd had a chance to discuss before it merged. Pushing changes prior to review is faster and easier for the committer, but ultimately creates an arduous process for reviewers. I've found it harder to have retroactive conversations about changes that have already merged.
-ck 1. https://lists.apache.org/thread/qn9b22fqv4yzg6jb114ovso40fnc1k0n On Wed, Jan 26, 2022, at 16:22, Gary Gregory wrote: > Not for me, this changes CTR to RTC, which is fine for work$, but too slow > for me here. When I find time for FOSS, I just want to go and do it, not > get bogged down in process. RTC is fine for a new medium to large feature, > but not for everything. Right now, I do something in release-2.x, then > cherry-pick to master, already a PITA because of the JPMS mess, now it has > to be a 4 step process instead of 2? Pass. > > Gary > > > On Wed, Jan 26, 2022, 15:25 Volkan Yazıcı <vol...@yazi.ci> wrote: > > > According to the OSSF Scorecards <https://github.com/ossf/scorecard>, we > > are missing two check marks (LOG4J2-3260 > > <https://issues.apache.org/jira/browse/LOG4J2-3260>) there: > > > > 1. Require code review (every change goes into a PR and requires at > > least one reviewer) > > 2. Require a CI status check > > > > Even though I admit with the convenience of freedom we have right now, I > > personally find it difficult to keep track of what is going in and out. > > This convention does not aim to obstruct the development progress, but > > rather improve the overall code quality and spread the know-how in a > > scalable way. Hence, I want to implement this feature on `release-2.x` and > > `master` branches. Thoughts? > > >
