Hello,

I am adding a negative opinion to this.

Lazy consensus is exactly what lead to absence of any testing and breakages.

If something is not looked at, it MUST NOT be integrated silently. It must be delayed until someone looks at it.

If no one acts, the mailing list can be called for actions with reasons why this pr must be integrated faster.


Maybe this rule could be added to the vote:

* No lazy consensus. If conditions for merging are not present because lack of contributors or reviewers, NEVER merge anything unsupervised. The correct solution is to delay, or call for action, with justification why the requester believes the change should be integrated faster.

Sebastien


On 11/02/2025 12:40, Tiago Medicci Serrano wrote:
Hi,

Two points that seem to be missing in the current *[VOTE] NuttX
Contributing Guidelines update 202502.* thread:

About commits...

We were discussing splitting some changes into different PRs, adding the
commit's message and description, etc but I couldn't find anything (even on
Docs) that mentions the rule of the commit being as small as it can be *without
breaking the build*.

About required reviewers...

I have a new proposal about "lazy consensus".

Currently, nothing being voted refers to it, but it may apply to one
specific situation: there are huge PRs that can't be broken on smaller
parts and affect only a single chip or board.

For instance, this <https://github.com/apache/nuttx/pull/12004> PR updated
the wireless drivers for ESP32-S3. As can be seen, only a single
independent reviewer reviewed it.

And it makes sense that no one was willing to review it:
  - It's big (and can't be split into smaller PRs because the changes depend
on each other);
  - It affects only a single chip (and it's expected that no one other than
the manufacturer or the developer that submitted it is willing to review
it);

*In this specific case, if the PR adheres to the other guidelines (proper
testing, logs, documentation etc), we could rely on a minimum of 1 (one)
independent reviewer and, after two weeks, merge it.*

Em seg., 10 de fev. de 2025 às 20:50, Tomek CEDRO <to...@cedro.info>
escreveu:

On Mon, Feb 10, 2025 at 8:42 PM Alin Jerpelea <jerpe...@gmail.com> wrote:
I thiink that we should have romething like a list and we should vote
+/-1
for each proposal then we summarize per change and we adopt the ones that
pass with +3
I fear that if we start 10+ votes we may miss to vote on some.
What do you think? what would be easyer?
Yeah, that should be quickest way best to manage, vote posted, if
anything is wrong just write, thanks :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Reply via email to