From bunk at stusta.de Sun Feb 2 23:13:02 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 3 Feb 2020 01:13:02 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> Message-ID: <20200202231302.GC6805@localhost> 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. From richard.purdie at linuxfoundation.org Sun Feb 2 23:48:49 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 02 Feb 2020 23:48:49 +0000 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200202231302.GC6805@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> Message-ID: <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> 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 From bunk at stusta.de Mon Feb 3 09:38:55 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 3 Feb 2020 11:38:55 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> Message-ID: <20200203093854.GA9503@localhost> On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: > On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: >... > > 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. Regarding testing, the only documented difference between LTS branches and community branches is "Automated testing is on a best effort basis". Regarding other quality aspects, I do not see why the community branch patch review and merging process has to be different from the normal stable process. > I believe at such a point people need to actively > decide whether its for them or not. I believe this is the same "Do I need security fixes?" question people already had to answer when deciding whether to use a point release or following the stable branch. >... > > 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. It is not obvious which legal entity would do the actual pooling of the money for the intended purpose. Would the Linux Foundation pay a YP LTS maintainer and send invoices for contributions to the salary? What kind of recognition can YP offer to contributors that are not Linux Foundation members? >... > If you have ideas for how we could better accept > contributions, or recognise them I'd be interested to understand them. >... Debian LTS has a setup where the minimal annual contribution is ? 255, and ? 1020 per year gets your company logo on the sponsorship page.[1] The rest is just a standard "get invoice and make SEPA payment". At these financial amounts and level of recognition it is easier to convince a customer or employer that a contribution is beneficial. I would be surprised if anything like this would be easy to setup for YP. > Cheers, > > Richard cu Adrian [1] https://www.freexian.com/services/debian-lts.html From akuster808 at gmail.com Mon Feb 3 15:58:54 2020 From: akuster808 at gmail.com (akuster808) Date: Mon, 3 Feb 2020 07:58:54 -0800 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200203093854.GA9503@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> <20200203093854.GA9503@localhost> Message-ID: <0f413ccf-3716-887c-94d2-182629250b6a@gmail.com> On 2/3/20 1:38 AM, Adrian Bunk wrote: > On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: >> On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: >> ... >>> 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. > Regarding testing, the only documented difference between LTS branches > and community branches is "Automated testing is on a best effort basis". That is the same difference of Stable branches and Community supported. What is not noted is the Build configurations along with Automated Testing it the unknown for Community support. > > Regarding other quality aspects, I do not see why the community branch > patch review and merging process has to be different from the normal > stable process. Stable has to pass builds on the AB and the tests included. Dot releases include a formal QA run. Community is unknown. - Armin >> I believe at such a point people need to actively >> decide whether its for them or not. > I believe this is the same "Do I need security fixes?" question people > already had to answer when deciding whether to use a point release or > following the stable branch. > >> ... >>> 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. > It is not obvious which legal entity would do the actual pooling of the > money for the intended purpose. > Would the Linux Foundation pay a YP LTS maintainer and send invoices > for contributions to the salary? > What kind of recognition can YP offer to contributors that are not > Linux Foundation members? > >> ... >> If you have ideas for how we could better accept >> contributions, or recognise them I'd be interested to understand them. >> ... > Debian LTS has a setup where the minimal annual contribution is ? 255, > and ? 1020 per year gets your company logo on the sponsorship page.[1] > The rest is just a standard "get invoice and make SEPA payment". > > At these financial amounts and level of recognition it is easier to > convince a customer or employer that a contribution is beneficial. > > I would be surprised if anything like this would be easy to setup > for YP. > >> Cheers, >> >> Richard > cu > Adrian > > [1] https://www.freexian.com/services/debian-lts.html > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture From bunk at stusta.de Mon Feb 3 17:23:46 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 3 Feb 2020 19:23:46 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <0f413ccf-3716-887c-94d2-182629250b6a@gmail.com> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> <20200203093854.GA9503@localhost> <0f413ccf-3716-887c-94d2-182629250b6a@gmail.com> Message-ID: <20200203172346.GB19411@localhost> On Mon, Feb 03, 2020 at 07:58:54AM -0800, akuster808 wrote: > On 2/3/20 1:38 AM, Adrian Bunk wrote: > > On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: > >> On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: > >> ... > >>> 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. > > Regarding testing, the only documented difference between LTS branches > > and community branches is "Automated testing is on a best effort basis". > > That is the same difference of Stable branches and Community supported. > What is not noted is the Build configurations along with Automated > Testing it the unknown for Community support. > > Regarding other quality aspects, I do not see why the community branch > > patch review and merging process has to be different from the normal > > stable process. > Stable has to pass builds on the AB and the tests included. Dot releases > include a formal QA run. > > Community is unknown. For community support branches the maintainer is required to publish a test plan. Easiest for everyone would be if stable/LTS/community branches all use the same processes for patches. > - Armin cu Adrian From richard.purdie at linuxfoundation.org Mon Feb 3 17:31:53 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 03 Feb 2020 17:31:53 +0000 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200203172346.GB19411@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> <20200203093854.GA9503@localhost> <0f413ccf-3716-887c-94d2-182629250b6a@gmail.com> <20200203172346.GB19411@localhost> Message-ID: On Mon, 2020-02-03 at 19:23 +0200, Adrian Bunk wrote: > On Mon, Feb 03, 2020 at 07:58:54AM -0800, akuster808 wrote: > > On 2/3/20 1:38 AM, Adrian Bunk wrote: > > > On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: > > > > On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: > > > > ... > > > > > 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. > > > Regarding testing, the only documented difference between LTS > > > branches > > > and community branches is "Automated testing is on a best effort > > > basis". > > > > That is the same difference of Stable branches and Community > > supported. > > What is not noted is the Build configurations along with Automated > > Testing it the unknown for Community support. > > > Regarding other quality aspects, I do not see why the community > > > branch > > > patch review and merging process has to be different from the > > > normal > > > stable process. > > Stable has to pass builds on the AB and the tests included. Dot > > releases > > include a formal QA run. > > > > Community is unknown. > > For community support branches the maintainer is required to publish > a test plan. > > Easiest for everyone would be if stable/LTS/community branches all > use the same processes for patches. The trouble is I very much doubt anyone is going to setup a copy of the autobuilder to test community supported releases. This implies the community branches have to use the autobuilder to run the tests. At that point if we're using all the project resources, we may as well give up on the community level of support and extend the stable release. I'd love to say we can use the autobuilder everywhere for everything but its a finite resource and there are challenges to doing that which we may or may not be able to address... Cheers, Richard From akuster808 at gmail.com Tue Feb 4 00:28:09 2020 From: akuster808 at gmail.com (akuster808) Date: Mon, 3 Feb 2020 16:28:09 -0800 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200203172346.GB19411@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200202231302.GC6805@localhost> <280192980d0c695806c1d400f6d9fa7c583aff50.camel@linuxfoundation.org> <20200203093854.GA9503@localhost> <0f413ccf-3716-887c-94d2-182629250b6a@gmail.com> <20200203172346.GB19411@localhost> Message-ID: On 2/3/20 9:23 AM, Adrian Bunk wrote: > On Mon, Feb 03, 2020 at 07:58:54AM -0800, akuster808 wrote: >> On 2/3/20 1:38 AM, Adrian Bunk wrote: >>> On Sun, Feb 02, 2020 at 11:48:49PM +0000, Richard Purdie wrote: >>>> On Mon, 2020-02-03 at 01:13 +0200, Adrian Bunk wrote: >>>> ... >>>>> 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. >>> Regarding testing, the only documented difference between LTS branches >>> and community branches is "Automated testing is on a best effort basis". >> That is the same difference of Stable branches and Community supported. >> What is not noted is the Build configurations along with Automated >> Testing it the unknown for Community support. >>> Regarding other quality aspects, I do not see why the community branch >>> patch review and merging process has to be different from the normal >>> stable process. >> Stable has to pass builds on the AB and the tests included. Dot releases >> include a formal QA run. >> >> Community is unknown. > For community support branches the maintainer is required to publish a > test plan. More than happy for someone to step up and provide such a document. > > Easiest for everyone would be if stable/LTS/community branches all use > the same processes for patches. The Stable branch scheme has been posted on the mailing list a few years back. Those ideas are now being included in the LTS process to align LTS with Stable and I am trying to document them. We have ideas about Community but its low on the list. - armin > >> - Armin > cu > Adrian From persaur at gmail.com Mon Feb 10 17:10:52 2020 From: persaur at gmail.com (Rich Persaud) Date: Mon, 10 Feb 2020 12:10:52 -0500 Subject: [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig Message-ID: <30A4CC9D-603A-458A-8ACD-EEC71389434A@gmail.com> On Feb 21, 2019, at 18:51, Richard Purdie wrote: > > ?Multiconfig is meant to support this workflow. Unfortunately there are > open bugs and people haven't the time to work on it so its stalled. > That said, the key pieces are already there. > > A picture is worth a thousand words. I thought a demo might interest > people and "prove" this can work. > > To make it work you need four patches: > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b896b2238c100d486e7c43992b49001150749d04 > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e5ef6b008e85f42b5e4ffd72fae7036dd68b2ea5 > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=5d2bd43d14315ef3212e0d09a16446bd74305a2f > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=abdb83576b699448b76293294809aaa04b8e853b > > The first two are fixes from Alejandro which haven't merged as they're > not right. The third patch was me hitting the fixes and bitbake to make > the demo work. That proves they're not right and hints at where we have > some problems in bitbake too. We can get those issues sorted fairly > easily and I'm going to block 2.7 M3 on them. > > The final patch is the interesting one. > > It adds a layer, meta-multiconfig-example layer with a README about how > to configure it. Basically you create two multiconfig configurations, > "musl" and "tiny". > > The demo is to run "bitbake core-image-full-cmdline". > > The result is a core-image-full-cmdline image with a tiny qemux86 image > and a musl based qemux86-64 image installed into /var/lib/machines/ > > The way it does this is creative, having a recipe called image-packer > which creates virtclass variants of itself which depend on the > appropriate multiconfig. It pulls in the images and creates a package > containing them which the bbappend to core-image-full-cmdline can then > install. It'd be very easy to turn this into a list driven piece of > code rather than the two values currently listed. > > Its late here, some of the above code is horrible. I have rushed this > but hopefully it shows this is possible! :) > > I've love to turn this into an oe-selftest, that is my ultimate > intention for this code. > > As things stand today you can't query one multiconfig from another. As > this demo shows, that doesn't need to stop you making interesting > things though. We will do something with such querying eventually to > make things easier but until then, much is still possible. For search engines: the multiconfig demo from this thread is now is an oe-selftest: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/multiconfig.py Are there other public examples of combining artifacts from different machines into a single image via multiconfig? We can include them in a doc update for Dunfell. A list of use cases could motivate more people to try multiconfig. For developer workflows, multiconfig can accelerate multi-image builds (more parallelism) but slow single-package builds (more recipe parsing). As a workaround, BBMULTICONFIG="" restores the speed of building a target for a single MACHINE+DISTRO config. Is there a better way to disable multiconfig for a single bitbake invocation? Bitbake currently requires a MACHINE to be specified for multiconfig builds. It also accepts non-multiconfig target names, even when BBMULTICONFIG is defined. From a usability point of view, this CLI syntax could distinguish the two workflows: standard build: MACHINE=foo bitbake singleconfig-image multiconfig build: bitbake mc::multiconfig-image Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kanavin at gmail.com Tue Feb 11 12:49:27 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 13:49:27 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core Message-ID: Hello, I'd like to lay out a few ideas/thoughts on what should be done with sato (matchbox bits) and X going forward. The inputs are: - Red Hat is the only company doing X maintenance anymore, and they're transitioning it to 'hard maintenance mode' https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ "Once we are done with this [xwayland gaining missing features] we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is. " - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and does not have a Wayland compositor. Yocto project does not have the resources to do the gtk4 port, or add a compositor. - no 'lightweight Wayland compositor with a desktop/launcher experience" has emerged in the open source space; I think the only realistic choice at the moment is the reference compositor Weston which provides a blank desktop with ability to open terminal windows. So the way I think things should be going (seeking opinions/inputs of course): - oe-core adopts Weston as the 'new sato'; all sato images that currently pull in matchbox and friends are changed to be Weston-based. Note that there is no requirement for 3D acceleration; Weston works with plain frame buffer device. However, both options should be supported and tested. Also, support for Xwayland should be tested. - oe-core continues to support and runtime-test X for as long as possible; for this a new image (say, 'core-image-sato-xorg') is created which will provide matchbox under X. However, once upstream bitrot sets in, and pain threshold is exceeded, this will be removed and/or relegated to a legacy layer. Thoughts? Regards, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Tue Feb 11 13:53:23 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 11 Feb 2020 15:53:23 +0200 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: Message-ID: <20200211135323.GA3234@localhost> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote: >... > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and does > not have a Wayland compositor. Yocto project does not have the resources to > do the gtk4 port, or add a compositor. > > - no 'lightweight Wayland compositor with a desktop/launcher experience" > has emerged in the open source space; I think the only realistic choice at > the moment is the reference compositor Weston which provides a blank > desktop with ability to open terminal windows. > > So the way I think things should be going (seeking opinions/inputs of > course): >... > - oe-core continues to support and runtime-test X for as long as possible; > for this a new image (say, 'core-image-sato-xorg') is created which will > provide matchbox under X. However, once upstream bitrot sets in, and pain > threshold is exceeded, this will be removed and/or relegated to a legacy > layer. > > Thoughts? matchbox made sense at a time when you could go into a shop and buy an internet tablet with Linux running on 256 MB flash with 256 MB RAM. Part of the problem is that the only remaining usage of this branch of matchbox development seems to be as example UI for Yocto. For matchbox/sato I am wondering whether replacing it with parts of meta-xfce from meta-openembedded would be a good way forward. Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland support, but at the point where supporting X might become a problem this should be available. Xfce was my first thought as replacement since it appears to be well-maintained in meta-openembedded, no strong opinion whether it is actually the best option. > Regards, > Alex cu Adrian From alex.kanavin at gmail.com Tue Feb 11 13:57:48 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 14:57:48 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: <20200211135323.GA3234@localhost> References: <20200211135323.GA3234@localhost> Message-ID: The question is: what are the use cases for an 'example/reference UI'? Why have one at all at this point? Remember, the core project is severely under-staffed and we need to commit our limited resources wisely. Alex On Tue, 11 Feb 2020 at 14:53, Adrian Bunk wrote: > On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote: > >... > > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and > does > > not have a Wayland compositor. Yocto project does not have the resources > to > > do the gtk4 port, or add a compositor. > > > > - no 'lightweight Wayland compositor with a desktop/launcher experience" > > has emerged in the open source space; I think the only realistic choice > at > > the moment is the reference compositor Weston which provides a blank > > desktop with ability to open terminal windows. > > > > So the way I think things should be going (seeking opinions/inputs of > > course): > >... > > - oe-core continues to support and runtime-test X for as long as > possible; > > for this a new image (say, 'core-image-sato-xorg') is created which will > > provide matchbox under X. However, once upstream bitrot sets in, and pain > > threshold is exceeded, this will be removed and/or relegated to a legacy > > layer. > > > > Thoughts? > > matchbox made sense at a time when you could go into a shop and buy an > internet tablet with Linux running on 256 MB flash with 256 MB RAM. > > Part of the problem is that the only remaining usage of this branch > of matchbox development seems to be as example UI for Yocto. > > For matchbox/sato I am wondering whether replacing it with parts of > meta-xfce from meta-openembedded would be a good way forward. > > Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland > support, but at the point where supporting X might become a problem > this should be available. > > Xfce was my first thought as replacement since it appears to be > well-maintained in meta-openembedded, no strong opinion whether > it is actually the best option. > > > Regards, > > Alex > > cu > Adrian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kanavin at gmail.com Tue Feb 11 14:01:20 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 15:01:20 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> Message-ID: Specifically (sorry for the rapid-followup), I think the main value proposition of core is integration and testing of various language toolchains and core libraries. UIs in embedded space can mean pretty much anything, and so I'd leave that to specialised layers. Alex On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin wrote: > The question is: what are the use cases for an 'example/reference UI'? Why > have one at all at this point? Remember, the core project is severely > under-staffed and we need to commit our limited resources wisely. > > Alex > > On Tue, 11 Feb 2020 at 14:53, Adrian Bunk wrote: > >> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote: >> >... >> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and >> does >> > not have a Wayland compositor. Yocto project does not have the >> resources to >> > do the gtk4 port, or add a compositor. >> > >> > - no 'lightweight Wayland compositor with a desktop/launcher experience" >> > has emerged in the open source space; I think the only realistic choice >> at >> > the moment is the reference compositor Weston which provides a blank >> > desktop with ability to open terminal windows. >> > >> > So the way I think things should be going (seeking opinions/inputs of >> > course): >> >... >> > - oe-core continues to support and runtime-test X for as long as >> possible; >> > for this a new image (say, 'core-image-sato-xorg') is created which will >> > provide matchbox under X. However, once upstream bitrot sets in, and >> pain >> > threshold is exceeded, this will be removed and/or relegated to a legacy >> > layer. >> > >> > Thoughts? >> >> matchbox made sense at a time when you could go into a shop and buy an >> internet tablet with Linux running on 256 MB flash with 256 MB RAM. >> >> Part of the problem is that the only remaining usage of this branch >> of matchbox development seems to be as example UI for Yocto. >> >> For matchbox/sato I am wondering whether replacing it with parts of >> meta-xfce from meta-openembedded would be a good way forward. >> >> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland >> support, but at the point where supporting X might become a problem >> this should be available. >> >> Xfce was my first thought as replacement since it appears to be >> well-maintained in meta-openembedded, no strong opinion whether >> it is actually the best option. >> >> > Regards, >> > Alex >> >> cu >> Adrian >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Tue Feb 11 14:13:47 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 11 Feb 2020 16:13:47 +0200 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> Message-ID: <20200211141347.GB3234@localhost> On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote: > Specifically (sorry for the rapid-followup), I think the main value > proposition of core is integration and testing of various language > toolchains and core libraries. UIs in embedded space can mean pretty much > anything, and so I'd leave that to specialised layers. That's actually quite different from your original email. Your original email raised the problem that X might start to bitrot after the end of support for RHEL 8 in the year 2029 (sic). What functionality should be in core for users/demo/QA/... is not strictly related to X versus Wayland. > Alex cu Adrian From holzmayr at rsi-elektrotechnik.de Tue Feb 11 14:05:00 2020 From: holzmayr at rsi-elektrotechnik.de (Josef Holzmayr) Date: Tue, 11 Feb 2020 14:05:00 +0000 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> Message-ID: <20200211140500.hreujdfmfxuf4omh@jh-mailer> Howdy! On Tue, Feb 11, 2020 at 02:57:48PM +0100, Alexander Kanavin wrote: > The question is: what are the use cases for an 'example/reference UI'? Why > have one at all at this point? Remember, the core project is severely > under-staffed and we need to commit our limited resources wisely. My $.02 are, that while being a good test vehicle to build for us, it is actually giving a wrong impression to newcomers. Like "here is a DE to start off, and you can use this build like your desktop box" which is not at all true. So my votes are on, as long as we have something that *can* do *something* on screen with as little effort as possible, we should go for it. Maintaining a custom thing should be avoided. Greetz > > On Tue, 11 Feb 2020 at 14:53, Adrian Bunk wrote: > > > On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote: > > >... > > > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and > > does > > > not have a Wayland compositor. Yocto project does not have the resources > > to > > > do the gtk4 port, or add a compositor. > > > > > > - no 'lightweight Wayland compositor with a desktop/launcher experience" > > > has emerged in the open source space; I think the only realistic choice > > at > > > the moment is the reference compositor Weston which provides a blank > > > desktop with ability to open terminal windows. > > > > > > So the way I think things should be going (seeking opinions/inputs of > > > course): > > >... > > > - oe-core continues to support and runtime-test X for as long as > > possible; > > > for this a new image (say, 'core-image-sato-xorg') is created which will > > > provide matchbox under X. However, once upstream bitrot sets in, and pain > > > threshold is exceeded, this will be removed and/or relegated to a legacy > > > layer. > > > > > > Thoughts? > > > > matchbox made sense at a time when you could go into a shop and buy an > > internet tablet with Linux running on 256 MB flash with 256 MB RAM. > > > > Part of the problem is that the only remaining usage of this branch > > of matchbox development seems to be as example UI for Yocto. > > > > For matchbox/sato I am wondering whether replacing it with parts of > > meta-xfce from meta-openembedded would be a good way forward. > > > > Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland > > support, but at the point where supporting X might become a problem > > this should be available. > > > > Xfce was my first thought as replacement since it appears to be > > well-maintained in meta-openembedded, no strong opinion whether > > it is actually the best option. > > > > > Regards, > > > Alex > > > > cu > > Adrian > > > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture -- ??????????????? Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ??????????????? Amtsgericht Ingolstadt ? GmbH: HRB 191328 ? KG: HRA 170393 Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _____________________________________________________________ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 From alex.kanavin at gmail.com Tue Feb 11 14:35:03 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 15:35:03 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: <20200211141347.GB3234@localhost> References: <20200211135323.GA3234@localhost> <20200211141347.GB3234@localhost> Message-ID: X might and likely will start to bitrot sooner for those not using RHEL 8 and its very conservative and never changing software stack. I can imagine Red Hat has no interest in supporting it on Fedora going forward for instance, they'll just make Xwayland work, and rip the standalone server and its drivers and libraries out. Oe-core will have X for as long as the burden of fixing build errors and runtime issues with custom patches is not too painful. The point I am trying to make is that I am not convinced oe-core needs a 'real' ui at all, and opinion to the contrary should justify the need. Alex On Tue, 11 Feb 2020 at 15:13, Adrian Bunk wrote: > On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote: > > Specifically (sorry for the rapid-followup), I think the main value > > proposition of core is integration and testing of various language > > toolchains and core libraries. UIs in embedded space can mean pretty much > > anything, and so I'd leave that to specialised layers. > > That's actually quite different from your original email. > > Your original email raised the problem that X might start to bitrot > after the end of support for RHEL 8 in the year 2029 (sic). > > What functionality should be in core for users/demo/QA/... > is not strictly related to X versus Wayland. > > > Alex > > cu > Adrian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Tue Feb 11 15:02:12 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 11 Feb 2020 17:02:12 +0200 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> <20200211141347.GB3234@localhost> Message-ID: <20200211150212.GC3234@localhost> On Tue, Feb 11, 2020 at 03:35:03PM +0100, Alexander Kanavin wrote: > X might and likely will start to bitrot sooner for those not using RHEL 8 > and its very conservative and never changing software stack. I can imagine > Red Hat has no interest in supporting it on Fedora going forward for > instance, they'll just make Xwayland work, and rip the standalone server > and its drivers and libraries out. There are plenty of other users big and small left, and most of the hardware support already moved to the kernel. Stale and stable is not necessarily bad for users, and X will not suddenly stop working. > Oe-core will have X for as long as the burden of fixing build errors and > runtime issues with custom patches is not too painful. If this is true, then let's revisit this topic in 10 years. And the solution would then likely be to switch from matchbox/sato to some desktop environment that supports wayland. > The point I am > trying to make is that I am not convinced oe-core needs a 'real' ui at all, > and opinion to the contrary should justify the need. The point I am trying to make is that this is a different discussion. And any "no UI in oe-core" decision would not have to wait until the point in the distant future when X might no longer be supportable. > Alex cu Adrian From mark.hatle at kernel.crashing.org Tue Feb 11 15:58:21 2020 From: mark.hatle at kernel.crashing.org (Mark Hatle) Date: Tue, 11 Feb 2020 09:58:21 -0600 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> <20200211141347.GB3234@localhost> Message-ID: <8b9de58b-7d65-dc89-69ec-4b5d40667184@kernel.crashing.org> On 2/11/20 8:35 AM, Alexander Kanavin wrote: > X might and likely will start to bitrot sooner for those not using RHEL 8 and > its very conservative and never changing software stack. I can imagine Red Hat > has no interest in supporting it on Fedora going forward for instance, they'll > just make Xwayland work, and rip the standalone server and its drivers and > libraries out.? X is incredibly stable code base. I think as long as there are no major changes, the bitrot will be 'minor'. I'm more worried about security response, especially as it goes longer and longer with only a small set of maintainers of last resort. > Oe-core will have X for as long as the burden of fixing build errors and runtime > issues with custom patches is not too painful. The point I am trying to make is > that I am not convinced oe-core needs a 'real' ui at all, and opinion to the > contrary should justify the need. It's already OE's responsibility to fix build errors and integration run-time issues. When the burden goes beyond our resources, then we need to stop or find a champion who will taker that burden. I think we need to plan for that for all of the components of the system, not just X, but X is a good starting point. I also don't think oe-core itself needs a 'real' UI, and as my previous response said -- we do need something though to test that the graphical framework is working properly. In the past this often comes back to needing a LOT of a UI in order to adequately test all of the components of the system. If wayland/weston has a proper test suite that exercises all of the various parts of and pieces of the systems -- then the need for a UI drops considerably. (but we still have the need for some sort of example/demostration...) --Mark > Alex > > On Tue, 11 Feb 2020 at 15:13, Adrian Bunk > wrote: > > On Tue, Feb 11, 2020 at 03:01:20PM +0100, Alexander Kanavin wrote: > > Specifically (sorry for the rapid-followup), I think the main value > > proposition of core is integration and testing of various language > > toolchains and core libraries. UIs in embedded space can mean pretty much > > anything, and so I'd leave that to specialised layers. > > That's actually quite different from your original email. > > Your original email raised the problem that X might start to bitrot > after the end of support for RHEL 8 in the year 2029 (sic). > > What functionality should be in core for users/demo/QA/... > is not strictly related to X versus Wayland. > > > Alex > > cu > Adrian > > > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > From mark.hatle at kernel.crashing.org Tue Feb 11 15:54:46 2020 From: mark.hatle at kernel.crashing.org (Mark Hatle) Date: Tue, 11 Feb 2020 09:54:46 -0600 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> Message-ID: <4375c8dd-fdad-087d-7ef8-7a845c6ea7da@kernel.crashing.org> On 2/11/20 8:01 AM, Alexander Kanavin wrote: > Specifically (sorry for the rapid-followup), I think the main value proposition > of core is integration and testing of various language toolchains and core > libraries. UIs in embedded space can mean pretty much anything, and so I'd leave > that to specialised layers. > > Alex > > On Tue, 11 Feb 2020 at 14:57, Alexander Kanavin > wrote: > > The question is: what are the use cases for an 'example/reference UI'? Why > have one at all at this point? Remember, the core project is severely > under-staffed and we need to commit our limited resources wisely. I don't think an example/reference UI is useful -- OTHER THEN -- we need a way to test that the framework(s) that are provided are functional. So lets, assume Wayland/Weston combo.. we still need something that can use the mouse, show that the cursor is being drawn properly, clicks are registered, etc etc etc.. I do think that we need to include a graphical framework (X.org, wayland/weston combo, etc..) as well as a basic set of examples that can be used to verify that they are working properly. There is a secondary 'problem' which I see more as a business issue then a technical one, everyone wants to have a way to 'demo the OpenEmbedded'. It's pretty hard to demo a build system, so they like to have a device that boots quickly and goes to something graphical that shows it's "working". --Mark > Alex > > On Tue, 11 Feb 2020 at 14:53, Adrian Bunk > wrote: > > On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote: > >... > > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and > does > > not have a Wayland compositor. Yocto project does not have the > resources to > > do the gtk4 port, or add a compositor. > > > > - no 'lightweight Wayland compositor with a desktop/launcher experience" > > has emerged in the open source space; I think the only realistic choice at > > the moment is the reference compositor Weston which provides a blank > > desktop with ability to open terminal windows. > > > > So the way I think things should be going (seeking opinions/inputs of > > course): > >... > > - oe-core continues to support and runtime-test X for as long as possible; > > for this a new image (say, 'core-image-sato-xorg') is created which will > > provide matchbox under X. However, once upstream bitrot sets in, and pain > > threshold is exceeded, this will be removed and/or relegated to a legacy > > layer. > > > > Thoughts? > > matchbox made sense at a time when you could go into a shop and buy an > internet tablet with Linux running on 256 MB flash with 256 MB RAM. > > Part of the problem is that the only remaining usage of this branch > of matchbox development seems to be as example UI for Yocto. > > For matchbox/sato I am wondering whether replacing it with parts of > meta-xfce from meta-openembedded would be a good way forward. > > Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland > support, but at the point where supporting X might become a problem > this should be available. > > Xfce was my first thought as replacement since it appears to be > well-maintained in meta-openembedded, no strong opinion whether > it is actually the best option. > > > Regards, > > Alex > > cu > Adrian > > > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > From alex.kanavin at gmail.com Tue Feb 11 17:46:19 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 18:46:19 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: <8b9de58b-7d65-dc89-69ec-4b5d40667184@kernel.crashing.org> References: <20200211135323.GA3234@localhost> <20200211141347.GB3234@localhost> <8b9de58b-7d65-dc89-69ec-4b5d40667184@kernel.crashing.org> Message-ID: On Tue, 11 Feb 2020 at 16:58, Mark Hatle wrote: > > I also don't think oe-core itself needs a 'real' UI, and as my previous > response > said -- we do need something though to test that the graphical framework is > working properly. > > In the past this often comes back to needing a LOT of a UI in order to > adequately test all of the components of the system. If wayland/weston > has a > proper test suite that exercises all of the various parts of and pieces of > the > systems -- then the need for a UI drops considerably. > > (but we still have the need for some sort of example/demostration...) > Wayland/weston do have test suites, neither of which we currently use. I don't know how much they exercise all the moving parts, but the tests do exist. As for the demo/examples, I think we have reached the point where we can outsource the eye candy to the Internet and not bother with 'apps'. Specifically, just bundle epiphany/webkit into core-image-weston-demo, and make a nice looking landing page somewhere on yoctoproject.org that links to various HD video sites and WebGL demonstrators. As long as both GL and h.264/whatnot are HW accelerated, this should look and feel fine, even in qemu with virgl and kvm acceleration to a recent x86 CPU family. For what it's worth, with my mbition.io hat on, I do not care in the slightest for X anymore, and wouldn't blink an eye if all of it would disappear from oe-core tomorrow. What I wanted to gauge is whether people still use X for *new* product development, and for what reasons, and how much resistance there is to the idea of switching the default graphical stack in oe-core to weston. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Tue Feb 11 17:53:38 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 11 Feb 2020 17:53:38 +0000 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: Message-ID: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> Hi Alex, Thanks for bringing this up. On Tue, 2020-02-11 at 13:49 +0100, Alexander Kanavin wrote: > I'd like to lay out a few ideas/thoughts on what should be done with > sato (matchbox bits) and X going forward. The inputs are: > > - Red Hat is the only company doing X maintenance anymore, and > they're transitioning it to 'hard maintenance mode' > https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ > "Once we are done with this [xwayland gaining missing features] we > expect X.org to go into hard maintenance mode fairly quickly. The > reality is that X.org is basically maintained by us and thus once we > stop paying attention to it there is unlikely to be any major new > releases coming out and there might even be some bitrot setting in > over time. We will keep an eye on it as we will want to ensure X.org > stays supportable until the end of the RHEL8 lifecycle at a minimum, > but let this be a friendly notice for everyone who rely the work we > do maintaining the Linux graphics stack, get onto Wayland, that is > where the future is. > " X.Org is definitely going to be shrinking market share going forwards. That said its going to take a few years for this to happen, its not going to be gone in 6 or 12 months. I'd hope that it should be a relatively low maintenance burden over the next couple of years as it won't change much, it will mainly be things like gcc changes that will affect it. > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), > and does not have a Wayland compositor. Yocto project does not have > the resources to do the gtk4 port, or add a compositor. Whilst gtk4 will come out, gtk3 will continue for a while yet, it feels like we only just got rid of gtk2+! :) > - no 'lightweight Wayland compositor with a desktop/launcher > experience" has emerged in the open source space; I think the only > realistic choice at the moment is the reference compositor Weston > which provides a blank desktop with ability to open terminal windows. > > So the way I think things should be going (seeking opinions/inputs of > course): > > - oe-core adopts Weston as the 'new sato'; all sato images that > currently pull in matchbox and friends are changed to be Weston- > based. Note that there is no requirement for 3D acceleration; Weston > works with plain frame buffer device. However, both options should be > supported and tested. Also, support for Xwayland should be tested. > > - oe-core continues to support and runtime-test X for as long as > possible; for this a new image (say, 'core-image-sato-xorg') is > created which will provide matchbox under X. However, once upstream > bitrot sets in, and pain threshold is exceeded, this will be removed > and/or relegated to a legacy layer. > > Thoughts? I still strongly believe we need something in core which pulls together all our pieces into a UI where you can test key elements of what we build. If we don't have sato how do we actually test the core or demo it? I think we shouldn't rush into things here. We should ramp up our wayland testing and make the wayland images more useful/comprehensive and then look at moving more of our tests from sato to the wayland images. So in summary, yes, I think we do retarget our testing over time and strengthen when were testing under wayland. I probably don't see that needing to happen quite as quickly as you do though! Cheers, Richard From martin.jansa at gmail.com Tue Feb 11 17:59:57 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Tue, 11 Feb 2020 18:59:57 +0100 Subject: [Openembedded-architecture] [OE-core] Future of sato and X in oe-core In-Reply-To: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> References: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> Message-ID: <20200211175957.mmmyembd5z4bhvwr@jama> On Tue, Feb 11, 2020 at 05:53:38PM +0000, Richard Purdie wrote: > I still strongly believe we need something in core which pulls together > all our pieces into a UI where you can test key elements of what we > build. If we don't have sato how do we actually test the core or demo > it? > > I think we shouldn't rush into things here. We should ramp up our > wayland testing and make the wayland images more useful/comprehensive > and then look at moving more of our tests from sato to the wayland > images. > > So in summary, yes, I think we do retarget our testing over time and > strengthen when were testing under wayland. I probably don't see that > needing to happen quite as quickly as you do though! Agreed, it might be nicer to have x11 separated in some meta-x11 layer and meta-sato in another layer as well, but as long as there is no clear replacement and x11 in oe-core doesn't cause too much work I think that dropping x11 from DISTRO_FEATURES is working quite nicely for people who don't care about x11 at all already. Maybe it would make sense to remove x11 from default DISTRO_FEATURES and/or include opengl+wayland instead? Cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From alex.kanavin at gmail.com Tue Feb 11 18:06:57 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 11 Feb 2020 19:06:57 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> References: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> Message-ID: On Tue, 11 Feb 2020 at 18:53, Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > > I still strongly believe we need something in core which pulls together > all our pieces into a UI where you can test key elements of what we > build. If we don't have sato how do we actually test the core or demo > it? > See my other email I just wrote; I think epiphany/webkit under weston is able to replace sato more or less fully in this aspect, and actually do more when it comes to modern embedded UI use cases which involve video and 3D. > I think we shouldn't rush into things here. We should ramp up our > wayland testing and make the wayland images more useful/comprehensive > and then look at moving more of our tests from sato to the wayland > images. > Certainly no rush here and this transition will proceed carefully and will take years, but then I am famous for mercilessly removing things from oe-core, and X with sato would be the biggest one yet! :) Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Wed Feb 12 11:40:18 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 12 Feb 2020 13:40:18 +0200 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <2a9e05eadae5df35ae1c13be4484fd6d3e8fed19.camel@linuxfoundation.org> Message-ID: <20200212114018.GA4081@localhost> On Tue, Feb 11, 2020 at 07:06:57PM +0100, Alexander Kanavin wrote: > On Tue, 11 Feb 2020 at 18:53, Richard Purdie < > richard.purdie at linuxfoundation.org> wrote: > > > I still strongly believe we need something in core which pulls together > > all our pieces into a UI where you can test key elements of what we > > build. If we don't have sato how do we actually test the core or demo > > it? > > See my other email I just wrote; I think epiphany/webkit under weston is > able to replace sato more or less fully in this aspect, Regarding dependencies and buildtime, epiphany/webkit is the largest part of sato. If you anyways want core to ship all the multimedia libraries and ruby and rust and plenty of other packages, then an additional desktop environment in core would be relatively lightweight. A small core would be headless. > and actually do > more when it comes to modern embedded UI use cases which involve video and > 3D. >... epiphany/webkit is a strange option to support in core for that, moving Qt back into core instead would bring more usage in actual products instead of shipping test/demo-only software. > Alex cu Adrian From alex.kanavin at gmail.com Sun Feb 16 16:38:07 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 16 Feb 2020 17:38:07 +0100 Subject: [Openembedded-architecture] Future of sato and X in oe-core In-Reply-To: References: <20200211135323.GA3234@localhost> <20200211141347.GB3234@localhost> <8b9de58b-7d65-dc89-69ec-4b5d40667184@kernel.crashing.org> Message-ID: On Tue, 11 Feb 2020 at 18:46, Alexander Kanavin wrote: > On Tue, 11 Feb 2020 at 16:58, Mark Hatle > wrote: > >> >> I also don't think oe-core itself needs a 'real' UI, and as my previous >> response >> said -- we do need something though to test that the graphical framework >> is >> working properly. >> >> In the past this often comes back to needing a LOT of a UI in order to >> adequately test all of the components of the system. If wayland/weston >> has a >> proper test suite that exercises all of the various parts of and pieces >> of the >> systems -- then the need for a UI drops considerably. >> >> (but we still have the need for some sort of example/demostration...) >> > > Wayland/weston do have test suites, neither of which we currently use. I > don't know how much they exercise all the moving parts, but the tests do > exist. > I have now ran these tests on my host system to see what they do. Both wayland and weston tests are fast (a few seconds each), and here's the outputs for both. I think once these are packaged as ptests and ran on the AB, all that's left is a reasonable demo UI (which as I said could be simply epiphany with working HW acceleration). libwayland: 1/23 wayland-egl symbols check OK 0.08 s 2/23 cpp-compile-test OK 0.02 s 3/23 scanner-test OK 0.18 s 4/23 array-test OK 0.02 s 5/23 client-test OK 0.01 s 6/23 display-test OK 0.57 s 7/23 connection-test OK 0.17 s 8/23 event-loop-test OK 0.17 s 9/23 fixed-test OK 0.01 s 10/23 interface-test OK 0.01 s 11/23 list-test OK 0.01 s 12/23 map-test OK 0.01 s 13/23 sanity-test OK 4.44 s 14/23 socket-test OK 0.02 s 15/23 queue-test OK 0.02 s 16/23 signal-test OK 0.01 s 17/23 newsignal-test OK 0.01 s 18/23 resources-test OK 0.01 s 19/23 message-test OK 0.01 s 20/23 compositor-introspection-test OK 0.01 s 21/23 protocol-logger-test OK 0.01 s 22/23 headers-test OK 0.00 s 23/23 os-wrappers-test OK 0.02 s weston: 1/26 config-parser OK 0.05 s 2/26 string OK 0.02 s 3/26 vertex-clip OK 0.03 s 4/26 timespec OK 0.05 s 5/26 zuc OK 0.22 s 6/26 bad-buffer OK 0.12 s 7/26 devices OK 2.53 s 8/26 event OK 0.42 s 9/26 keyboard OK 0.23 s 10/26 linux-explicit-synchronization OK 0.63 s 11/26 internal-screenshot OK 0.19 s 12/26 presentation OK 0.19 s 13/26 pointer OK 0.53 s 14/26 roles OK 0.18 s 15/26 subsurface OK 2.08 s 16/26 subsurface-shot OK 0.28 s 17/26 text OK 0.13 s 18/26 touch OK 0.18 s 19/26 viewporter OK 2.03 s 20/26 xwayland OK 0.48 s 21/26 ivi-shell-app FAIL 0.68 s (killed by signal 6 SIGABRT) (needs some image resources in /usr which I didn't install) 22/26 plugin-registry OK 0.04 s 23/26 surface OK 0.04 s 24/26 surface-global OK 0.07 s 25/26 ivi-layout-internal OK 0.14 s 26/26 ivi-layout OK 0.18 s Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Feb 17 11:52:43 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 17 Feb 2020 13:52:43 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> Message-ID: <20200217115243.GA18745@localhost> 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. > Cheers, > > Richard > (on behalf of the YP TSC) cu Adrian From akuster808 at gmail.com Mon Feb 17 16:18:18 2020 From: akuster808 at gmail.com (akuster808) Date: Mon, 17 Feb 2020 08:18:18 -0800 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200217115243.GA18745@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200217115243.GA18745@localhost> Message-ID: 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? - armin > > >> Cheers, >> >> Richard >> (on behalf of the YP TSC) > cu > Adrian > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture From bunk at stusta.de Mon Feb 17 22:32:16 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 18 Feb 2020 00:32:16 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200217115243.GA18745@localhost> Message-ID: <20200217223216.GA6921@localhost> 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 From denis at denix.org Mon Feb 17 22:36:53 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Mon, 17 Feb 2020 17:36:53 -0500 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200217223216.GA6921@localhost> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200217115243.GA18745@localhost> <20200217223216.GA6921@localhost> Message-ID: <20200217223653.GC4735@denix.org> On Tue, Feb 18, 2020 at 12:32:16AM +0200, Adrian Bunk wrote: > 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. That's not out of the ordinary - some fixes are only applicable to older versions. Obviously, a patch needs to explain why it's not applicable to newer versions. -- Denys > > - armin > > cu > Adrian > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture From bunk at stusta.de Mon Feb 17 23:05:34 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 18 Feb 2020 01:05:34 +0200 Subject: [Openembedded-architecture] Yocto Project stable release changes In-Reply-To: <20200217223653.GC4735@denix.org> References: <80deef5eb5952f8fe40e05fd84ad6c4cf91bcd70.camel@linuxfoundation.org> <20200217115243.GA18745@localhost> <20200217223216.GA6921@localhost> <20200217223653.GC4735@denix.org> Message-ID: <20200217230534.GC6921@localhost> On Mon, Feb 17, 2020 at 05:36:53PM -0500, Denys Dmytriyenko wrote: > On Tue, Feb 18, 2020 at 12:32:16AM +0200, Adrian Bunk wrote: > > 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. > > That's not out of the ordinary - some fixes are only applicable to older > versions. Obviously, a patch needs to explain why it's not applicable to > newer versions. That's why my suggested policy says "When applicable". > Denys cu Adrian