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. > - armin cu Adrian _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
