On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano <tiago.medi...@gmail.com> wrote: > Hi! > Thanks, Tomek, for summarizing it. > > I liked Nathan's proposal. Instead of simply increasing the number of > reviewers from 2 to 4, we can adopt tags (we can even evaluate if the bot > can do it automatically), and, based on such categories, we have new > requirements for the reviewers. > > Considering that, I'd drop the concept of *Lazy Consensus* (item 19) > because it covers my main concern: > > We *should* try to keep NuttX as stable and backwards compatible as > > feasible so that people can adopt NuttX and count on it to keep > > working for them in the long run. > > At the same time, > > > > *we need to be very careful not to make rules thatare too strict and > > inflexible, because then we would risk turning awaycontributors and we > > would end up with old cruft that is really brokenand generating a lot of > > complaints but can't be fixed because it wouldbreak the rules.* > > So we need to strike a good balance. > > We don't need a general rule and 4 reviewers for Documentation and new chip > bring-ups. We need 4 (or even more) reviewers for changes that break > production-ready interfaces.
Yeah I just wanted rules to be as simple as possible and generic that would avoid exceptions. If exceptions are required then maybe another simple rule should be added? The problem is we don't really know what change will break what and lots of PRs had testing section as short as "CI" nothing more :-P So is it okay to keep 2 reviewers for version bumps and documentation updates and 4 for the rest? Maybe its good to have two rules: 2 reviews for trivial updates like version bumps and documentation update (what else?) and 4 reviews for all other PRs? Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
