Crater and all, Let me further elaborate that one of the attractions here is the Apache value of community over code, and for me, commit-then-review, exemplifies that. Ironically, I know people here a lot less personally and professionally than I do people I work with; but, I trust you, I trust everyone on the PMC. We can make mistakes, we fix them, we can revert commits, and so on, and it is through all of these activities that we build a community, our community. For me, review-then-commit, says "I don't trust you". It feels like work. At that point, we might as well start our own company and provide paid support and development for Log4j forks or whatever else we want, then we can put in all the processes anyone wants.
Gary On Thu, Jan 27, 2022 at 9:02 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi Carter, > > I think we'll have to agree to disagree, especially if you want RTC just > to add a single getter method, as your example shows. At work we use RTC > for everything, no exceptions, and that's all good and works for our team, > _at work_. This is not what I want to do in my free time. > > Gary > > On Wed, Jan 26, 2022 at 8:01 PM Carter Kozak <cko...@ckozak.net> wrote: > >> 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? >> > > >> > >> >
