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