On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: > 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 aim is to get to a point where changes merge regularly onto the stable branches in a matter of days in a similar way to the way master works (in theory anyway!). I'd also like to see the release process optimised down so that point releases can be tagged and made more regularly. We're making progress, albeit much more slowly than I'd like. The TSC was mindful of this when writing the new process. This is one reason the manual testing is being de-prioritised. > 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. Agreed, and the process should be moving the emphasis onto this. > 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. This I disagree with, quite strongly. When something moves to community support, it means the testing and quality could change. I believe at such a point people need to actively decide whether its for them or not. Changing a branch isn't a big deal, I appreciate people would need to know. > 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] I agree. The process does state LTS has to be chosen in advance. Picking the first one and establishing a maintainer and so on is going to be harder but going forward I hope we can establish such visibility and show clear intent. Practicalities are tough here but we are going to try. > 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. Yocto exists to allow people to pool together and do things together when they might not otherwise have been able to. A single €10k contribution can do so much, if you have 10 of them, you can suddenly do an awful lot more or achieve something you otherwise couldn't! YP does things which need help from people, it also does things which need money. We take very gratefully take whatever contributions we can in whatever form they come in. I know you've written patches and helped with review, both are hugely appreciated. If you have ideas for how we could better accept contributions, or recognise them I'd be interested to understand them. Thanks for the reply btw, I was surprised this email didn't get more comments! Cheers, Richard _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
