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

Joshua Watt jpewhacker at gmail.com
Mon Oct 28 06:46:36 PDT 2019


On 10/28/19 5:55 AM, Rich Persaud wrote:
> On Oct 28, 2019, at 6:23 AM, Adrian Bunk <bunk at stusta.de> wrote:
>> Hi Rich,
>>
>> most of what you are writing is unfortunately quite far from the actual
>> problems regarding Yocto LTS.
>>
>> Yocto LTS might not happen at all due to a lack of resource commitments.
>>
>> Discussing what additional work could be done for Yocto LTS is
>> therefore not productive, unless you are the one doing this work.
>>
>> If you manage to convince your employer or a customer to make
>> a resource commitment for Yocto LTS, everyone would be extremely
>> grateful since this would help solving the biggest problem.
> As stated at the beginning of the thread, few companies can alone resource the work needed for LTS support, given the complexity of the software supply chain.  As stated in the previous email, Linux Foundation, Google, Microsoft and RedHat today announced their pooled investment of resources into a test project (Kernel CI) with historical resource challenges.
>
> If long-term support for OpenEmbedded is not receiving sufficient resource investment, one question is:  which similar projects *are* receiving investment?  Two examples were provided, one based on OE/Yocto.  Has Yocto asked Microsoft to contribute resources to Yocto LTS?  Another question that can be posed to potential contributors:  what changes to Yocto LTS scope (phase 1 or 2) would enable contribution of pooled resources?
>
> OpenXT uses OpenEmbedded to develop systems with hardware-assisted security properties.  If Yocto LTS can reduce our existing test burden on real hardware, there is potential for collaboration.  Currently-scoped Yocto LTS would not be a good fit for testing security properties, especially if the virtual test hardware is based on Ubuntu instead of OpenEmbedded meta-virtualization + bitbake guarantees for software supply chain integrity.

I understand why this is desirable for a secure supply chain, but on the 
other hand I wonder how this is different from the reference hardware 
platforms that Yocto project already builds? The reference hardware 
platforms certainly don't cover all the hardware that the project can 
run on, but you can easily extended the project to run on whatever 
hardware you desire. Similarly, just because the LTS release is only 
tested on Ubuntu LTS for resource reason (which I personally think is a 
good idea), doesn't mean that you can't also extended the LTS release in 
your own layer to do an OE-on-OE build.

Also, out of curiosity, how close is the build-appliance [1] image to 
what you are looking for? If that's sufficient for your use cases 
(perhaps with some minor tweaks), that is an image that the project 
already supports (and tests) for the OE-on-OE build use case. If that is 
something that is useful, allocating some resources to maintain that 
image in OE-core would be helpful to the project overall.


[1] 
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/build-appliance-image_15.0.0.bb


Thanks,

Joshua Watt

>
> Rich
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


More information about the automated-testing mailing list