Hi all! About the pending proposals, can we proceed to another vote round?
I think we should wrap up it subject and create the article in the docs as soon as possible... Are we waiting for something else? Best regards, Em ter., 18 de fev. de 2025 às 09:45, Tiago Medicci Serrano < tiago.medi...@gmail.com> escreveu: > 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 >> >
