Changes that affect the build system should require three +1 binding
votes and no vetoes from PMC members
Other projects that I know of that have tried an approach like, seem to have a
lot of difficultly get those 3 +1 votes. This slows down development or worse
forms groups of people that just all +1 each other patches without doing a real
review. This project may be different and if it’s not working you can change it.
Sometimes it is good to slow down if there are modifications proposed to
critical parts of the system. A bad build system change can cause
serious problems for a lot of people around the world. A bad change in
the core OS can destroy the good reputation of the OS.
I see what your concern is (not break the build) but with any CTR (commit then
review system) any commit can be easily reverted and you have known working
points (releases) that users can use. How does a system like this help you
users of NuttX?
It is true that build errors are usually found quickly. Usually you
will hear about it in a day or so. But it is not good public relations
to break peoples builds; it is unprofessional. A good qualification
environment should build on several platforms first: Linux, Windows
(native, Cygwin, MSYS2), macOS, free/openBSD, and others (those are the
main paltforms). That would minimize the risk of those embarrassments.
Errors in the core OS are much, much more subtle. You make changes that
subtly damage scheduling, prioritization, interlocking, priority
inheritance, real-time performance and not catch problem for months.
That is because the effect is subtle; the OS just becomes a crappy OS
for a few release cycles. That is the big one that I worry most about
and and slow-down in the workflow for changes that risk those core OS
features would be well worth it.
Greg
