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 [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
