> @ 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 > > > > > > > > > > > >
