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 > > >>>>> > > >
