[Openembedded-architecture] Yocto Project stable release changes

[Adrian Bunk]

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
> 
> As part of this we've included information about how an LTS could work
> and how it fits with other stable releases. At this point this is not a
> commitment to an LTS, its documentation about how the TSC believes one
> should work.
>...
> This does change a few things from how the project currently operates
> but given resources (human and automated), the TSC believes this should
> given the best outcome for supporting the community and ensuring
> project quality given the resources we have.
>...

Thanks a lot for doing this.

Below are some thoughts from me on topics covered in the wiki page.
I am aware that even if there would be agreement with my points
some of them might not be easy to implement.


1. The Yocto focus on point releases is below the standard of other 
   distributions (also for non-LTS stable series)

Having well-tested point releases every 3 or 6 months sounds good at 
first sight. The problem is that most relevant fixes are actually
security fixes. The default setup of other distributions is that
security fixes are installed automatically immediately, and point
releases are mainly a rebuild of installation media with the
already published security fixes included.

I can see why it might be desirable for a hardware vendor to publish
a reference BSP based on a point release, but for actual products
users should be encouraged to follow the latest commits on the
stable branch they are using.

And this branch should be updated frequently, not just before a point 
release.

The additional testing of point releases is appreciated, but the 
observation that it rarely finds serious regressions shows that
the regular review and automated testing as well as aiming at
master first for all changes in stable branches already gives
a good result users can use.


2. Branch change when changing to community maintainance would be bad

This would silently break any automated setup that follows a stable
branch for getting security updates.


3. Release support visibility is important for users

Depending on the development and certification schedule of a project 
there is a time where you have to make the final decision on the 
distribution and release to use.

If I would have to make such a decision today I know that Ubuntu 20.04
will give me 5 years support, but I do not know whether Yocto 3.1 will
have 7 months or 12 months or 2 years or 5 years of upstream support.

And "one major upgrade every 4 years" is a reasonable and predictable
schedule for getting continuous security support for Ubuntu based
products with a long lifetime.

Another benefit of visibility that can be seen on Ubuntu is that 
Ubuntu-based BSPs from hardware vendors are usually also based on the 
Ubuntu LTS releases and skip the non-LTS releases. It is easier to build 
products when the BSP is already based on the release you want to use, 
and the benefits are even larger for users who just use whatever 
distribution came with the reference hardware.[1]


4. It is hard to contribute to a stable series (both LTS and non-LTS)

Apart from submitting patches, it is hard to find ways to contribute to 
stable series when you are not a big company that can afford a huge
contribution.

How could an individual or small company contribute specifically
to something like "5 years security support for Yocto 3.1"?
The 6 digit resource commitment of paying 50% of the time of a qualified 
person is obvious. It is less clear how Yocto would be able to accept 
and use a € 10k contribution.


> Cheers,
> 
> Richard
> (on behalf of the YP TSC)

Thanks for your work
Adrian

[1] In many cases this is not good practice, but it is very common.