On Wed, 9 Apr 2025 at 03:43, Sebastien Lorquet <sebast...@lorquet.fr> wrote:
> > > >> I Maintain, DO NOT CHANGE THE DEFAULT CRC ROUTINE. > >> > > 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. > > > > 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. > > > > > >> CRCs are relied upon for data structure integrity validation. > >> > >> If you change the default, new code will consider valid data record as > >> invalid and STUFF IN PRODUCTION WILL BREAK > >> > > No it won't. I just told you why above. > > > This is not a productive reply. Telling me to "f... off" with my own > proprietary fork is not how collaboration works. > > Sebastien Proprietary code is not how open source collaboration works. Plain and simple. I only care about code I can see and change. Stabilizing out-of-tree code is out of scope and none of my business unless I am under contract. This is not an attack on anyone. Just common sense. But that is not the point I was making. I was suggesting that we should try to set up code so that something like CONFIG_FOO_BAR=31 saved in the fork can preserve its meaning even if upstream later changes the value to 5.
