Nathan, that's not what I mean.Look at this comment from Alin and discussion below it: https://github.com/apache/nuttx/pull/15789#issuecomment-2648017787
wt., 11 lut 2025 o 21:33 Nathan Hartman <hartman.nat...@gmail.com> napisał(a): > There will be regular releases as well and if I am understanding correctly, > all PRs that are accepted will go to a regular release, and in addition, > those that are important bugfixes or security will be backported to the LTS > release also. So it's not that PRs would be harder to accept, just that > we'll be a bit more careful about which ones will be backported to the > stable, LTS releases. > > On Tue, Feb 11, 2025 at 12:46 PM raiden00pl <raiden0...@gmail.com> wrote: > > > I personally don't care about LTS releases and it seems to me that Nuttx > > doesn't > > have the resources for it. But if there are people willing to work on > this > > this, > > I wish them good luck. What I don't like is the fact that the new PR > > requirements > > for LTS will make life as difficult as possible for contributors. > > Compensating for > > lack of resources by making it harder for contributors is the wrong > > approach. > > > > > > wt., 11 lut 2025 o 15:07 Nathan Hartman <hartman.nat...@gmail.com> > > napisał(a): > > > > > I also think LTS point releases should focus on bugfixes and security > > only, > > > to ensure the maximum stability. > > > > > > Nathan > > > > > > On Tue, Feb 11, 2025 at 8:32 AM Sebastien Lorquet < > sebast...@lorquet.fr> > > > wrote: > > > > > > > Hello, > > > > > > > > I agree. Only bugfixes, criticity threshold to be determined, but new > > > > features seem unnecessary to me. > > > > > > > > Sebastien > > > > > > > > > > > > On 11/02/2025 12:43, Tiago Medicci Serrano wrote: > > > > > Hi, > > > > > > > > > > I would make the scope even more restricted. Considering an LTS > > should > > > be > > > > > 100% compatible with an existing defconfig, it should not add new > > > drivers > > > > > and new HW. I propose it to contain only bugfixes and security > > patches. > > > > > > > > > > Best regards, > > > > > > > > > > Em ter., 11 de fev. de 2025 às 08:27, Alin Jerpelea < > > > jerpe...@gmail.com> > > > > > escreveu: > > > > > > > > > >> I propose that for our first LTS we start with a small scope and > we > > > > >> backport only fixes, new hw and drivers > > > > >> > > > > >> For the future releases we may consider expanding the scope if the > > > > workload > > > > >> permits > > > > >> > > > > >> What do you think ? > > > > >> > > > > >> On Tue, Feb 11, 2025 at 10:55 AM Laczen JMS <laczen...@gmail.com> > > > > wrote: > > > > >> > > > > >>> Hi Alin, > > > > >>> > > > > >>> I also encourage this. I would start by defining what is expected > > > from > > > > a > > > > >>> LTS: > > > > >>> > > > > >>> A LTS release of NuttX is a release that will be maintained and > > > > >>> supported over a longer period of time (1 year). > > > > >>> LTS updates are mainly focused on bugfixes that where discovered > > and > > > > >>> corrected during the support period. > > > > >>> These bugfixes will be backported to the LTS release. > > > > >>> > > > > >>> Should new features and hardware be allowed in a LTS? If so, how > > many > > > > >>> releases should they have been in? > > > > >>> Many users will keep there own defconfig for a certain product, > > > should > > > > >>> they remain valid? If so are Kconfig changes allowed? > > > > >>> > > > > >>> Anyhow thanks for the proposal, > > > > >>> > > > > >>> Jehudi > > > > >>> > > > > >>> Op di 11 feb 2025 om 10:02 schreef Michael Jung < > > > > michael.j...@secore.ly > > > > >>> : > > > > >>>> Hello Alin, > > > > >>>> > > > > >>>> I would love to see this, as it would make maintaining our > product > > > > much > > > > >>>> easier. > > > > >>>> > > > > >>>> Thanks for the proposal. > > > > >>>> > > > > >>>> Michael > > > > >>>> > > > > >>>> On Tue, Feb 11, 2025 at 9:55 AM Alin Jerpelea < > jerpe...@gmail.com > > > > > > > >>> wrote: > > > > >>>>> Hi all, > > > > >>>>> > > > > >>>>> there have been suggestions that we should create LTS releases > > > > >>>>> > > > > >>>>> I propose that we mark every Q1 (match) release as a LTS > release > > > and > > > > >>>>> maintain it for 2 years. this would always ensure a fresh LTS > > > > >>> overlapping > > > > >>>>> the old one and allowing the users to migrate the code to the > new > > > > >>> release. > > > > >>>>> What do you think? > > > > >>>>> > > > > >>>>> Best regards > > > > >>>>> Alin > > > > >>>>> > > > > > > > > > >
