I like the LTS idea, but I need to vote -1 too!
- We don't have enough staff to even review PRs, let alone create a new
burden to LTS support.
- The current LTS approach is forcing contributors to divide PRs in many
commits, although other projects with LTS are not requiring it.
- First we need to
Before we have a solid test suite to ensure the release achieves some
quality level, the release is just a snapshot of a developing code base
with a very basic verification(nsh+ostest), which quality is far from LTS.
So, I suggest to setup the olid verification suite and automation test farm
before
Hi,
-1. Same arguments: we don't have enough staff to make it at the moment.
Let's focus on automated testing to lower staff workload when reviewing PRs.
Em qua., 26 de fev. de 2025 às 10:36, Alan C. Assis
escreveu:
> I like the LTS idea, but I need to vote -1 too!
>
> - We don't have enough s
Hello,
Same, negative vote *in this state*.
The idea of LTS releases is extremely useful and important but I believe
it needs a little more organization and time.
Let's first implement everything that is being decided in the other vote
first.
Depolyable Automated Hardware testing is also v
I was only skim reading the discussions on LTS, so probably missed
detailed descriptions/conclusion of the LTS proposal. It seems a great
idea but @raiden00pl makes a valid point I think?
This is a vote for 13.0.0 which is an LTS candidate I would imagine.
Once out in the wild, any fixes (not
-1 from me.
1. It's a waste of already limited resources in this project.
2. It makes life harder for contributors, by for example requiring
separation of PRs on arch/boards/doc. Extra work for contributors to
compensate for the project's limited resources is not okay.
3. Regarding the above poi
> we only need separate commits not PR which is a best practice and improves
readability
Lately I've been seeing something completely different on Github...
Separate commits are OK, separate PRs are not.
> We can provide fixes and improve the LTS releases compardd with the
regular
releases which
This vote proposes to start the LTS releases for NuttX RTOS
The proposed LTS release plan is
- 1st release each year is a LTS release (maintained for 1.5 years)
- 6 minor releases for each release
ex: 13.0.0-13.0.6 for our first LTS release
Voting will be open for 72hr.
A minimum of 3 binding +1
On Wed, 26 Feb 2025, 10:32 raiden00pl, wrote:
> -1 from me.
>
> 1. It's a waste of already limited resources in this project.
>
> 2. It makes life harder for contributors, by for example requiring
> separation of PRs on arch/boards/doc. Extra work for contributors to
> compensate for the project'
Hi Tim,
the release process for every release is having 4 weeks of stabilization
ex: for the proposed release
LTS release plan for 13.0.0
*
create the 13.0.0 branch on 1 March
*
back-port the fixes (no enhancements) for 4 weeks
*
create the RC0 release tag on 21 March and start the release
10 matches
Mail list logo
