> The real prejudice is on my side when it takes one week to update from a > 6 month old nuttx and the resulting image does not even run. Can you > imagine this burden and frustration and stress? My boss is not happy > about this and it's not my fault. I know it's an open source project > without warranty, but clearly, pushing too many untested code is not > helping.
I understand your situation and can really empathize with you. However, every time I encounter similar problems, I just want to solve them. I know it's difficult for every developer. So if you come across similar issues, you don't need to spend too much time trying to solve them on your own. You have a community, and everyone from community will actively step up to fix the problems. Moreover, you can see that some core-developers fix regression issues within 24 hours. What we're actually worried about is that too many problems are lurking in the community. I'm really honored to hear you complaining about what has happened recently. > My goal is to see both evolution and stability of nuttx of all users, > because I'm not against changes, but I want to see a better way to > integrate the changes. Agree with you. This is precisely why I sent the spin_lock issue to the mailing list. It's to keep the semantics of the existing API consistent with the previous ones, so as to prevent individual developers and 3-party projects from spending more time debugging problems caused by NuttX upgrades. BRs, Sebastien Lorquet <sebast...@lorquet.fr> 于2025年2月5日周三 22:27写道： > Hello, > > The real prejudice is on my side when it takes one week to update from a > 6 month old nuttx and the resulting image does not even run. Can you > imagine this burden and frustration and stress? My boss is not happy > about this and it's not my fault. I know it's an open source project > without warranty, but clearly, pushing too many untested code is not > helping. > > Can you please take steps so we can see an effort from your company to > establish a more concerted contribution initiative instead of a constant > stream of changes every day, with the great risk to introduce unwanted > bugs? Honestly, we all know the automatic tests run today are not enough > to ensure all your changes are working. Something has to be done. > > Pre-staging your changes for some time before contributing would be a > great step in getting everything better. It would allow more time for > reaction. > > > On 05/02/2025 15:11, chao an wrote: > >> This is not an Apache Project communication channel, so it does not > >> exist as far as we are all concerned. > > actually we've had extensive discussions on the community PR, but no one > > has ever cared about this issue. I would feel highly honored if I could > get > > some tips from you. > > https://github.com/apache/nuttx/pull/15705 > > I am not a specialist of spinlocks. But I know changing it can break > many things in subtle ways and I know it's better to be safe than sorry. > This project has actual users and we need to be careful. > > If no one has ever cared about the issue, and you know someone has to > care, then the solution is not to push it anyway. You need to force us > to care. > > I am honest, there are too many pull requests and commit, I do not even > know where and how to start. I cannot spend full time looking at all > your contributions, it's too much, it's complex and subtle. > > A pre-contribution repository would help greatly to see the desired > contributions, discuss them and select the best options. The only long > term solution is to slow down. If you cant slow down, then we need a > "buffer" to adapt your rate of contribution to the rate of review > available from nuttx contributions. > > > > > >> As a general rule, please stop testing your changes in prod, I know you > >> refuse to reply to me but you read anyway. > > I just haven't figured out how to reply to you. I agree with your > opinion, > > However, could you please refrain from criticizing others with > prejudice? I > > could have chosen not to send this email. But I hope that we can have > > further discussions to make the revisions even more perfect. > > We have different cultures and reactions so it is expected that this > kind of friction will occur. This is an expression of my long term > frustration (several years). > > I know it is not the best way to react but I have not figured any other > method to wake up people about this perceived problem. > > My goal is to see both evolution and stability of nuttx of all users, > because I'm not against changes, but I want to see a better way to > integrate the changes. > > Sebastien > > > > > >> If I understand correctly spinlocks are basically a no-op when no SMP is > > involved, which is the majority of CPUs supported by NuttX. You shall not > > break all platforms. > >> I urge you all to revert any commit that might have broken something in > > this domain, redesign it carefully on your own code fork, and then push a > > final working version to nuttx. > > > > I'm also really grateful for your advice. I believe everything is getting > > better. > > > > BRs, > > > > Sebastien Lorquet <sebast...@lorquet.fr> 于2025年2月5日周三 22:01写道： > > > >> Hi, > >> > >> On 05/02/2025 13:03, chao an wrote: > >>> I talked with > >>> Xiaoxiang in WeChat before. > >> This is not an Apache Project communication channel, so it does not > >> exist as far as we are all concerned. > >> > >> > >> These changes MUST be tested in a separate code branch so all platforms > >> can be tested and validated for several weeks. > >> > >> We need an explicit GO on every supported arch (SMP and not SMP) before > >> this goes into main/master. > >> > >> These are critical core changes that have potential to introduce very > >> nasty bugs that will be very hard to track. > >> > >> It may take time to validate all of this, and this delay is fine. > >> > >> > >> As a general rule, please stop testing your changes in prod, I know you > >> refuse to reply to me but you read anyway. > >> > >> > >> Sebastien > >> > >> >
