the solution is simple. dont fix what is not broken, even if you really
really really want to optimize something.
also you could have an official "out of tree board" that you keep
working so customers can track these changes.
linux is a moving target but not its build system. There is some thought
dedicated to its architecture.
Also you dont have to follow the kernel mailing list daily and the
commit log to just use linux or build a module.
Honestly there were changes to netlib arp and they werent that hard to
bring in.
But the build system, wow! Every time its structure changes, it takes so
long to fix!
The contents of the main Make.defs is also a nightmare to track. It's
full of critical stuff, none of which is documented and tracked,
including when it was introduced, renamed, new critical stuff added,
etc. At one revision? No one knows (not me at least lol).
Maybe someone can explain this breakage, which is what broke the camel's
back? That wont change my mind for now. NuttX is going out out of my
scope until some effort is done to make it more stable over releases.
slo@slolin:~/Sources/product-env/nuttx$ LANG=C tools/configure.sh -a
../product/apps/ ../product/board/configs/net
Copy files
sed: -e expression #1, char 11: extra characters after command
sed: -e expression #1, char 16: unknown command: `O'
sed: -e expression #1, char 17: extra characters after command
sed: -e expression #1, char 14: unknown command: `S'
sed: -e expression #1, char 11: extra characters after command
sed: -e expression #1, char 13: unknown command: `O'
sed: -e expression #1, char 17: unknown command: `O'
sed: -e expression #1, char 11: unknown command: `m'
sed: -e expression #1, char 14: unknown command: `Z'
sed: -e expression #1, char 15: unknown command: `O'
Select CONFIG_HOST_LINUX=y
Refreshing...
CP: arch/dummy/Kconfig to
/home/slo/Sources/product-env/nuttx/arch/dummy/dummy_kconfig
CP: boards/dummy/Kconfig to
/home/slo/Sources/product-env/nuttx/boards/dummy/dummy_kconfig
LN: platform/board to /home/slo/Sources/product-env/product/apps/platform/
LN: include/arch to arch//include
No directory at /home/slo/Sources/product-env/nuttx/arch//include
make[1]: *** [tools/Unix.mk:286: include/arch] Error 1
make: *** [tools/Unix.mk:725: olddefconfig] Error 2
ERROR: failed to refresh
slo@slolin:~/Sources/product-env/nuttx$ LANG=C make distclean
make[1]: *** arch//src: No such file or directory. Stop.
make: *** [tools/Unix.mk:794: arch//src_clean] Error 2
Imagine my surprise to find this.
Even distclean is broken. Why. This worked with a nuttx from around may
2024. What happened? I have no time for this.
I already spent a day to port it from one year ago to half a year ago.
Hundreds of commits have happened. I dont have time to track these breakage.
Please keep the basics working. I did not make "weird" changes in my
product. This worked before.
Sebastien
On 29/01/2025 14:20, Alan C. Assis wrote:
Hi Simon,
Yes, but it important to prove your point using a commercially available
development board.
NuttX (just like Linux) is a moving target. So one out of tree board always
will break because people are constantly changing the building system and
moving things of place.
There is no simple way to avoid this evolution. Unfortunately! So, those
companies using NuttX could stick to a fixed release or use some automatic
patching process to detect issues early and report to us.
BR,
Alan
On Wednesday, January 29, 2025, Simon Filgis<si...@ingenieurbuero-filgis.de>
wrote:
Just for my understanding, could I vote -1 for a release that is not
building/working properly for my board?
Alin Jerpelea<jerpe...@gmail.com> schrieb am Mi., 29. Jan. 2025, 12:24:
Hi all,
I started a thread some time ago asking for imput and wishes from all of
us
so that we cans set some goals and create a roadmap
Unfortunately the mail got little traction....maybe now we can revive it
and complete a roadmap
Best regards
Alin
On Wed, 29 Jan 2025, 12:14 raiden00pl,<raiden0...@gmail.com> wrote:
I completely agree that project management in NuttX is either lacking
or
completely non-existent. I think the lack of a generally accepted road
map
for
the project is the biggest problem here. TBH we don't even know where
the project is headed. Probably if this large number of commits were
supported
by some kind of roadmap so that it would be known what the goal of
these
changes is - it would make more sense.
In the long run, without coordinated collaboration between teams
working
separately on NuttX and without a commonly accepted roadmap, I think
the
project
may fail spectacularly.
This is where the advantage of BDFL projects comes in. One person has
authority over the project and manages it according to his/her vision.
Managing a project in a distributed manner is a difficult task,
and so far we are not succeeding at it. I think NuttX hasn't correctly
transitioned from being managed by Greg (BDFL model) to being managed
by
distributed management yet. And this is the biggest problem here.
And how to fix it? I have no idea, but I don't think limiting the
number
of
changes
to the project is a solution. Maybe a good first step is to discuss and
establish
a project roadmap with its contributors and companies that are
interested
in it.
But this requires someone to coordinate the process and preferably has
experience
in managing distributed open source projects. I don't know if we have
such
a person in our group.
śr., 29 sty 2025 o 11:33 Sebastien Lorquet<sebast...@lorquet.fr>
napisał(a):
hi
On 29/01/2025 10:21, raiden00pl wrote:
Sebastian, so you're saying that you and your company have the
resources
to
develop
and maintain your own RTOS, but you lack the resources to help
maintain
NuttX (e.g., code review, release testing.)?
This either doesn't make sense or you just don't want to
participate
in
this project.
I dont have resources for a project as large as nuttx, obviously.
And I
dont need to.
it will take some time and it will be much simpler. In fact I have a
project that is almost working for this including a vfs.
Or I'll find a project that cares about long term support.
But for sure, I'll get rid of nuttx, thats enough: every time I
update,
everything is broken, the build system is not stable, and what used
to
work does not work anymore, including things as simple as the
configure.sh script. it takes ages just to get our code to compile
again
before I can consider any improvement.
I dont have energy to spend for such dumb fixes. I'm loosing my time
in
a completely useless way.
I prefer sending more time being productive with the goal of
controlling
our software stack.
Cherry-picking a single commit to justify your frustration isn’t
fair.
Yes, some commits may be poorly described, but we actively try to
improve in
that regard. With a limited number of contributors, it’s
understandable
that our
reviews aren’t perfect. However, it's worth noting that neither you
nor
your company contributed to addressing this issue.
come on, do you really think it's just one commit? if you cant guess,
no
it isnt. this was just an example to show that your own policies are
not
even applied correctly.
before using ai to review pull requests, just make sure that commit
messages are useful! But you cant, there's too many stuff to check.
that's a huge red flag for me.
it's an accumulation of problems, for years, with no changes, and
it's
getting worse. The more you add auto tool, the more they are
circumvented, because developers know that no one will check.
No, I dont want to fix anything in nuttx anymore. it's no use. I'm a
drop in an ocean, just complaining to a community that does not care
and
just want to code faster than light.
also, you have several developers pushing hundreds of commit every
week.
if they wanted to fix anything, they would do it.
That’s completely fine, everyone has different priorities. What is
NOT
OK is
criticizing those who dedicate their time to this project, often
voluntarily.
This is one of the biggest problems with open source projects:
people who give little, demand a lot and complain about others.
there are different way to dedicate available time.
My conclusion is that volunteers here are not spending their time
wisely.
I have no wish to spend energy for project management. But I can see
that something is wrong here, definitely.
BTW, if your product works on earlier NuttX releases, wouldn’t it
be
easier
to stick with a stable release and selectively cherry-pick only the
changes
that matter to you?
Tried to do that for tcp keep alive, which is broken in the version I
was using. but the full network stack has completely changed in a few
months. I cant cherry pick and apply anything.
thats beyond frustration.
I need a full nuttx upgrade after one year and first thing I need to
understand is why configure.sh is complaining about sed. wtf???
so the only way to use nuttx long term is by following the master
branch
every day?
that is not going to happen.
It's a pity that you're leaving because I remember that you've been
in
this
community for a very long time. Your critical perspective (the
correct
way
of
doing engineering IMO) was really useful and is something that is
unfortunately
disappearing in today's world.
this is sad but my conclusion is I cant change anything in this
project,
so it's no use banging my head on the wall with no purpose.
it would be great if my departure would lead to your reconsidering of
this project management and leadership.
if you looked at the reality, and detected that the amount of commits
coming daily is not a sustainable way to manage project.
but lets be honest. nothing will happen, right? I've been here for
long
enough to be sure of that.
so I'm out.
this is good for you: I'll stop complaining.
Take care and good luck.
wt., 28 sty 2025 o 16:19 Tomek CEDRO<to...@cedro.info>
napisał(a):
On Tue, Jan 28, 2025 at 11:23 AM Sebastien Lorquet <
sebast...@lorquet.fr>
wrote:
my trust in nuttx is now hard to maintain.
Every day a DELUGE of commits (from xiaomi, this is a fact) is
added
to
the repository.
I am struggling to understand what happens in this project.
so many fixes are pushed, how is that even possible? this is a
quicksand
project!
Sebastien, I feel your pain. Not necessarily with NuttX as this is
my
"safe island". But with all Open-Source in general. This is the
result
of enforced-changes ideology introduced ~30 years ago by Microsoft
that surrounds us even in daily non-computer life. I don't even
mention commercial products that get constantly more expensive and
clearly have no basic QA process and break ~6 month after
purchase.
I
lost trust in big brands long ago.
Also, how are such commits (not from xiaomi!) allowed? No
description
except "uf2" ? Where is the adult in charge?
We do what we can, updated documentation and requirements, added
helper bots with feedback, etc, and require sensible
descriptions. I
even update some PR descriptions by hand. Still it is git log that
contains the history true.
There is only few people that review the code. If you could help
us
that would help a lot! You may not use GH for projects just to
help
us
in review..
I am announcing that after that many years my company has started
to
develop a minimal rtos to replace our usage of nuttx, because it
is
just
not stable enough to be usable for stable long term projects.
There are too many changes, we are loosing money every time we
need
an
update. there is no way to maintain the use of a nuttx custom
board
and
project over several years.
Having control of our code will be a better investment. That will
obviously be closed source. Which is, after all, a better way of
control
on our products.
I am facing the same situation for some long years and it gets
worse
and worse :-( Either use something that is advertised to work
quickly
but then you are tied to constant moving target and maintenance
nightmare and if you want to change one simple thing it takes more
time than would take me to write everything myself. On the other
hand
it is impossible to write everything on your own. I wrote from
scratch
the LibSWD ~15 years ago to be able to debug.. and it turns out
today
that I can do much more today with a commercial probe :-( All
previous
project made with fancy pancy RTOS and frameworks are now in
trash.
Solutions like Linux and FreeRTOS also change API every release
that
causes maintenance nightmare. I use FreeBSD as OS but it also has
its
own problems, more changes are introduced with every release,
drivers
adopted to be compatible by so called "Linux standard" are
self-incompatible nightmare.
I am working with niche solutions but the changes come constantly
from
other places and that impacts even those niche solutions. You will
have the same problem with your own RTOS as I face them in my own
projects :-(
This comes mainly from enforced changes ideologies that are
advertised
as "innovation" by people with zero old-school coherent simple and
effective engineering knowledge.. and maybe from exponential
growth
that is objectively hard to cope without full time team and that
requires funding we have and no one really cases about funding
Open-Source just taking the results for free.
No amount of my involvement in the github triage is going to
help,
the
case is desperate. I just have no time, no energy, no motivation,
no
spoons left to deal with this. it's a deluge of commits, let it
be,
but
without me.
Yes, but what was the last time you helped us in review? This is
our
best-effort and all brainz matter! Help us to make things good. I
always valued your constructive criticism on the mailing list.. it
would be more than welcome and appreciated on GH too. But you are
not
on GH so how can you help? I also dont like Microsoft took over
GitHub, I also dont like their fake support for Open-Source while
its
clearly an exploitation, I also dont like we need to ask for over
5
years for FreeBSD CI runners and it is rejected every time. I also
use
other platforms to host projects, but this is a common place, a
tool.
the warning from the apache foundation that you use too many ci
credits
should have been a warning to slow down and reflect on the
project
direction. nothing has happened except making it even faster.
Not really. I would expect support from Apache in tuning stuff,
maybe
adapting resources to scale of the project (tiny projects have the
same amount of resources as big projects). We updated and
optimized
the CI process as a result. We are working on more independent
solutions for both code hosting, build automation, and runtime
testing. But this is not a weekend work for few people in a free
time.
I agree there is a problem. But we do what we can to fix it. All
brainz matter. Help us make things good.
I will also discourage people to use this project, I cannot in
good
conscience recommend it to anyone, it would be a trap.
Just as any other Open-Source project nowadays unfortunately. I
dont
even mention closed source SDKs that change on monthly or weekly
basis
and you have nothing to say just to chase the rabbit. I feel your
pain
because I face the same problems for a long time. There is
however a
difference in enforcing changes just to make things "modern" or
adding
modern stuff in best-effort incremental way respecting the
old-school
engineering rules that I think we follow here in NuttX. Problems
happen everywhere. The problem is what you do with the problem.
Creating your own RTOS may be a solution but you will eventually
face
the same problems. In the long term it may cost you even more than
just helping us from time to time to make things right.
goodbye.
Sebastien
This is your decision Sebastien, and we respect it. Hopefully you
will
reconsider and help up make things good in the process, hands-on,
with
the tools that we have available. You are always welcome back!!
Thank you and take care!
Tomek
--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info
