Hi! 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?
IMHO, It's still too restrictive. I liked the concept of having these 4 major areas: * Under Development: 1 reviewer * Experimental: 1 reviewer (eventually 2 if breaking changes) * Production Stable: 4 reviewers (in case of breaking changes, still valid the rule for discussing in the mailing list) * Periphery: 1 reviewer Best regards, Em seg., 17 de fev. de 2025 às 19:15, Tomek CEDRO <to...@cedro.info> escreveu: > 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 >
