Hi All, @Xiang, please reconsider resuming contributing to NuttX. You, your team and Xiaomi are welcome on this project! I can't remotely enumerate how much your contributions (being code, or man-hours to review upstream PRs) enhanced NuttX throughout these years. @Xiang, @Donny and @Otpvondoiats (sorry If I missed your name): I'm really sorry for this conversation.
For everyone on the NuttX project: please, be kind - always be kind and respectful. Please remember that the NuttX community is spread across the globe, and we may have different approaches. Communication is a problem in this scenario, and it'll be even worse if we don't account for the differences. We must always expect the best of whom contributes to this project. That being said, let's talk about technical aspects: AI discussion here is out-of-scope: I strongly suggest that we keep our own opinions about the subject out when reviewing a PR. AI agents may evolve even further, and we won't be able to judge if something was AI-driven or not. The PR's author is responsible for submitting it, providing tests and logs (if possible), and fixing any issues. On the other hand, reviewers are responsible for ensuring that the code meets NuttX requirements. That's it. @raiden00pl: your analysis here <https://www.mail-archive.com/[email protected]/msg14188.html> is perfect. Xiaomi is bigger than NuttX. We lack reviewers. @matteo, I understand your concerns about reviewing code. PRs' descriptions should provide reproducible test scenarios (in the sense that any other developer could replicate the problem, apply the patch and check the solution). However, we should also consider scenarios where it might not be able to and move forward. Your code review is well appreciated as well! @Donny and @Otpvondoiats, technically speaking, please reconsider the effort of adhering to PR's description guide. The most important point is the summary. The testing section should (ideally) provide a way to reproduce the problem, how to apply the patch, and then verify that the problem is gone. I understand that this might not always be possible, but it's an effort we should always look for. When using AI to generate the description, ensure it generates meaningful (and summarized) results to ease code reviewing (and not add a burden). There is no problem doing that ;) @all: NuttX is a relatively small project, and without the help of companies that not only use NuttX but also promote it, we'd be in a hurry as an open-source project. Please consider that companies that contribute are positive additions to the community. CI/CD enhancement is the way to improve the community and deal with a larger volume of contributions. We'll reach that point! Wish you (and NuttX!) the best! Tiago. Em qua., 4 de fev. de 2026 às 10:17, raiden00pl <[email protected]> escreveu: > > For some bugs, we have already provided a clear description of the issues > > encountered and the modifications made. > > If a bug inherently has no valid logs available, where can we possibly > > get logs ? > > There was a similar situation with some PCI related changes or netdev. A > simple change, > an obvious bug, and a "review request." Even if I understood the change and > wanted > to merge it, I was blocked because "no logs." Sometimes providing logs is > more > difficult than the change itself. > > I've said this many times before: not every PR is the same, and not every > change > requires the same testing. If a maintainer knows what they're merging, they > should > have the right to do, even if it's blocked by another maintainer. But > there's another > problem here: what if a maintainer abuses this rule? We had that problem > too, which > led to even more frustration for maintainers. > > > The automation test logs don't enough ? > > If so, we should optimize the automation test. > > Everyone agrees with that. But recently, even improving automation with > NTFC was > blocked because CI resources were consumed by Xiaomi's changes. I've > prepared > more NTFC changes to enable testing on more targets, but I can't upstream > them > because it will burden CI even more. > > śr., 4 lut 2026 o 14:02 Guiding Li <[email protected]> napisał(a): > > > Hi Alan & Alin, > > > > Thanks for standing up for what’s right. > > > > But noone has answer my questions yet: > > > > For some bugs, we have already provided a clear description of the issues > > encountered and the modifications made. > > If a bug inherently has no valid logs available, where can we possibly > > get logs ? > > > > Take the following PR for example. > > https://github.com/apache/nuttx/pull/18266 > > > > 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. > > > > Asking for logs without such background knowledge is simply > self-deceptive. > > > > How can I provide the logs ? > > > > The automation test logs don't enough ? > > If so, we should optimize the automation test. > > > > > > > > Alan C. Assis <[email protected]> 于2026年2月4日周三 19:37写道： > > > > > The discussion is more technical than political. If we call them in to > > > mediate, it will become purely political. > > > > > > On Wed, Feb 4, 2026 at 8:28 AM raiden00pl <[email protected]> > wrote: > > > > > > > > No, please don't! Everyone here is mature (ok, not everybody) to > > solve > > > > our > > > > own problems. > > > > > > > > I don't see a problem with seeking help from an organization that's > > > already > > > > takes credits from NuttX through our contributions to project. > > Especially > > > > since > > > > solving such problems requires experience and intuition in managing > > > > open source projects. I don't have such experience and I don't think > > > anyone > > > > in our community has such experience. As you can see, it's not going > > well > > > > for > > > > us so far :) > > > > > > > > > > > > śr., 4 lut 2026 o 12:17 Alan C. Assis <[email protected]> > napisał(a): > > > > > > > > > Hi Mateusz, > > > > > > > > > > No, please don't! Everyone here is mature (ok, not everybody) to > > solve > > > > our > > > > > own problems. > > > > > > > > > > Please we don't need to ask "Momy" to solve our fight with our > > > brothers. > > > > > :-) > > > > > > > > > > BR, > > > > > > > > > > Alan > > > > > > > > > > On Wed, Feb 4, 2026 at 7:32 AM raiden00pl <[email protected]> > > > wrote: > > > > > > > > > > > Maybe it's worth contacting the Apache Foundation for help? Could > > > they > > > > > > offer some > > > > > > advice on how to handle problems we have here? Like how to handle > > > > > > situations where > > > > > > contributions exceed the community's capacity to process them? > > > > > > > > > > > > I think there are many open source projects bigger than NuttX, > that > > > > deal > > > > > > with such > > > > > > problems with systemic approach. We're not the first project to > > have > > > > such > > > > > > problems. I'm sure the Apache Foundation is full of great people > > with > > > > > > experience in > > > > > > managing big projects, maybe it's worth asking for advice? > > > > > > > > > > > > Of course, I disagree with Sebastian. For me, Xiaomi leaving the > > > > project > > > > > > would be > > > > > > a sign of the death of NuttX. To be clear: Xiaomi pays me so I'm > > > > biased, > > > > > > but still > > > > > > about 90% of my contributions to this project were made in my > free > > > > time, > > > > > > for free. > > > > > > > > > > > > It's sad to say but [my opinion now] without Xiaomi, this project > > > would > > > > > > have been dead > > > > > > long ago and I personally would lose any interest in NuttX. > > > > > > > > > > > > > > > > > > śr., 4 lut 2026 o 11:09 chao an <[email protected]> > napisał(a): > > > > > > > > > > > > > @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. > > > > > > > Their work has driven real progress, fixed critical issues, > > and > > > > > > expanded > > > > > > > the project’s capabilities. If you’re so unhappy with the > > > > community, > > > > > > no > > > > > > > one > > > > > > > is forcing you to stay—feel free to leave and stop poisoning > > the > > > > > space > > > > > > > with > > > > > > > your negativity. > > > > > > > And for the record: I work at ByteDance (TikTok), so I have > > zero > > > > > > > affiliation with Xiaomi. This isn’t a defense of a > > company—it’s > > > a > > > > > > > defense > > > > > > > of basic fairness and respect for people who actually > > contribute > > > > to > > > > > > this > > > > > > > project. > > > > > > > 2. *2. Let’s talk about your track record.* > > > > > > > - 90% of your commits are trivial, history-driven busywork. > > Your > > > > > > > so-called “contributions” are negligible at best. > > > > > > > - When was the last time you reviewed a core code change, > > or > > > > > > > contributed to the CI/CD pipeline that keeps this project > > > > > running? > > > > > > > You’ve > > > > > > > done nothing to move NuttX forward, yet you love to sit > on > > > the > > > > > > > sidelines > > > > > > > and trash people who *actually* do the work. > > > > > > > - You have zero credibility to judge anyone else’s > > > > contributions. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > Sebastien Lorquet <[email protected]> 于2026年2月4日周三 17:33写道： > > > > > > > > > > > > > > > Hello again, > > > > > > > > > > > > > > > > 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). > > > > > > > > > > > > > > > > Sebastien > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/26 10:11, raiden00pl 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. > > > > > > > > > The tension is rising, and we have what we have: a > disaster. > > > This > > > > > > > > approach > > > > > > > > > is > > > > > > > > > an obvious recipe for failure. > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
