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