Why are you so unwilling to change your opinion?

You are ready to break nuttx just for your comfort, in whatever way it may take to advance your own agenda. That is very political.

I dont like that.

We need a consensus, and a majority of this thread is against the change you want to make. So it should be cancelled.

Rememeber this thread is a vote. My vote is No. Close the pull request. Do another one that has chances to be consensually accepted. Let's vote again.


I will paste the quote that Greg posted in the thread about the modlib change:


Rules for voting are a little different for code changes.

The required Apache voting process is 
here:https://www.apache.org/foundation/voting.html

For code changes, that document says:  "Votes on code modifications follow consensus 
approval<https://www.apache.org/foundation/glossary.html#ConsensusApproval>. In this scenario, a 
negative vote constitutes a veto<https://www.apache.org/foundation/voting.html#Veto>, which the 
voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy 
consensus<https://www.apache.org/foundation/voting.html#LazyConsensus> declaration when the request 
for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy 
consensus) conditions, the proposal requires three +1 votes and no -1 votes in order to pass; if it fails 
to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or 
modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets 
around to removing it."
And "For code-modification votes, +1 votes are in favour of the proposal, but -1 
votes are vetos<https://www.apache.org/foundation/voting.html#Veto> and kill the 
proposal dead until all vetoers withdraw their -1 votes.
Unless the proposer declares that the vote is using lazy 
consensus<https://www.apache.org/foundation/voting.html#LazyConsensus>, three +1 
votes are required for a code-modification proposal to pass."



Sebastien


On 09/04/2025 10:20, chao an wrote:
I like your second option, so could we remove the implementation of both crc16/crc16part interfaces and rename to crc16xmodem/crc16xmodempart?

BRs,

Sebastien Lorquet <sebast...@lorquet.fr> 于2025年4月9日周三 16:00写道:

    Hello,

    once again, the number of usage is unimportant and irrelevant.

    The ONLY thing that matters is that when I call function POOP, it
    always does POOP. Not something else.

    Because users you are unaware of expect this function to do POOP
    and they may not be able to change their code.

    If you want different crc functions, use something else.


    A better example than the building: the zip format

    zip uses adler32 which is not even a proper crc and is largely
    suboptimal.

    zip developers NEVER changed this in decades, even if they know
    it's bad. Why? because otherwise, old zip files would become
    completely unusable.

    We have the same issue.

    The default crc is bad? OK, deal with it. Add better functions.
    Document everywhere that the default crc is deprecated and should
    not be used because more accurate functions are available.

    But dont change the damn thing.

    I am against changing the default implementation of the legacy
    function silently.

    I would be less mad if you REMOVED the old function rather than
    silently changing its behaviour. (that would still be bad, however)

    Sebastien


    On 09/04/2025 05:12, chao an wrote:
    I can empathize. But we just don't want to fill this regret again
    in the new building.
    The lack of standards is currently the biggest issue hindering
    the promotion of this proposal.
    Another interesting thing, I'd like to share another data from
    github:
    if we search for the lookup table of crc16 on GitHub, you'll find
    that CRC-16/IBM with a higher use rate:

    CRC-16/IBM: 3.1k
    
https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code
    
<https://github.com/search?q=%220x0000%2C+0xc0c1%2C+0xc181%2C+0x0140%2C+0xc301%2C+0x03c0%2C+0x0280%2C+0xc241%2C%22&type=code>

    image.png

    CRC-16/XMODEM: 304
    
https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code
    
<https://github.com/search?q=%220x0000%2C++0x1021%2C++0x2042%2C++0x3063%2C++0x4084%2C++0x50a5%2C++0x60c6%2C++0x70e7%2C%22&type=code>

    image.png

    BRs,

    Tomek CEDRO <to...@cedro.info> 于2025年4月9日周三 10:52写道:

        On Wed, Apr 9, 2025 at 3:45 AM chao an <magicd...@gmail.com>
        wrote:
        > > > > On Tue, Apr 8, 2025 at 7:17 PM Lwazi Dube
        <lwa...@gmail.com> wrote:
        > > > > 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.
        >
        >  So you think it's more important to maintain your current
        10 floors
        > building, and it's none of your business if a 100 floors
        skyscraper appears
        > in the future? so could you afford all the developer time
        spent on this
        > kind of problem?

        Anchao, what I meant was to finish 10 floor building as planned
        (development), let people live inside that building
        (maintenance), and
        move development resources to 100 floor building as planned,
        without
        changing plans in the middle of construction, not getting
        stuck on 10
        floor building construction because plans change all the time and
        never getting to that 100 floor building. Its good to have solid
        immutable tools that you can depend on. Imagine there are devices
        already deployed out there that may not be possible to
        update, yes
        maintenance (in terms of keeping them inter-operational) may
        be the
        priority in that case, because replacing all devices may wipe
        out the
        company and leave owner with ubearable financial debt.

        I know this CRC is an important and quite hard problem, and I
        hope
        there can be a win-win solution where users have choice when
        they need
        one, thank you for bringing this up to the attention.. to be
        honest I
        have no clue what is the best solution here if there is no
        standard to
        relay on :-)

-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Reply via email to