On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube <lwa...@gmail.com> wrote: > No. The open source project provides the ability for proprietary forks to > override the master branch default with the company default. Your approach > stalls the development process. A trivial change like this should not take > a week to commit.
I don't agree with this approach. Some defaults were set in NuttX and these defaults assure self-compatibility in various components that we should treat as sacred because people depend on it. Maintenance cost is nowadays higher than development cost unfortunately. We cannot change whatever we like whenever we like and blame users that their stuff stops working because of our upstream changes. There are commercial and industrial products running on NuttX and we should keep that in mind. Its not about how quickly we can change things, but how to add new features as an option/alternative without destroying existing working stuff. NuttX is like a foundation, it should be solid, so many things can be built on top of it. We should not change the foundations, not allow building different things at the same time in the same place which is impossible. We should offer a choice, not enforce changes. Linux may not be the best "reference" as it tends to change so often many people abandoned it as serious solution. Its a maintenance nightmare or single-use solution if you don't care what is inside. Unfortunately Linux is most popular so most software and drivers are written initially for Linux that propagates problems to all related OS (i.e. FreeBSD drm/kms video drivers), we try to avoid that in NuttX. Even Rust was not able to cope with Linux's internal changes pace, so they abandoned in-kernel maintenance and started writing from scratch RedoxOS in pure Rust, which seems to be long but reasonable path - people will have choice whether use Linux or switch to Redox, maybe in the long run Redox wins because of long term self-compatibility. Also in NuttX we have Rust port that does not impact all users, only interested folks can enable Rust if they want it, no one else is impacted, users have choice. I am sure the same approach can be applied to CRC stuff :-) > If Kconfig is in place it is now 100% your company's responsibility to > maintain your desired CRC defaults in your private proprietary board files. > Any change to the master will not affect you in this case. Keep > CONFIG_CRC16_XMODEM in your shipping product's config and ignore what > anchao is doing. An open source project's ability to innovate should not be > held up by your preferences. The last sentence is completely wrong. Its not about "preference" but impacting self-compatibility and long term maintenance. Messing the foundations and defaults is not innovation. Try building a home when the project constantly changes during the process, when you have 10 floors ready and suddenly you need to change pavements. Innovation is when you create new functionality and give users a choice without breaking existing working stuff. Back to the point, this discussion touched important area, lets focus on how to design a versatile CRC(16/32) API that would keep things operational and self-compatible, but create a new user selectable choices/alternatives. That seems the best constructive way forward :-) Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
