The goal is not to automatically merge PR, but only to avoid that some PRs that don't reach the maximum number of reviews be allowed to be merged.
Typically, those who are most eager to impose new rules are not the same as those who are subject to them! BR, Alan On Wed, Feb 12, 2025 at 2:55 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote: > Again, I will vote against this. Not that it matters if a majority wants > to approve it. > > This is a bypass of all other rules we're trying to enforce. > > If such situation arise, there are two cases: > > - either the submitter still cares and will yell at people to get it > approved > > - either it will be dropped entirely. > > I dont want to see unsupervised auto commits. > > The conditions listed in this point (no breakage, execution of tests, > etc) HAVE TO be verified. > > Sebastien > > > On 12/02/2025 17:14, Tiago Medicci Serrano wrote: > > Hi! > > > > Thanks, Tomek ;) > > > > So, rewriting 19: > > > > *19.* A PR may be *eligible* to be merged under the concept of *Lazy > > consensus* with the following conditions: > > - It affects only a single chip or board (no > > kernel/libs/upper-half drivers etc); > > - It implements a new feature (or app) that doesn't introduce > any > > breaking changes or backward incompatibility; > > - It didn't get the minimum of 4 reviewers after two weeks > (to be > > discussed); > > - At least one independent reviewer reviewed it; > > - It adheres to all other conditions. > > The PR's author should: > > - After a week (to be discussed) without any reviewers, send > an > > e-mail to the mailing list asking for more people to review it; > > - Explain why the PR can't be split into smaller PRs (if > > applicable); > > - Ask for the independent reviewer to merge it after two weeks > > without any other reviewers; > > *The (required) independent reviewer* is responsible for > checking > > if the PR matches the *Lazy Consensus* conditions and merging it. > > > > Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO <to...@cedro.info> > > escreveu: > > > >> On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano > >> <tiago.medi...@gmail.com> wrote: > >>> Hi! > >>> Tomek, there is an important missing point about 19 (that is part of my > >>> proposal): > >>> > >>> 19. "Lazy consensus" is a situation where PR is auto-merged into the > >>>> upstream when not enough reviews are done in predefined time (i.e. > >>>> there are no minimum required positive reviews within two weeks time). > >>>> PR should initially be treated according the general rules (4 > >>>> independent reviewers); After a week without enough reviewers, a call > >>>> should be made on the > >>>> mailing list, explaining why the PR can't be split into smaller PRs; > >>>> After two weeks without any reviewers, we could merge if the above > >>>> conditions are met and we have at least one independent reviewer. This > >>>> may solve situation when we don't have enough people to review it (or > >>>> we are not interested in that). It prevents people from forking the > >>>> project just to be able to develop their stuff: *we* *really would not > >>>> like that*. The PR's author is still responsible for fixing some > >>>> bugs if found in the future. > >>> > >>> It's missing that a PR has to be *eligible *for requiring it and this > >>> includes some specific situations: > >>> - It should not affect more than one chip/board; > >>> - It applies to new features and apps that have no associated breaking > >>> changes and backward compatibility; > >>> - It requires at least one independent reviewer; > >>> - It requires an extensive testing section and proper documentation. > >>> > >>> These are *mandatory *conditions and we can vote it without it (this > was > >>> part of my considerations about *Lazy Consensus*). I would be against > >>> proposition 19 it if these requirements are missing. > >>> > >>> Can you please update proposition 19 and reconsider your vote based on > >> the > >>> requirements? > >> Hey there Tiago :-) > >> > >> This voting is to identify general rules that we all agree on already. > >> These points are supposed to be extract from our discussions. If I > >> missed some key points please add them here folks! For proposed rules > >> with doubts (0 or -1 votes) we should discuss more and update maybe > >> even finally reject them. > >> > >> On weekend we will gather and sum up the current vote results. Then > >> discussion will follow, where we may make clarifications, update > >> doubted rules, and vote again. The goal is to have common agreement on > >> the rules update. What we want to add and what form this is all up to > >> us. No one wants to enforce anything or create a monster that will > >> make our work harder, just a tool to help in review and code quality > >> improvement :-) > >> > >> If I provided incomplete information on proposition 19 then I am > >> sorry! Tiago you are the author, please send updated proposition 19 > >> text and note the old one is cancelled :-) > >> > >> Thanks!! :-) > >> > >> -- > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> >
