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
