so thats how it's going to happen?
One small email from one of the one company that causes most of the
problem, no discussion, and that is done?
Think about that once again.
My idea at this stage is quite different.
Every large company wanting to push many commits into nuttx should have
a code of conduct that they will coordinate with a nuttx core team
Large companies (xiaomi, espressif, etc) only push work to their own forks.
Sometimes, they are allowed to publish a consolidated and consistent
patchset of changes they would like to see in upstream
The core upstream team reviews everything, ask questions about wether or
not it's good to have
Some of the patches are accepted, some are rejected
what is needed is NOT NEW TOOLS
what is needed is TIME AND ARCHITECTURE
rushing as fast as possible to a half-baked solution that suits xiaomi
so they can just continue doing what they want is NOT going to help
Yes I know I am naming Xiaomi and you may not like that
But COME ON
Open the commit long on a large tall screen and LOOK AT IT
90% of commits come from one company.
This can not be good.
I am not saying large companies should not contribute.
I am saying large companies must make MORE EFFORTS to NOT BREAK a cool
project.
Not tools. not scripts. not ai. not CI. not unit tests.
Just brain. Thoughts, and time. and global architecture.
Exactly what you dont want to spend.
STOP developing more patches. If xiaomi cant stop, establish a fork so
they can continue.
THINK about it. What is nuttx? What must it become?
Is it a puppet for some companies or a project for a common good of a
large number of partners?
I've been saying the same thing for years now.
Until this is fixed, I am out.
Sebastien
On 1/30/25 06:41, Xiang Xiao wrote:
Ok, let's come up with a solid plan. Xiaomi could sponsor
engineering resources to improve the community automation test quality.
On Thu, Jan 30, 2025 at 12:50 PM Nathan Hartman <hartman.nat...@gmail.com>
wrote:
That's true. So we should:
1. Decide if we want to have a LTS release, and
2. If yes, then we need to determine all the prerequisites. That will
include things like the solid automation tests, and probably other things
3. Once we have defined what is needed, we can track the items in the issue
tracker and start working to accomplish them.
Of course, we can decide that LTS releases are not a good fit for us and
improve the testing anyway.
Cheers,
Nathan
On Wed, Jan 29, 2025 at 11:28 PM Xiang Xiao <xiaoxiang781...@gmail.com>
wrote:
Before we have a solid automation test, how do we declare the release is
good enough to be LTS release?
As I mentioned before, it's impossible to have a stable base or LTS
release
without enough automation test.
On Thu, Jan 30, 2025 at 4:05 AM Nathan Hartman <hartman.nat...@gmail.com
wrote:
On Wed, Jan 29, 2025 at 8:21 AM Alan C. Assis <acas...@gmail.com>
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
The moving target does present a difficulty when trying to develop a
product with NuttX that needs to be maintained and updated over time.
There is a way to solve the moving target problem without limiting the
speed of NuttX development:
LTS Releases.
Normal development can continue at full speed and new releases can be
made every 3 months.
But once in a while, such as every 2 years, we could make a LTS
release. For this release, we would create a branch in the NuttX repo.
After the LTS release is published, only bug fixes and security fixes
can be backported to the LTS branch. We would keep each LTS release
alive for 4 years. That means that in 4 years, we will deprecate the
oldest LTS and publish a new LTS, and we will always have 2 active LTS
lines.
People who need stability can use the LTS line. If they need to add
custom in-tree drivers or boards, they can base their private branch
on the LTS branch.
People who need faster development can work from master and the
regular (non-LTS) releases.
The time frame of 2 years and 4 years isn't set in stone. It's just an
initial suggestion.
Cheers,
Nathan
