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