[Openembedded-architecture] Yocto Project stable release changes
Adrian Bunk
bunk at stusta.de
Mon Feb 17 22:32:16 UTC 2020
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
More information about the Openembedded-architecture
mailing list