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