Thank you Nathan :-) I just noticed that we missed self review can be added to 17 :-P
I am allergic to bureaucracy myself. All this is to improve project quality not to make life harder. But also avoid obvious situations like self merging, sending untested changes, making breaking changes standard, and in general distinguishing lack of self-compatibility from fake innovation. NuttX is really unique in modern ICT world of enforced changes and we should nurture that quality over quantity approach. This is why there are no changes in requirements yet until everyone is happy and we sort things out :-) I checked that NuttX supports over 15 different architectures, 342 unique boards, and over 1600 different configurations!! 2024Q4 we had 1233 commits in nuttx repo and 228 commits in nuttx-apps repo :-) Some good things already noticed is the increase in reviewers activity and this was my main goal behind point 14 whatever final form it gets, PR and git messages improved already, and we are working on distributed test tools, so the situation seems quite motivational and constructive, big thank you everyone for that :-) Have a good day folks :-) Tomek On Sun, Feb 16, 2025 at 6:31 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > Okay so here goes the vote results :-) > > Thanks, Tomek, for doing all of this! > > I would like to add some more of my thoughts: > > Regarding these rules: > > 9. Zero trust approach to user testing > 10. Breaking changes not welcome. > 11. Respect for long term maintenance and self-compatibility > 12. Breaking changes handling process > 14. Minimum code reviews 2 -> 4 > > Raiden said something very relevant (in #11) that I would like to expand upon: > > > Not every interface in NuttX is equally mature. Until we > > establish which API is stable and which is not, this change is bad. > > Breaking a stable API should be avoided, breaking an unstable and > > under development API should be allowed. > > 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 that > are too strict and inflexible, because then we would risk turning away > contributors and we would end up with old cruft that is really broken > and generating a lot of complaints but can't be fixed because it would > break the rules. > > So we need to strike a good balance. > > How to strike a good balance? > > When deciding how easy or hard it should be to change some code, we > should consider: > * How new or mature the area of code is > * How well the area of code works (known buggy .. known good) > * How much will changes in this code affect other parts of the system > * How well the area conforms to established standards > > Then: > > Code in mainline that is relatively new, known buggy, and won't affect > too much the rest of the system should be allowed to change easily. > Not too much discussions, votes, and other ceremony needed here. Just > make the change with one reviewer (not from same org) and move on... > > Code in mainline that has existed for a long time, is mature, known to > be working well, and will break many parts of the system if changed, > should require careful consideration before changing. We shouldn't > outright forbid such a change; maybe it's a "breaking" change but > still needs to happen for important reasons. This is an area that > needs lots of input, so, there should be a good discussion in the > mailing lists, possibly including a [VOTE] to decide should we make > this change or not. > > We could come up with some kind of formal "status" for each area of the code: > * Under Development > * Experimental > * Production Stable > * Periphery > > I'll describe each: > > # Under Development: > > This status is for things that are substantially working but are still > considered incomplete. Examples might be a new CPU arch, a new board, > a new driver, etc. > > Why include it in NuttX mainline? Because this way, other people can > join the effort. Consider how Lup made NuttX boot on the PinePhone. > (Thanks, Lup!) Most features were not implemented, but putting it in > NuttX mainline means that people could play with it, experiment with > it, hack on it, and help develop it further. It helps to inspire new > contributors and that's a good thing. > > We shouldn't include totally broken things, but under development and > *working* to some extent is welcome. If it's a new CPU arch and board, > NuttX should at least boot to NSH prompt. It's okay if most other > drivers (display, sound, GPS, who knows what) don't work yet. > > Areas like this should be allowed to change easily without too much > worrying about stability or backwards compatibility because they are > not stable yet and people probably shouldn't try to build products > with them. If you do build a product with "Under Development" code, > you should understand the risks and be prepared to solve problems and > hack on it when things break. > > One reviewer (not from the same org) should be enough. > > # Experimental: > > This status is for things that are considered "finished" (not "Under > Development") but it hasn't received widespread testing yet. There > might be rough edges or occasional crash or who knows what. So it's > finished, but needs more testing in the wild before it can be > considered good enough for production use. > > People can consider to build products with this kind of code but > should be informed of the risks and be prepared to test heavily and > help solve problems. > > It should be relatively easy to submit bugfixes for this kind of code. > > 1 reviewer (not from the same org) should be enough. > > Breaking changes in this kind of code should have a discussion and > maybe 2 reviewers, because the code might already be used in > production somewhere. If someone is using it in production with good > results, perhaps it should be elevated to the next level: > > # Production Stable: > > This status is for things that are complete and working in production. > > This kind of code needs to remain as stable as possible. > > Bugfixes are always welcome, of course. I suggest 3 reviewers (not > from the same org) and a good description of what was the bug and how > is it fixed. > > Breaking changes are possible but need to be considered very > carefully. I suggest: Mailing list discussion. ASF requires 72 hours, > I suggest more like a week, to make certain that people have a chance > to study the matter and respond. Followed by a [VOTE]. For the actual > change, I suggest 3 reviewers (not from the same org). (And follow all > the other rules about git logs and etc). > > # Periphery: > > I couldn't think of a better word, but this is other things that are > part of the system, such as Documentation and whatnot. Often it is > hard for projects to find contributors for these areas, so code is > worked on and fixed, but documentation (and other things) often lag > behind. > > We want to encourage contributors here, so I suggest to make it easy, > with 1 reviewer (not from the same org), unless you're reorganizing > the manual, moving chapters around, and making big changes like that. > Then, maybe there should be more discussion. Use common sense to > decide... > > Anyway, those are my thoughts. To sum up, how easy or hard to make > "breaking changes" should depend on how mature/stable the code in > question already is, and how much it will affect other parts of the > system. Some areas are more isolated (e.g., some obscure driver), some > areas are shared by all code (e.g., sched), some areas are very new > (e.g., PinePhone), some are very mature and used in production. > > I'm glad we have turned what was previously a bad thing (disruptive > changes that made people upset--understandably!) to something positive > and creative for the community. I hope we can continue this way... > > Cheers, > Nathan -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
