[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] Yocto Project stable release changes
From:       Adrian Bunk <bunk () stusta ! de>
Date:       2020-02-17 23:05:34
Message-ID: 20200217230534.GC6921 () localhost
[Download RAW message or body]

On Mon, Feb 17, 2020 at 05:36:53PM -0500, Denys Dmytriyenko wrote:
> On Tue, Feb 18, 2020 at 12:32:16AM +0200, Adrian Bunk wrote:
> > On Mon, Feb 17, 2020 at 08:18:18AM -0800, akuster808 wrote:
> > > 
> > > 
> > > On 2/17/20 3:52 AM, Adrian Bunk wrote:
> > > > On Wed, Dec 18, 2019 at 11:10:28AM +0000, Richard Purdie wrote:
> > > >> There has been a lot of discussion about stable releases and how the
> > > >> project might handle them going forward. The TSC has put together some
> > > >> process/policy information on the project wiki:
> > > >>
> > > >> https://wiki.yoctoproject.org/wiki/LTS
> > > >> ...
> > > > One more comment on this:
> > > >
> > > > Stable/LTS common properties:
> > > > - Strict "backport only", master first policy
> > > >
> > > > Community status properties:
> > > > - Master first policy recommended
> > > >
> > > >
> > > > Could this be changed to the (recursive) policy
> > > >   When applicable, a change should already be in the
> > > >   next-higher maintained branch.
> > > >
> > > > This would include that changes backported to Yocto 3.1 LTS
> > > > should already be in Yocto 3.2 community maintained.
> > > >
> > > > In practice it should rarely be a problem to apply a backport
> > > > from master to an older release also to all releases in between,
> > > > and all maintained branches are supposed to have a maintainer.
> > > We changed stable to a 6 month   life then is goes to community or EOL.
> > > If it goes to community support then you want this branch to be in line
> > > for backports by someone and have the LTS branch wait?
> > 
> > Basically yes, a valid point is that "already be in the" could be
> > replaced with wording like "accepted in" or at least "submitted to"
> > the the higher branch.
> > 
> > It can easily become a mess if Yocto 3.1 LTS contains fixes not in
> > Yocto 3.2 community maintained, or Yocto 3.0 community maintained
> > contains fixes not in Yocto 3.1 LTS.
> > 
> > We already have that today with fixes submitted for sumo and thud that 
> > are not already in all higher branches.
> 
> That's not out of the ordinary - some fixes are only applicable to older 
> versions. Obviously, a patch needs to explain why it's not applicable to 
> newer versions.

That's why my suggested policy says "When applicable".

> Denys

cu
Adrian
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

[prev in list] [next in list] [prev in thread] [next in thread]