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
>
