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