Note it was the thumbs down emoji, not the thumbs up, that was interpreted as an insult.
Be kind, everyone <thumbs up>! > On 5 Feb 2026, at 13:34, Nathan Hartman <[email protected]> wrote: > > Hi everyone, > > This is a good point: emoji have different meanings in different cultures. > Also, perhaps language differences have caused things to be understood as > hostile unintentionally. It's possible that AI is being used to translate > back and forth between languages, and the meaning might be lost in > translation. Perhaps someone wrote "you made a mistake" in their native > language and the AI translated it to "you are stupid." Whenever we > communicate across the world we must keep in mind that language barriers > can lead to all kinds of misunderstandings. If something seems hostile, > perhaps it is better to assume that the meaning was unintentionally > distorted in the translation. > >> On Thu, Feb 5, 2026 at 7:17 AM Tiago Medicci Serrano < >> [email protected]> wrote: >> >> Hi Donny, >> >> Thank you for your words. We totally understand how disappointed you are. I >> hope this conversation can heal things in the end and everyone - I mean the >> NuttX community and Xiaomi - can continue working together to improve >> NuttX. >> >> One thing caught my attention from your last e-mail: >> >> Matteo Golin mentioned being called "stupid", but looking back at the >>> communication records, he frequently used the *"thumbs-down" emoji* in >>> multiple PRs. >>> *This emoji is considered extremely impolite and provocative in Chinese >>> culture, and repeated use is bound to make developers feel disrespected. >> * >> >> >> I really didn't know about it. I'm Brazilian, and the thumbs-up means >> something like "It's fine/Go ahead/Nice/Got it/Understood/Checked" for me. >> I've been using it like that with my colleagues from Europe, India, and >> even China (now I'm worried about how my Chinese colleagues received it). >> Thank you for sharing that it may not be well-received in China. This >> cultural difference may be something that makes our communication even >> harder, so please consider that people were using the thumbs-up emoji on >> NuttX meaning what they thought it would mean. On our side, we can avoid >> using it when engaging in a conversation with a Chinese colleague, knowing >> now that it may not sound as good as it appears. I may say that it wasn't >> supposed to be used in a provocative way at all. >> >> Best regards, >> Tiago. >> >> Em qui., 5 de fev. de 2026 às 03:12, 董九柱 <[email protected]> >> escreveu: >> >>>> @ Tomek CEDRO >>> >>> The hostility part here mentioned by Matteo seems true, and it was >>>> reported before during nanosecond timers implementation. Calling >>>> someone impolite and then calling his requests stupid this is higher >>>> level of impolite, this is hostility. When you call something "stupid" >>>> without understanding why someone asks the questions situation has no >>>> solution. This is a direct result of long time flood of low quality >>>> breaking changes. This situation happened for years. We tried to stop >>>> that and improve situation but you call that stupid, your choice. >>>> Community prefers quality over quantity and communication is very >>>> important here, so is understanding. >>> >>> >>> @Matteo Golin >>> >>> I understand that sometimes bugs are hard to reproduce, they might occur >>>> spuriously, or that changes don't necessary result in an output that >> can >>> be >>>> captured in logs. That is totally fine. What I ask is that the >>>> justification be provided in the testing section instead of logs. I >> have >>>> been called "stupid" for requesting test logs on changes that >> supposedly >>>> don't produce verifiable output in this PR that keeps getting cited: >>>> https://github.com/apache/nuttx/pull/18266. When I asked for testing, >> I >>>> wasn't told that the change couldn't produce logs, I was told that the >>> logs >>>> are "too old and lost". I assume this means there is a way to obtain >>> them, >>>> and that the change itself is quite old (which doubly means it should >> be >>>> tested against mainline). I asked for a re-test and was told with >>> hostility >>>> that I should have just read the code and realized a) the deadlock was >>>> fixed and wouldn't produce logs and b) that the power consumption >>>> improvement cited at 20-30% was obvious from the changes. The author >> also >>>> mentioned that testing was done in another patch, but provided no >> link. I >>>> am sure the solution is obvious to the developers of the patch, but I >> am >>>> not a mind reader. I was polite when I asked for logs and stated that a >>>> number of recent PRs were AI-generated, so I wanted to make sure that >> the >>>> changes actually resolved the problem. This is within the contributing >>>> guidelines, it was NOT an attempt to mindlessly block the PR. I don't >>>> appreciate being called stupid and my intelligence mocked for not >>>> "understanding" the changes when I am presented with less information >>> than >>>> the developer themselves has access to. Especially not after quite >>>> literally north of 15 PRs were submitted that week with purely >>> AI-generated >>>> descriptions containing false claims about testing that was never >>>> performed. >>> >>> >>> Regarding the dispute over "*bad attitude*", we must state objectively: >>> Xiaomi developers have never taken the initiative to provoke. >>> Matteo Golin mentioned being called "stupid", but looking back at the >>> communication records, he frequently used the *"thumbs-down" emoji* in >>> multiple PRs. >>> *This emoji is considered extremely impolite and provocative in Chinese >>> culture, and repeated use is bound to make developers feel disrespected. >> * >>> We have always been willing to provide detailed responses to technical >>> issues (such as rpmsg framework details and deadlock repair logic), >>> but if reviews only focus on "demanding logs" while ignoring the >> technical >>> rationality of the code itself (such as MISRA identity replacement and >>> backtrace evidence for deadlock fixes), >>> it is understandable that developers who prioritize technology feel >>> confused. >>> >>> On Wed, Feb 4, 2026 at 10:10 AM raiden00pl <[email protected]> wrote: >>>>> I think the root cause is completely different. The real problem here >>> is >>>>> Xiaomi's >>>>> attempt to add changes from its entire annual development cycle. Year >>> of >>>>> changes >>>>> from a large development team to an open source community with fewer >>> than >>>>> 10 active >>>>> members. The community is flooded with changes it can't process, and >>>> Xiaomi >>>>> is >>>>> blocked because they can't add further changes based on unmerged >>> changes. >>>>> (..) >>>>> This approach hasn't worked recently, and it's not working now. The >>>> Xiaomi >>>>> team >>>>> is growing much faster than the NuttX community. The number of >> changes >>>> from >>>>> Xiaomi >>>>> is growing, and it has now reached absurd proportions. >>>>> If these changes were added gradually, without waiting for the end of >>> the >>>>> year, >>>>> the problem would be much smaller. >>>>> >>> >>> >>> *Xiaomi's adoption of the "annual cycle centralized submission" model is >> a >>> proactive adjustment fully based on previous community feedback. * >>> Previously, when we attempted to synchronize small daily development >>> patches to the community, frequent feature rollbacks and unstable builds >>> occurred due to the limited CI/CT capabilities of the community. >>> To reduce disruptions to the community, we switched to the model of >>> "internal closed-loop verification first, then centralized upstream >>> submission" — *each patch* must undergo dozens of code reviews by >>> @xiaoxiang781216 before being >>> merged into the internal mainline. Subsequently, it also needs to pass >> over >>> 1,000 code tests (CT) and 10,000+ device tests (DT) to verify stability >>> before finally being submitted to the community. >>> *This "verify carefully before submission" approach is essentially >> intended >>> to reduce the review and maintenance burden on the community, rather than >>> "dumping" changes.* >>> If we had continued to submit dozens of small patches daily as before, >>> given the community's scale of fewer than 10 active members, the review >>> pressure would have been even greater; >>> the same "review efficiency" issue would arise if a large number of >>> individual developers submitted patches scatteredly. We understand Tomek >>> CEDRO's concerns about community maintenance, >>> but we also hope everyone can see the compromise Xiaomi has made for >>> "community stability" — *after all, "verify internally first and then >>> submit centrally" is far more responsible than "submit while rolling >>> back".* >>> >>>> @ Tomek CEDRO >>> >>> No, this is author responsibility to present results in clear coherent >>>> and easy to understand manner so it can be reviewed quickly. All >>>> open-source projects work that way. You have big company with big full >>>> time teams and work internally, the community is small and free time >>>> crowd, you cannot just throw scraps that are supposed to be accepted >>>> without questioning. You have the context, we do not. As other people >>>> mentioned before many times, these changes often broke things for >>>> everyone else, and breaking changes are still constantly purposefully >>>> ignored and hidden - this is the biggest problem for me and there >>>> seems to be no solution here because it happens by design. >>> >>> We understand that "submitters should write clear PR descriptions" is a >>> community consensus, but it is also important to note that NuttX is no >>> longer the lightweight >>> system it was in the early days. It now needs to cover multiple >>> architectures (such as xtensa and armv7-a) and meet product-level >>> functional/performance requirements >>> (such as sensor low power consumption and multi-core communication), with >>> strong correlations between some modules (such as rpmsg and uORB). >>> *If reviewers judge only based on "superficial descriptions" without >>> understanding the underlying logic of the modules, they may put forward >>> modification suggestions that * >>> *do not conform to technical reality — this not only wastes the >> submitter's >>> time but may also introduce new issues.* We are not requiring reviewers >> to >>> "learn all framework source codes by themselves", but hope that in the >>> review of key modules, there can be communication based on technical >>> details >>> (such as "whether this modification will affect multi-core >> synchronization" >>> or "whether it conforms to the sensor wake-up logic"). *After all, the >> core >>> value of the community lies in * >>> *"technical co-creation". If reviews become "procedural log demands >> without >>> looking at technical details", it will instead make geek developers lose >>> their enthusiasm for participation.* Regarding the dispute over >> "demanding >>> deadlock logs" in the #18266 PR: We have provided a complete deadlock >>> backtrace (the call stack of lock competition between >>> the user task and the rptun thread) in the initial PR, and the root cause >>> of the deadlock (conflict in lock holding order) has also been clearly >>> explained. The core of deadlock >>> repair is "adjusting the timing of lock release", and the key to >> verifying >>> such modifications lies in "whether the code logic is closed-loop", >> rather >>> than "running logs that reproduce the deadlock". >>> *The backtrace is already the core evidence of the deadlock scene, and >>> further demanding "real-time logs of deadlock occurrence" is essentially >> an >>> unreasonable technical requirement. * >>> In addition, the "wakeup/nonwakeup-related modifications" in this PR are >>> strongly related to the deadlock repair (both involving the sensor rpmsg >>> communication logic), >>> and placing them in the same PR is to ensure functional integrity and >> avoid >>> logical fragmentation caused by splitting. >>> In addition, most of the PRs mentioned in the list (such as #3381, >> #18223, >>> #18219, etc.) are MISRA compliance modifications — these modifications >> are >>> "code identity replacements" >>> (such as eliminating goto and merging return statements) and do not >> change >>> any functional logic. We have covered all core scenarios through ostest. >> If >>> we are still required to "provide separate test logs for each API", >>> it is not only unnecessary (logs cannot prove the "correctness of >> identity >>> replacement") but also takes up a lot of community communication energy. >>> What really needs attention is "whether the code replacement complies >>> with MISRA rules and whether it introduces syntax errors", rather than >>> repeatedly demanding logs — after all, correct logs do not mean the code >> is >>> problem-free, and the review of code logic is the key. >>> *Even if the logs are available, if no strict review is conducted, the >>> problems in the code will still persist. It is better to focus the effort >>> on the code review.* The Xiaomi team has always respected the open-source >>> spirit of the NuttX community and is grateful for the community's >>> recognition of Xiaomi's contributions in the past. >>> We understand that community maintainers have limited time and energy, >> and >>> we are willing to cooperate to improve PR descriptions and supplement >>> necessary technical explanations, >>> *but the premise is "mutual respect" — avoiding the use of provocative >>> emojis, focusing on the technical rationality of the code itself, rather >>> than excessively obsessing over formal log requirements.* >>> *Not all problems have logs, but if logs exist, it doesn't mean there are >>> no issues in the code.* >>> >>> *The first-generation CI system of the NuttX community was built by >>> Xiaomi's @liuguo09 ; the first-generation CT (code testing) system was >>> built by Xiaomi's @nietingting; * >>> *and the latest NTFC system was co-constructed by Xiaomi and raiden00pl.* >>> These are not "small fixes" but core infrastructure that supports the >>> entire community's code verification >>> and stability — without these foundations, even small daily patches would >>> be difficult to verify, let alone large-scale feature iterations. >>> >>> Xiaomi has never asked for "returns" for these contributions; we only >> hope >>> that the community can develop in a more stable and efficient direction. >>> But it is disappointing that some members who have been enjoying these >>> infrastructure dividends (such as relying on CI to verify builds, using >> CT >>> to check code specifications) are now >>> criticizing Xiaomi's submission model as "dumping" or "low-quality". We >>> want to ask: What practical contributions have you made to the >> community's >>> infrastructure, code testing, >>> or core module optimization? *Xiaomi has been taking action to solve >>> problems (such as adjusting submission models to fit community capacity, >>> building testing systems to reduce review pressure), * >>> *while some criticisms seem to only stay at the "verbal" level.* >>> >>> >>> Xiaomi's developers are not working for any individual in the community; >>> our time is also spent on ensuring code quality and community stability. >> We >>> hope that future reviews can focus >>> on "technical logic" rather than "formalistic demands" — this is the >>> respect for the contributors who spend time building infrastructure and >>> verifying code, and also the foundation for the >>> community to continue developing healthily. >>> >>> >>> Matteo Golin <[email protected]> 于2026年2月5日周四 05:27写道： >>> >>>> I feel at least partially responsible for the cause of this "rift", so >> I >>>> would like to respond and clarify a few things. Please bear with me. >>>> >>>> First, I am completely appreciative of the work that Xiaomi contributes >>> to >>>> NuttX. It isn't even a question that they are the largest "contributor" >>>> (really, many contributors) to NuttX and have provided a ton of useful >>>> features and bug fixes. In fact, uORB, probably my favourite feature of >>>> NuttX (as some of you might know) was I believe contributed by Xiaomi >>>> developers. It's no question that they have advanced the NuttX >> project. I >>>> am also incredibly happy to see NuttX used in a large commercial >> company >>>> like Xiaomi! I am proud to tell people NuttX is used in Xiaomi devices >>> when >>>> they ask me about the project. >>>> >>>> Obviously, as raiden mentioned, NuttX is Apache licensed. Xiaomi is >>>> completely within their rights to make modifications and never share >>> them, >>>> keep their internal testing methods private and use NuttX in commercial >>>> products for profit. That is great thing! I do not demand that Xiaomi >>> share >>>> their internal CI pipelines and test code and logic with us. That is >> not >>> my >>>> goal in requesting test logs on PRs. I also want to state that I am not >>>> targeting Xiaomi; I don't have some kind of vendetta against them at >>> all. I >>>> apply the same review process to every single PR I review. It just so >>>> happens that Xiaomi PRs account for the vast majority of PRs I review, >>>> because once again, they are the largest contributor. >>>> >>>> However, I cannot understand what their demanded resolution is here. >> The >>>> contributing guidelines, voted on in this mailing list, very clearly >> list >>>> the expectations for PRs. The PR template which is auto-populated has >>>> descriptions of exactly what each section should contain and even a >>> warning >>>> that test logs will be requested! This is a requirement for >> contributing >>> to >>>> NuttX. A primary reason for this is, as pointed out many times, our CI >> is >>>> unfortunately quite poor. Most of the tests constitute simple >> compilation >>>> passes of each configuration. There is one CI process I know of which >>> runs >>>> a CI test suite to verify some run-time regressions (this test suite I >>>> believe is thanks to Xiaomi contributions, again, thank you!). However, >>>> NuttX has so much complexity with so many toggle-able options that our >> CI >>>> does not cover all test cases. To avoid regressions, we voted to ask >>>> contributors to share some test output (syslogs, logs from GDB, >> pictures >>> of >>>> hardware doing something, whatever) as a demonstration that the >>> contributor >>>> has verified that their change works as expected. I believe this is a >>> fair >>>> request, at least until we can improve the CI so that we have full >>>> confidence in its results. Having a comprehensive CI could solve many >> of >>>> these issues, but unfortunately it might be some time until that's >>>> achieved. >>>> >>>> The reason I ask for test cases on PRs is to avoid time wasted. There >> are >>>> ~10 reviewers responsible for merging contributions. Reading and >>>> understanding code is a time investment. I generally do not invest more >>>> time than a "skim" of code changes on PRs that don't have a proper >>>> description or aren't tested, because for all I know the testing will >>>> reveal issues that requires a code change. That means I need to read >> the >>>> code again and again until tests pass. So, I reserve my detailed code >>>> reviews for those PRs which meet the contributing guidelines. If your >> PR >>>> does not follow the guidelines, it is not ready for review and it >> should >>> be >>>> marked as a draft or not yet submitted. Period. And again, I do this >> for >>>> *every >>>> single PR*, not just Xiaomi PRs. Even if the code is great, flawless, >>>> perfect, there is still a good chance it doesn't run on the NuttX >>> mainline >>>> because it is a moving target. We don't know what version Xiaomi is >>> testing >>>> internally, and we've seen cases where code that was thoroughly >>> internally >>>> tested has caused regressions in NuttX. It happens. The goal of >> providing >>>> testing information is to reduce how often this happens. It doesn't >>> matter >>>> if there is a commitment to fixing the regressions as they're reported >>>> (which is great), we should still be minimizing the regressions that >>>> happen. >>>> >>>> I understand that sometimes bugs are hard to reproduce, they might >> occur >>>> spuriously, or that changes don't necessary result in an output that >> can >>> be >>>> captured in logs. That is totally fine. What I ask is that the >>>> justification be provided in the testing section instead of logs. I >> have >>>> been called "stupid" for requesting test logs on changes that >> supposedly >>>> don't produce verifiable output in this PR that keeps getting cited: >>>> https://github.com/apache/nuttx/pull/18266. When I asked for testing, >> I >>>> wasn't told that the change couldn't produce logs, I was told that the >>> logs >>>> are "too old and lost". I assume this means there is a way to obtain >>> them, >>>> and that the change itself is quite old (which doubly means it should >> be >>>> tested against mainline). I asked for a re-test and was told with >>> hostility >>>> that I should have just read the code and realized a) the deadlock was >>>> fixed and wouldn't produce logs and b) that the power consumption >>>> improvement cited at 20-30% was obvious from the changes. The author >> also >>>> mentioned that testing was done in another patch, but provided no >> link. I >>>> am sure the solution is obvious to the developers of the patch, but I >> am >>>> not a mind reader. I was polite when I asked for logs and stated that a >>>> number of recent PRs were AI-generated, so I wanted to make sure that >> the >>>> changes actually resolved the problem. This is within the contributing >>>> guidelines, it was NOT an attempt to mindlessly block the PR. I don't >>>> appreciate being called stupid and my intelligence mocked for not >>>> "understanding" the changes when I am presented with less information >>> than >>>> the developer themselves has access to. Especially not after quite >>>> literally north of 15 PRs were submitted that week with purely >>> AI-generated >>>> descriptions containing false claims about testing that was never >>>> performed. >>>> >>>> There is an inherent bias towards Xiaomi in NuttX. **This is NOT a bad >>>> thing**, it's a result of the fact that most contributions come from >>>> Xiaomi. The problem is that CI resources are scarce and so testing >> needs >>> to >>>> be shown from all contributors. We don't need to increase this bias by >>>> reducing the bar for entry just for one group of people because they >>>> perform their own internal testing and/or do not wish to include >>>> descriptions that follow the community guidelines. This isn't fair to >>> other >>>> contributors held to the same standard and it also gives a specific >> group >>>> more influence over the project. I don't believe that Xiaomi is >> purposely >>>> seeking to "dominate" NuttX in some way, or that their contributions >> have >>>> some kind of negative intention. Again, I acknowledge that none of >> their >>>> contributions must be contributed upstream since this is not a >> copy-left >>>> license. However, intentions aside, the result **is** that the code >> being >>>> merged and CI resources are dominated by Xiaomi. Again, no way to stop >>> that >>>> without barring their contributions, **WHICH WOULD BE BAD**! But if we >>>> start accepting PRs that don't follow the community voted guidelines >> just >>>> to get back their contributions, or because we assume their internal >>>> testing is perfect, then the vast majority of the contributions to >> NuttX >>>> are going to be in violation of its own guidelines. >>>> >>>> Please, please, please see the perspective of the reviewers. There are >>> few >>>> of us with limited time and resources. There are many Xiaomi developers >>> on >>>> salary whose full time job is writing code that runs on NuttX, who have >>>> access to vast internal testing resources. The reviewer cannot be >>> expected >>>> to test your patches for you, as I've been suggested on many of these >>> PRs. >>>> The contributing guidelines are there to level the playing field and >> make >>>> it easier to review and merge your contributions. I maintain that it's >>>> incredible disrespectful to: >>>> >>>> - AI generate descriptions with false claims and not verify them before >>>> submission >>>> - Refuse outright to meet reviewers halfway and tell contributors to >>>> "ignore my unreasonable 'demands'" >>>> - Call reviewers stupid for requesting test logs on an under-documented >>>> change >>>> - React to change requests with hostility >>>> >>>> Again, to REITERATE, I AM APPRECIATIVE OF XIAOMI CONTRIBUTIONS TO >> NUTTX. >>> I >>>> have no desire for them to leave the project, even though there are >>>> certainly difficulties associated with having contributions from an >>>> organization with vastly more time and resources than the rest of >> NuttX. >>>> HOWEVER, I will continue to review PRs according to the contributing >>>> guidelines because they are the standards decided by the community. It >>>> would not be fair to give a preference to a specific group or >>> individual. I >>>> will continue to be critical of AI-generated PRs so long as they are >>> below >>>> the NuttX standards, and I will continue to call out disrespectful >>>> treatment of reviewers. I will not test contributor code on their >> behalf >>>> (except in cases where I own some target hardware and have been >> politely >>>> requested to do so) and I will not tolerate constant PRs that repeat >> the >>>> same AI-generated violations of the contributor guidelines even after >>>> multiple requests to verify output. Most of all, I will not tolerate >>> being >>>> called stupid. >>>> >>>> Matteo >>>> >>>> On Wed, Feb 4, 2026 at 1:22 PM raiden00pl <[email protected]> >> wrote: >>>> >>>>> Regarding the current CI process and logs, CI can save logs from NTFC >>> and >>>>> export >>>>> them as CI artifacts that can be downloaded from PR jobs. NTFC saves >>> the >>>>> full >>>>> console log, so we can automatically have a full log of ostest and >>> other >>>>> tests >>>>> for qemu and sim and this doesn't require any work from a >> contributor. >>>>> It actually worked that way, but now I see that the logs are deleted >>>> before >>>>> exporting artifacts. I must have messed it up in one of the recent >>> github >>>>> work >>>>> updates. >>>>> >>>>> śr., 4 lut 2026 o 18:40 Tomek CEDRO <[email protected]> napisał(a): >>>>> >>>>>> My response here as summary of various different threads below. >>>>>> >>>>>> On Wed, Feb 4, 2026 at 10:09 AM Guiding Li <[email protected]> >>> wrote: >>>>>>>> On Wed, Feb 4, 2026 at 6:09 AM Matteo Golin < >>>> [email protected]> >>>>>> wrote: >>>>>>>> Xiaomi floods the upstream with low quality PRs/AI generated >>>>>>>> PRs, we request changes to follow the contributing guidelines >> and >>>>>> Xiaomi >>>>>>>> contributors respond with hostility. It seems that they would >>>> prefer >>>>>> not to >>>>>>>> include testing or adequate descriptions and instead have >> company >>>>>>>> committers approve the patches because internal reviews were >>>>> performed. >>>>>>> >>>>>>> This statement is quite impolite, just like how you disliked the >>>>> "stupid >>>>>>> log requests". >>>>>>> We have been submitting code in full compliance with the >>> community’s >>>>>> rules. >>>>>> >>>>>> The hostility part here mentioned by Matteo seems true, and it was >>>>>> reported before during nanosecond timers implementation. Calling >>>>>> someone impolite and then calling his requests stupid this is >> higher >>>>>> level of impolite, this is hostility. When you call something >>> "stupid" >>>>>> without understanding why someone asks the questions situation has >> no >>>>>> solution. This is a direct result of long time flood of low quality >>>>>> breaking changes. This situation happened for years. We tried to >> stop >>>>>> that and improve situation but you call that stupid, your choice. >>>>>> Community prefers quality over quantity and communication is very >>>>>> important here, so is understanding. >>>>>> >>>>>> >>>>>> On Wed, Feb 4, 2026 at 10:09 AM Guiding Li <[email protected]> >>> wrote: >>>>>>> (..) If you intend to conduct a genuine review of this PR, you >> need >>>> to >>>>>> have >>>>>>> relevant background knowledge: >>>>>>> first, you must read and understand the rpmsg/rptun framework (at >>> the >>>>>> very >>>>>>> least, have read through it); >>>>>>> second, you need to know what sensor_rpmsg is and the purpose of >>> this >>>>>>> module; >>>>>>> finally, you have to understand the specific bug addressed in >> this >>> PR >>>>> and >>>>>>> how the current PR resolves it. >>>>>> >>>>>> No, this is author responsibility to present results in clear >>> coherent >>>>>> and easy to understand manner so it can be reviewed quickly. All >>>>>> open-source projects work that way. You have big company with big >>> full >>>>>> time teams and work internally, the community is small and free >> time >>>>>> crowd, you cannot just throw scraps that are supposed to be >> accepted >>>>>> without questioning. You have the context, we do not. As other >> people >>>>>> mentioned before many times, these changes often broke things for >>>>>> everyone else, and breaking changes are still constantly >> purposefully >>>>>> ignored and hidden - this is the biggest problem for me and there >>>>>> seems to be no solution here because it happens by design. >>>>>> >>>>>> >>>>>> On Wed, Feb 4, 2026 at 10:10 AM raiden00pl <[email protected]> >>>> wrote: >>>>>>> I think the root cause is completely different. The real problem >>> here >>>>> is >>>>>>> Xiaomi's >>>>>>> attempt to add changes from its entire annual development cycle. >>> Year >>>>> of >>>>>>> changes >>>>>>> from a large development team to an open source community with >>> fewer >>>>> than >>>>>>> 10 active >>>>>>> members. The community is flooded with changes it can't process, >>> and >>>>>> Xiaomi >>>>>>> is >>>>>>> blocked because they can't add further changes based on unmerged >>>>> changes. >>>>>>> (..) >>>>>>> This approach hasn't worked recently, and it's not working now. >> The >>>>>> Xiaomi >>>>>>> team >>>>>>> is growing much faster than the NuttX community. The number of >>>> changes >>>>>> from >>>>>>> Xiaomi >>>>>>> is growing, and it has now reached absurd proportions. >>>>>>> If these changes were added gradually, without waiting for the >> end >>> of >>>>> the >>>>>>> year, >>>>>>> the problem would be much smaller. >>>>>>> >>>>>>> Any speculations that Xiaomi is deliberately abandoning NuttX are >>> BS. >>>>>> Let me >>>>>>> remind you of the timeline of the current situation: >>>>>>> >>>>>>> 1. Xiaomi starts pushing changes, often without a proper PR >>>>> description, >>>>>>> 2. The community is unable to process the changes, >>>>>>> 3. Xiaomi limits itself to changes directly affecting NuttX >> (e.g., >>>>>>> abandoning >>>>>>> the new init system), >>>>>>> 4. Xiaomi start to use AI to generate PR descriptions, >>>>>>> 5. It doesn't help at all, in fact it makes things worse. The >>>> community >>>>>> is >>>>>>> still >>>>>>> unable to process the changes, >>>>>>> 6. The tension is rising, everyone is pissed, >>>>>>> 7. Xiaomi abandons contributing to NuttX. >>>>>>> >>>>>>> I don't see any bad will here, just poor management and constant >>>>>>> underfunding >>>>>>> of open source projects. Also, expecting a company to share how >> it >>>> uses >>>>>>> an open source project internally is ridiculous. It's their >>> business, >>>>>>> their tools, they don't have to share anything. They have no >>>> obligation >>>>>> to >>>>>>> contribute, this is not a copyleft project. Of course, >>> communication >>>>>> between >>>>>>> the companies that use the NuttX and NuttX community currently >>> don't >>>>>> exist, >>>>>>> and that sucks for both sides. And this is not just Xiaomi's >>>> approach, >>>>>> but >>>>>>> EVERY company using NuttX. >>>>>>> >>>>>>> How can we fix collaboration with Xiaomi - I have no idea. >>>>>>> Maybe the order of adding changes by Xiaomi is reversed and it >>>>> shouldn't >>>>>>> look like this: >>>>>>> >>>>>>> Xiaomi internal -> NuttX upstream -> Open Vela >>>>>>> >>>>>>> but like this: >>>>>>> >>>>>>> Xiaomi internal -> Open Vela -> NuttX upstream >>>>>> >>>>>> Yes, exactly, even those few maintainers working full time would >> have >>>>>> hard time processing such a batch of changes in such a short time >>>>>> without prior knowledge this is why descriptions are so important. >> No >>>>>> one else have problem with understanding that. >>>>>> >>>>>> But we are not working full time here, this is our hobby and >>>>>> safe-harbor, working far overtime in our own small business, at our >>>>>> own expense, with zero support from the big companies using NuttX. >>>>>> Then in return we are being called "stupid". Maybe we are because >> it >>>>>> turns out we are working for free for the big companies!! This is >> not >>>>>> what Open-Source is about. >>>>>> >>>>>> As I can see Xiang is still closing the PRs from Xiaomi. Looks like >>>>>> decision was already made. We are always confronted with existing >>> post >>>>>> factum situation with nothing to say. My only choice is to accept >>> that >>>>>> so I do. >>>>>> >>>>>> This " Xiaomi internal -> Open Vela -> NuttX upstream" seems to be >> a >>>>>> reality already. It was finally clearly stated that no new features >>>>>> are provided to NuttX and other updates often don't fit because >>>>>> codebase already diverged. More time passes the divergence is >> bigger >>>>>> and we will only have bigger problems because NuttX community does >>> not >>>>>> want constant breaking changes while these are part of Vela by >> design >>>>>> (kind of BSD vs Linux approach and this is okay). All these changes >>>>>> were only in Xiaomi interest, but not much support in many places >>>>>> clearly in need of support (i.e. security). >>>>>> >>>>>> >>>>>> On Wed, Feb 4, 2026 at 10:10 AM raiden00pl <[email protected]> >>>> wrote: >>>>>>> (..) >>>>>>> Another important thing. Once we've exceeded CI limits, all PRs >>>> should >>>>> be >>>>>>> automatically blocked. Ideally, we should set the repositories to >>>>>> read-only >>>>>>> mode until the limits reset. This way, we'd have an automatic, >>>> enforced >>>>>> PR >>>>>>> limit and time to review the changes. >>>>>> >>>>>> That would hurt all other contributions because one big company >> with >>>>>> unlimited resources drained all of our free community resources.. >> and >>>>>> something does not add up here because if their changes are always >> so >>>>>> well tested before then why they don't perfectly build at first run >>> on >>>>>> our upstream?? >>>>>> >>>>>> I may only suspect that brilliantly simple and perfectly elegant >>>>>> design of NuttX, even having so many changes introduced recently, >>>>>> still serves as a solid stable reference point for all other >>> projects. >>>>>> We should not block any other project with more progressive >> approach >>>>>> to walk away and grow, but we can easily predict the growing pains. >>> My >>>>>> guts tell me we should protect these brilliant NuttX design goals, >>>>>> even at the cost of community split we are currently facing. >>>>>> >>>>>> >>>>>> On Wed, Feb 4, 2026 at 10:33 AM Sebastien Lorquet < >>>> [email protected]> >>>>>> wrote: >>>>>>> I have warned about this problem for YEARS AND YEARS and it >>> happened >>>>>>> EXACTLY as I had seen. >>>>>>> >>>>>>> It is a good thing to be honest, that will reduce the amount of >>> work >>>>>>> from nuttx maintainers. >>>>>>> >>>>>>> If openvela (as I understand) has good features added by xiaomi, >> it >>>> is >>>>>>> the task of nuttx to upstream them as they wish, in a calm and >>>> positive >>>>>>> way, by taking enough time to think about the design and >> structure, >>>>>>> without all the stress and speed of a commercial corporate >> project. >>>>>>> >>>>>>> NuttX is not a commercial project. it has no targets to reach and >>> no >>>>>>> investors to please. >>>>>>> >>>>>>> It is a much nicer way to work and I think it is better like >> that. >>>>>>> >>>>>>> It is a good thing to have less xiaomi contributions forced in >>> nuttx. >>>>>>> >>>>>>> I think we can thank them for their past contributions that made >>>> nuttx >>>>>>> grow, but it is also a good thing to realize when it must stop >> (eg, >>>>>>> before NuttX becomes XiaomiX). >>>>>> >>>>>> This resonates with me as well. Looks like Xiaomi already departed >>>>>> from NuttX to OpenVela. We could have more time to focus on what is >>>>>> important for the community. There were companies before that took >>>>>> full NuttX into their products and returned nothing. Xiaomi seems >> to >>>>>> be the biggest returning contributor and after all that really >>>>>> deserves a huge appreciation!! >>>>>> >>>>>> But as a small community we are unable to cope with the pace of the >>>>>> the big tech company without any sort of financial support to have >>>>>> 108% focus only here.. but that would then make us company >>> employees.. >>>>>> and most of us probably prefer to stay independent on the community >>>>>> side in order to maintain freedom of choice. >>>>>> >>>>>> We should coexist peacefully in friendship, cooperate, stay in >> touch, >>>>>> exchange news about problems and possible fixes.. let each other >> grow >>>>>> in preferred way and speed.. and over all remember about our common >>>>>> root that is Gregory NUTT the creator and father of NuttX! >>>>>> >>>>>> >>>>>> On Wed, Feb 4, 2026 at 11:09 AM chao an <[email protected]> >> wrote: >>>>>>> @Sebastien Lorquet <[email protected]> >>>>>>> I’ve had just about enough of your toxic, hypocritical nonsense. >>>> Let’s >>>>>> cut >>>>>>> through your garbage and talk facts: >>>>>>> >>>>>>> 1. 1. Xiaomi’s contributions to NuttX are undeniable. (..) >>>>>>> 2. *2. Let’s talk about your track record.* (..) >>>>>>> 3. 3. Shut your mouth already. (..) >>>>>>> Every time I see your bitter, passive-aggressive posts, I feel >>>> sick. >>>>>>> You’re nothing but a keyboard warrior, a technical fraud who >>> loves >>>>> to >>>>>> run >>>>>>> his mouth while contributing nothing of value. Your constant >>>>>> negativity >>>>>>> isn’t constructive—it’s just sad. >>>>>>> >>>>>>> If you can’t contribute positively or keep your toxic opinions to >>>>>> yourself, >>>>>>> do us all a favor and disappear from this community. We don’t >> need >>>> your >>>>>>> kind here. >>>>>> >>>>>> Well, this proves many problems that NuttX community raised before, >>>>>> but from my perspective Sebastien is not the problem here, quite >> the >>>>>> opposite. Maybe the community split is unavoidable and will do some >>>>>> good for everyone the sooner the better. That concludes my >> position. >>>>>> >>>>>> Live long and prosper! :-) >>>>>> Tomek >>>>>> >>>>>> -- >>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>> >>>>>> On Wed, Feb 4, 2026 at 7:28 AM Tomek CEDRO <[email protected]> >> wrote: >>>>>>> >>>>>>> Whaat, so this is why Xiang closed so many PR recently? o_O >>>>>>> >>>>>>> https://github.com/apache/nuttx/pull/18340 >>>>>>> >>>>>>> Some snips from @xiaoxiang781216: >>>>>>> * Let's summary how Xiaomi do the test internally before we >>> upstream >>>>>>> patch to community: CT(1000+ test cases) (..), DT(10000+ test >>> cases) >>>>>>> (..), monkey test on 100 units sim/qemu/device (..), 10000+ >> manual >>>>>>> test which run by tester manually before we make an official >>> release >>>>>>> every two/three months. >>>>>>> * (..) Many bugs only happen in the special timing or scenario >> like >>>>>>> #18266? when the error happen there is no log at all, how can >>>>>>> @Otpvondoiatsdo provide you log? Do you print log after each >>>>>>> statement? It's stupid to ask the log for each patch without look >>> at >>>>>>> the change! >>>>>>> * (..) BTW, since the recent contribution rule change, Xiaomi >> team >>>>>>> already decides ALL new features and components which doesn't >>> tightly >>>>>>> couple with NuttX will never be upstreamed in the future. >>>>>>> * (..) If you still do review like this, my team will leave NuttX >>>>>>> community and never upstream anymore. @acassis. >>>>>>> * If so, we will stop contrubtion now! sorry, bye. >>>>>>> >>>>>>> Does this mean that Xiaomi departed from the NuttX project for >>> good? >>>>> :-( >>>>>>> >>>>>>> Was the main reason update to the Contributing Guidelines to ask >>> for >>>>>>> better quality contributions and less breaking changes? >>>>>>> >>>>>>> Why they did not mention their internal testing process details >> in >>>> any >>>>>>> way before? Why no support to the community knowing our >> limitations >>>>>>> and problems? I assumed that Xiang had perfect prior knowledge of >>>>>>> their contributions thus his fast approvals, and that was not a >>>>>>> problem, its just that we did not have a clue about incoming >>> changes >>>>>>> were just supposed to accept them. >>>>>>> >>>>>>> I can see now why breaking changes are big problem here literally >>> for >>>>>>> everyone.. and why there may not be a middle point possible. This >>> was >>>>>>> never about change descriptions or communication because change >>>>>>> already happened long before, we just did not know about that. >>>>>>> >>>>>>> Yes it looks now like the NuttX community was only a byproduct / >>>>>>> burden and Xiaomi focused already on their bleeding edge Vela. So >>>>>>> people now have to choose which path fits them best and which one >>> to >>>>>>> follow? >>>>>>> >>>>>>> What do you think about all of this folks?? >>>>>>> >>>>>>> -- >>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>>> >>>>>>> On Wed, Feb 4, 2026 at 6:09 AM Matteo Golin < >>> [email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>> To be completely honest I don't know how to resolve these kinds >>> of >>>>>> issues. >>>>>>>> >>>>>>>> The PR template that automatically appears contains exact >>>>> descriptions >>>>>> of >>>>>>>> what is expected in the description and where to find the >>>>> contributing >>>>>>>> guidelines. Many of the recent contributors ignore this and >> copy >>>>> paste >>>>>> AI >>>>>>>> output. In this PR you showed, the author said that >> descriptions >>>>>> require >>>>>>>> too much information and so they use AI to write them. Yet, as >>> you >>>>>> pointed >>>>>>>> out, the PR is still missing things (breaking change indicator, >>>>>> description >>>>>>>> of what was tested). That seems like willful ignorance to me. >>>>>>>> >>>>>>>> I have requested changes on these AI generated PRs and PRs >>> missing >>>>>>>> information to adhere to the guidelines, but I'm met with >>> hostility >>>>>> that I >>>>>>>> should simply trust contributors because Xiaomi has internal >>>> testing >>>>>> and >>>>>>>> review processes. When the community stance was clarified that >>>> tests >>>>>> need >>>>>>>> to be included and shown to work with the NuttX mainline, >> Xiaomi >>>> has >>>>>>>> decided that they will no longer contribute to the upstream >>> because >>>>> it >>>>>> is >>>>>>>> too much work. You can see that discussion here: >>>>>>>> https://github.com/apache/nuttx/pull/18340 >>>>>>>> >>>>>>>> This also resulted in all Xiaomi patches under review being >>> closed, >>>>>> which >>>>>>>> is unfortunate. I don't see an easy resolution here. We >> struggle >>>> with >>>>>>>> regressions being introduced by low quality PRs so we update >> the >>>>>>>> guidelines, Xiaomi floods the upstream with low quality PRs/AI >>>>>> generated >>>>>>>> PRs, we request changes to follow the contributing guidelines >> and >>>>>> Xiaomi >>>>>>>> contributors respond with hostility. It seems that they would >>>> prefer >>>>>> not to >>>>>>>> include testing or adequate descriptions and instead have >> company >>>>>>>> committers approve the patches because internal reviews were >>>>>> performed. I >>>>>>>> don't think NuttX should become a company "product" and I think >>> the >>>>>>>> contributing guidelines are reasonable to keep code quality >> high >>>> and >>>>>> save >>>>>>>> reviewer time. I don't really see a middle ground considering >>> that >>>>> the >>>>>>>> contributing guidelines were voted on and are improving the >>> quality >>>>> of >>>>>> PRs >>>>>>>> that we merge. >>>>>>>> >>>>>>>> On Tue, Feb 3, 2026, 11:52 PM Tomek CEDRO <[email protected]> >>>> wrote: >>>>>>>> >>>>>>>>> Hmm, discussion here is quite sad to be honest, but a good >>>> example >>>>> of >>>>>>>>> the problem with a clear summary: >>>>>>>>> >>>>>>>>> "@Otpvondoiats: @linguini1 I can understand that you don't >>>> welcome >>>>>>>>> open source contributors, so please don't review my patches >>>>> anymore." >>>>>>>>> >>>>>>>>> https://github.com/apache/nuttx/pull/18266 >>>>>>>>> >>>>>>>>> Whether it was AI generated or not we already see the general >>>> loss >>>>> of >>>>>>>>> trust. Maybe it is more important than we think. I hoped that >>>>>>>>> Contributing Guide updates would make things easy by defining >>>> clear >>>>>>>>> expectations for both contributors and maintainers. >>>>>>>>> >>>>>>>>> What is more, PR contains breaking changes that are not >> marked >>>>>>>>> presented nor discussed correctly as expected, which is >> another >>>>>>>>> problem to skip for now. >>>>>>>>> >>>>>>>>> Do we want to treat open-source as our own private playground >>>> where >>>>>> we >>>>>>>>> can put whatever we want however we want without minding >> other >>>>>> people? >>>>>>>>> >>>>>>>>> Lets focus on how to improve things.. is it >> miscommunication.. >>>>>>>>> misunderstanding.. purposeful ignorance.. enforcing changes? >>> How >>>>> can >>>>>>>>> we meet in the middle? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>>>>> >>>>>>>>> On Tue, Feb 3, 2026 at 4:04 PM Matteo Golin < >>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> This week in particular there has been a large number of >>>>>> AI-generated >>>>>>>>> pull >>>>>>>>>> requests submitted to NuttX and NuttX apps. Most of these >>> used >>>> AI >>>>>> to >>>>>>>>>> completely generate PR descriptions and/or commit messages. >>> In >>>>> some >>>>>>>>> cases, >>>>>>>>>> AI was used to generate documentation and possibly code. >>>>>>>>>> >>>>>>>>>> The quality of these PRs are low, containing unnecessary >>>>>> information that >>>>>>>>>> summarized the diffs (i.e. files changed, lines inserted, >>> etc) >>>>> and >>>>>>>>>> repetitive summaries. The dangerous aspect of these PRs is >>> that >>>>>> the vast >>>>>>>>>> majority of them contained completely generated test claims >>>> with >>>>>> no logs >>>>>>>>>> (and in some cases, generated logs) to back them. When >> asked >>>>> about >>>>>> the >>>>>>>>> test >>>>>>>>>> claims, the authors stated that the PR was AI-generated and >>>>>> removed all >>>>>>>>>> claims. >>>>>>>>>> >>>>>>>>>> This is starting to become a trend, with a lot of recent >> PRs >>>>>> containing >>>>>>>>> the >>>>>>>>>> same "files changed" section. They are difficult to review >>>>> because >>>>>> they >>>>>>>>>> don't communicate the changes clearly, have unnecessary >>>>>> information and >>>>>>>>>> often contain fabricated information. Some of them contain >>>>> multiple >>>>>>>>> commits >>>>>>>>>> which should be reviewed split across multiple PRs and >> change >>>>>> summaries >>>>>>>>>> which omit information about commits. PR authors are also >>>>> refusing >>>>>> to >>>>>>>>>> provide logs or adequate explanations in some cases. >>>>>>>>>> >>>>>>>>>> I think it's time for the community to discuss a stance on >> AI >>>>>> generated >>>>>>>>>> submissions. I don't think it's enforceable to prevent >>>>>> contributors from >>>>>>>>>> using AI in their PRs, and some contributors may be using >> it >>> to >>>>>> assist >>>>>>>>> them >>>>>>>>>> in a moderate way (I personally do not think any AI use is >>>> good, >>>>>> but I >>>>>>>>> know >>>>>>>>>> this is not realistic for many people). I think that PRs >>> which >>>>>> contain AI >>>>>>>>>> generated descriptions or code should be blocked by a >> change >>>>>> request >>>>>>>>> until >>>>>>>>>> they are modified to improve the code quality or >> description >>>>>> quality. >>>>>>>>> This >>>>>>>>>> isn't really a change, that's what we do with poor code >>>>>> submissions. >>>>>>>>>> However, I think contributors should be warned to stop >> using >>> AI >>>>>> output if >>>>>>>>>> they are not verifying it, and there should be a stance >> from >>>>> NuttX >>>>>> in the >>>>>>>>>> contributing guidelines regarding AI usage/guidelines. If >> it >>>>>> becomes a >>>>>>>>>> pattern for certain contributors I think their PRs should >>> start >>>>>> getting >>>>>>>>>> closed. >>>>>>>>>> >>>>>>>>>> What does the community think? >>>>>>>>>> >>>>>>>>>> Matteo >>>>>>>>>> >>>>>>>>>> Here are some of these AI PRs: >>>>>>>>>> >>>>>>>>>> https://github.com/apache/nuttx-apps/pull/3381 >>>>>>>>>> https://github.com/apache/nuttx-apps/pull/3397 >>>>>>>>>> https://github.com/apache/ < >>>>>> https://github.com/apache/nuttx/pull/18223 >>>>>>>>>> nuttx >>>>>>>>>> <https://github.com/apache/nuttx/pull/18223>/pull/18223 >>>>>>>>>> <https://github.com/apache/nuttx/pull/18223> >>>>>>>>>> https://github.com/apache/nuttx/pull/18266 >>>>>>>>>> https://github.com/apache/nuttx/pull/18221 >>>>>>>>>> https://github.com/apache/nuttx/pull/18219 >>>>>>>>>> https://github.com/apache/nuttx/pull/18217 >>>>>>>>>> https://github.com/apache/nuttx/pull/18216 >>>>>>>>>> https://github.com/apache/nuttx/pull/18205 >>>>>>>>>> https://github.com/apache/nuttx/pull/18207 >>>>>>>>> >>>>>> >>>>> >>>> >>> >>
