1: +1 2: +1 3: +1 4: +1 5: +1 6: +1 7: +1 8: +1 9: +1 10: +1 11: +1 12: +1 13: +1 14: +1 15: +1 16: +1 17: +1
Thanks :-) Lup On Tue, Feb 11, 2025 at 7:39 AM Tomek CEDRO <to...@cedro.info> wrote: > Hello world :-) > > As discussed extensively in various mailing list threads we have > gathered all additional ideas for Contributing Guidelines update that > should improve NuttX Code Quality and self-compatibility / long term > maintenance. > > Lets vote what we have. If anything is missing then lets talk about > this in "NuttX Code Quality Improvement 2025Q1" thread and add to vote > here the final form. > > Each proposal is given number, please vote +1, 0, or -1 in reply for > every number to vote for, neutral, or against proposed update. > Comments are welcome too :-) > > 1. In Contributing Guidelines we are adding additional section for > Reviewers in order to provide complementary set of rules that should > filter out breaking code as much as possible also on our side. > > 2. Each PR (including git commits) _must_ adhere to requirements > presented in Contributing Guidelines or will be auto-rejected until > fixed / updated. > > 3. Git commit messages are as important as PR descriptions. These > provide in-code descriptions of each change and are git interface > independent. > > 4. Proper description of change is mandatory. Description must contain > explanation on what proposed change do, why it is necessary, what if > fixes, and how things are changed / fixed / updated, what is the > impact (build / runtime / api / what area), how it was tested. Local > code build and real world hardware runtime test logs must be provided > where mandatory. Description can be single..several sentences long or > bullet points but enough for anyone to understand change goals and > details. Usually it will look similar for PR and git commit message. > > 5. Proper description in PR is mandatory, or change is auto-rejected > until fixed / updated. Build and real world hardware runtime logs are > mandatory. > > 6. Proper description in Git commit message is mandatory, or change is > rejected until fixed / updates. Build and runtime logs are optional > here if these are too long and already provided in PR. > > 7. Each git commit message must consist of topic, description, and > signature, which are mandatory, or change is auto-rejected until fixed > / updated. Topic consists of functional prefix, ":" mark, and short > self-explanatory context. Description is separated from topic with a > single blank line. Example already presented in Contributing > Guidelines. > > 8. Changes must come with with documentation update where applicable. > If change presents new functionality a documentation must be provided > in the same PR (not in future). If change requires documentation > update it must be contained in the same PR (not in future). Successful > documentation build log shortcut is welcome. > > 9. We implement zero trust approach to user provided testing. It is > the commit author duty to provide real world hardware build and > runtime logs that must prove change does not break stuff for others. > > 10. Breaking changes are not welcome. This is anything that alters > Build / Kernel / Architecture / API, alters both nuttx and nuttx-apps > repo at the same time, breaks build/runtime/api for single or many > boards/architectures/applications, breaks self-compatibility, breaks > build/runtime compatibility with existing release code (packages) both > for nuttx and nuttx-apps, etc. > > 11. We respect long term maintenance and self-compatibility is our > ultimate goal. Alternative solutions and non-invasive approaches are > preferred that offers user a choice and compatibility. Breaking > changes are avoided, and planned towards next major release. > > 12. Breaking changes _must_ be discussed prior introduction on the > dev@ mailing list. PR may be created with clear indication it is for > discussion and marked as draft not to be "accidentally merged". > > 13. Breaking changes are special case where build and > runtime test logs (i.e. apps/ostest) from more than one different > architecture is mandatory. QEmu tests does not count here as it passed > breaking change that did not work on a real hardware. > > 14. Number of minimum required code review votes should be increased > from 2 to 4. This will ensure cross-checks and filter out faulty > changes. > > 15. Counting review votes should come from independent organizations. > There may be more than one review from a single organization, but > these will count as one vote. > > 16. Single company commit, review, merge is not allowed. > > 17. Self committed code merge is not allowed. > > Thank you :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
