Dev update: The tool works, does not download 300MB of repos for each
build, and is ALMOST ready I'll just finish the reporting of results
tomorrow. UTC+1 here.
Sebastien
On 2/4/26 18:34, Sebastien Lorquet wrote:
I have decided to work on distributed CI because Alan clearly listed
this as a tool that will help the community.
It wont be fancy initially, but it can be improved later. Release
early, release often, yeah?
So I am writing a tool that will allow many clients to fetch and
report jobs, in a way that can run on ANY machine with python and
build tools.
Remarkably for the moment there are NO dependencies on anything that
is not the default, except php-sqlite, which is easy to get.
I have written a specification of what I imagine.
https://code.f4grx.net/software/nuttx-builder
I have also spent the afternoon (ooops) writing code for these tools.
At the moment the tools are able to create the job db, add/remove
users and add/list/cancel jobs. the php script can return jobs and
mark them as pending.
And it WORKS. in one afternoon. I was not very productive at dayjob
lol. No slop machine was used to generate this.
Next step is the build tool itself, probably my hobby task for this
evening.
It is not deployed yet, dont ask me for a url.
Please be creative and imaginative, I know the code probably sucks,
what counts here is the *protocol*. I took as many shortcuts as
possible to get into a working state FAST.
I am absolutely NOT a server guru, the server can be implemented any
way you like, dashboard and stats and stuff, I am unable to do it, so
it's a simple php script. I just care about the client and protocol.
Play with it, look at it, scream in horror, do something!
I am certain that pull requests from github can be wired into
something that can work with this tool, I can add server side APIs to
submit jobs from a php script later, so you can poke it from github ci
stuff I have no idea about and dont want to know about haha.
I guarantee that when this tool works, I will run it on at least 6 of
my machines, and not just raspberry pis, several of them have 16
cores, several of them are very underused VPS. We can do stuff to
limit the cpu load so the machine stays usable when it builds (thats
cgroups iirc?).
Sebastien
On 2/4/26 14:19, raiden00pl 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.
