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
