Yes, I think this is a good example of when requiring logs is excessive. We could define a more pragmatic approach:
- Require logs only for modifications that could break many (or all) architectures, such as scheduler modifications, etc. - If it's a fix for some functionality that was broken and the test is trivial, provide a log showing that the fix solves the problem. - If the fix is not testable (requires some board/sensor that the author doesn't have, but the fix does what the datasheet/etc says), just state that in the test summary in the PR. Any other suggestions? BR, Alan On Wed, Feb 4, 2026 at 10:17 AM raiden00pl <[email protected]> wrote: > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
