Hi Simon, you can always vote as a community member with -1 and explain what the issue is (you can check the last release vote thread)
The release process for each release: 1) a release branch created 3-4 weeks before the release. (you can test your board on it and post bugs in the bug report) 2) the release manager will back-port fixes to the branch and make sure that the release branch is in good shape (no new features will be added) 3) the release manager will create the RC releases and submit them for community vote 4) the community will test the RC and vote the release - if the issue is affecting just a board will not stop the release (we will document it as a known issue with the release - if the issue if affecting multiple boards or platforms we will stop the release, get back to step 2 5) if the release passes the community vote it becomes official NuttX tries to stick to a quarterly release (release branches will appear in March, June, September, December with releases aimed for the end of each of those months depending depending on voting results). I hope that this process answers your questions Best regards Alin On Wed, Jan 29, 2025 at 12:30 PM 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 > > > > >> > > > > > > > > > >
