[Automated-testing] [Openembedded-architecture] Yocto Project LTS Proposal/Discussion

[Martin Jansa]

On Mon, Oct 28, 2019 at 03:12:07PM +0300, Petr Nechaev wrote:
> Hello,
> 
>  I am sorry if this is off-topic, I can only speak as a user of yocto.
> But what is the goal of doing half-year releases along with LTS ones
> if we have limited and possibly declining amount of resources ?
>  How many users do really need half-year releases and fast package
> updates --vs-- how many do need LTS and stable ABI? (any data on
> this?)
>      What is the shortest time-to-release for a yocto-based project,
> do they expect 'all' packages to be 'latest' or just a few to be
> 'recent' that they can upgrade themselves?
> 
>  Instead of introducing LTS as a *new* policy, could we just change
> the release model:
> 1. Release once a year (or even every two years).  Less testing - less hassle
> 2. Support every release for 5 years:
>    - 3 years of full support and updates
>         New kernel (recipe) versions are introduced as new optional
> (DEFAULT_PREFERENCE = "-1") recipe files. We test both.  If one wants
> - they can upgrade..
>         Basic ABI like libc or python are never changed.
>         Individual ABIs (say, gui framework upgrades) are up to the
> system designer
>    - 2 years of critical bugfix, community only
> 
> I imagine the overall amount of testing efforts to be less than we have now.

Interesting idea, but I think 2 years is too long with too many changes
when someone is upgrading from one release to another.

In my experience the easiest way to do upgrades between releases is to
regularly test against latest version and adapt the product layers
incrementally every time something in upstream layers breaks them.

That way it's much easier to understand why something got broken (or
bisecting relatively short list of new upstream changes when doing the
testing often enough). It's a bit more work, but also helps upstream
when possible issues are highlighted early enough to test them before
release.

Yes I can do the same with 2 year release cycle in upstream, but
unfortunately this will loose the useful sync points every half year, so
even when we were behind upstream for 2.5 years, I was able to do
product build in 5 different stages along the way for each release
available (even when we weren't going to use the intermediate steps in
the end).

This wouldn't be so important if it's single project, but with many
layers included in bigger builds, each maintained by separate entities,
it's important to get them in sync often enough.

But with LTS available I would save the resources by shortening the
support on release branch, now each release is supported for basically a
year and a bit (thud still actively maintained now when there is warrior
and now zeus available as well). I would cut this support only til the
next version is released (so warrior support would end as soon as zeus
is released) - who needs longer support should use LTS and we would
still have the half years sync points.

Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/automated-testing/attachments/20191028/b60e5e54/attachment-0001.pgp>