Personally, I find RTC much more appropriate for mature-ish projects where quality and awareness are a higher priority than fast innovation. I think the sub-topic here actually supports that notion.
Faster innovation and iterative development can happen in feature branches with appropriate merge criteria in place. In Knox and other projects that I am involved with, trivial changes don't need review but with proper review, checkstyle integrations, etc, a lot of unnecessary thrashing can be avoided. While I don't have a binding vote here, I'd encourage you (from the sidelines) to codify your style preferences in automated precommit checks and switch to an RTC model. These can actually be healthy growing pains. (If you choose to see them that way) :) --larry On Thu, Nov 17, 2022 at 3:45 PM Gary D. Gregory <ggreg...@apache.org> wrote: > There's your answer Cater, it was intentional, unreviewed, and unilateral. > > On 2022/11/15 21:22:29 Oleg Kalnichevski wrote: > > On Tue, 2022-11-15 at 15:41 -0500, Gary Gregory wrote: > > > This is a distraction from the problem I brought up in another > > > thread: Oleg > > > erases other people's commits at he wishes, CTR or RTC won't matter. > > > This > > > is not the Apache way. > > > > > > > You have a long history of making really bad changes to the project > > code based on nothing more than your personal wishes and preferences. > > Moreover, you repeatedly ignored multiple requests to have a discussion > > before making such changes at the very least, a basic decency toward > > your fellow project members. > > > > THIS is not the Apache way. > > > > Oleg > > > > > > > Gary > > > > > > On Tue, Nov 15, 2022, 15:37 Michael Osipov <micha...@apache.org> > > > wrote: > > > > > > > Am 2022-11-15 um 14:32 schrieb Oleg Kalnichevski: > > > > > We have an implicit commit-them-review policy ever since the > > > > > inception > > > > > of the project in the year of 2005. We all are free to commit > > > > > what we > > > > > deem appropriate but no commit can be considered safe until it > > > > > has been > > > > > voted upon and tagged with a release tag. > > > > > > > > > > If an objection has been raised about any commit in the > > > > > development > > > > > branch it can be reverted and should be resubmitted through a PR > > > > > and put > > > > > to a review. This basically applies to all committers and any > > > > > commit. > > > > > Any committer can ask for a commit to be reverted and the change- > > > > > set put > > > > > to a review. > > > > > > > > > > If any commiter no longer feels comfortable with this approach I > > > > > personally will have no problem switching to the pre-commit > > > > > review > > > > > policy whereby every change must go through a PR first. Naturally > > > > > that > > > > > would call for a format vote. > > > > > > > > You guys might want to read dev@maven.a.o. We had this discussion > > > > recently. Coincedence. > > > > > > > > After the Maven 3.7.0 fiasco we have moved from CTR to RTC which -- > > > > yes, > > > > it slows down the process -- *but* drastically improved the quality > > > > of > > > > the code/new changes /before/ they land and reverts are basically > > > > down > > > > to zero. Additionally, people tend to do better self reviews. I did > > > > a > > > > lot of self reviews on recently Doxia changes and noticed myself > > > > that my > > > > PRs were incomplete. I would never go back to CTR, personally. > > > > (except > > > > for typo fixes or alike) > > > > > > > > Of course, CTR means that you have qualified people who can review > > > > in a > > > > decent timeframe (needs to be defined). It is never wrong to have > > > > another pair of eyes on a solution. > > > > > > > > Michael > > > > > > > > > > > > ------------------------------------------------------------------- > > > > -- > > > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
