On 10/28/19 5:55 AM, Rich Persaud wrote:
On Oct 28, 2019, at 6:23 AM, Adrian Bunk <b...@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@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
