This "lazy consensus" seems hot topic, lets just gather the feedback votes for now to see how many +1 / 0 / -1 are out there, then we will discuss the details, everyone may have their own reasons and for sure we can express them freely here :-)
Thanks :-) Tomek On Wed, Feb 12, 2025 at 7:21 PM Tiago Medicci Serrano <tiago.medi...@gmail.com> wrote: > > Hi, > > Again, Sebastien, read it *carefully*. It seems you are not willing to do > it. > > It doesn't bypass anything: > > - either the submitter still cares and will yell at people to get it > > approved > > > * My proposal says explicitly about this:* > > 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; > > > *Continuing:* > > I dont want to see unsupervised auto commits. > > > > The conditions listed in this point (no breakage, execution of tests, > > etc) HAVE TO be verified. > > > Neither do I! That's why there is the following rule: > > *The (required) independent reviewer* is responsible for checking > > if the PR matches the *Lazy Consensus* conditions and merging it > > > > *THE INDEPENDENT REVIEWER *(not the PR's author) is responsible for > checking and merging it. It requires *AT LEAST* one independent reviewer. > > So, if we were not able to have 4 reviewers *and* already asked for help. > Then we can try to check if it's *eligible*. > > Em qua., 12 de fev. de 2025 às 15:10, Alan C. Assis <acas...@gmail.com> > escreveu: > > > 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 > > > >> > > > > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
