Hello, I was not aware of how the thumbs-down emoji is interpreted in Chinese culture. I was using it to express displeasure at the harsh words. I absolutely did not intend for it to be as offensive as it was received and I apologize for using it.
Matteo On Thu, Feb 5, 2026, 8:34 AM 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
