I'm with Matt. It should be left at the discretion of the developer whether a PR or straight commit is justified. I see no reason to throw sand in the gears.
Gary On Tue, Sep 17, 2024, 2:05 PM Matt Sicker <m...@musigma.org> wrote: > I’m -1 on switching to RTC. Same reason as always. Losing momentum from > waiting for an unnecessary code review will simply lead to much longer gaps > between time I spend on the project. > > > On Sep 17, 2024, at 03:30, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi all, > > > > Inspired by the way the Log4Net team works, I would like to propose a > > switch from our CTR policy to RTC: > > > > * every change to the main branches should go through a pull request, > > * pull requests can be merged if they have 1 positive review and no > > requested changes. To allow everyone to look at the PR, let's not > > merge them before at least 24 hours have passed. > > * if a pull request does not receive any review in 72 hours, as a last > > resort we merge them without a review. > > > > I would like to apply this policy to our most active repos: > > > > * l-log4j2 > > * l-log4j-kotlin > > * l-log4j-scala > > * l-log4j-transform > > * l-log4j-tools > > * l-log4net > > > > I am NOT proposing this change to the equally active l-log4cxx > > repository, since the Log4cxx team has an established workflow that > > does not use formal reviews. > > > > I would prefer to explicitly add a branch protection rule that > > requires reviews. If a PR is not reviewed within 72 hours, please ping > > the Slack channel so someone can review it. > > > > What do you think? > > > > Piotr > >
