<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 1:09 AM Rich Persaud <<a href="mailto:persaur@gmail.com">persaur@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><i>(adding the automated-testing list)</i></div><div dir="ltr"><br></div><div dir="ltr">On Oct 24, 2019, at 18:52, Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>> wrote:<div dir="ltr"><blockquote type="cite"><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>I'm posting this to openembedded-architecture since it probably is the</span><br><span>best place for discussions about OE/Yocto planning.</span><br><span></span><br><span>The Yocto Project TSC believes one of the things needed for YP and for</span><br><span>OE is more information being pulled together about how an LTS release</span><br><span>could work. The document linked to below is the information it was able</span><br><span>to collate together on the subject. Its the result of some long</span><br><span>discussions by the TSC.</span><br>...<br><span>The key thing needed to make this happen is a resource commitment to</span><br><span>it. Without such a commitment it is simply not feasible. </span></div></blockquote><div><br></div><div>Vendors who provide commercial support for OE/Yocto-based products may already be investing downstream resources for equivalent "LTS" support. May be useful for the document to show the financial benefits of shifting a percentage of downstream LTS validation resources to upstream Yocto LTS.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I think this will supplement their effort infact since they will have an upstream to send and maintain some of the patches it should help in reducing that burden. At the same time there would be the benefit of other contributions that they can take downstream</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div></div><div><br></div><blockquote type="cite"><div dir="ltr"><span>There may be</span><br><span>new companies willing to join the project in order to make it happen,</span><br><span>if so we should talk further.</span><br><span></span><br><span>The document:</span><br><span></span><br><span><a href="https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/" target="_blank">https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/</a></span><br></div></blockquote><div><br></div><div>> The project components to be covered would need to match those included in our standard release process and should be clearly defined. Those components would be:</div><div><div>> Bitbake</div><div>> OE-Core</div><div>> Meta-yocto</div><div>> yocto-docs</div></div><div>...</div><div>> For simplicity, it is also proposed that only automated testing be used for testing the LTS and that any current manual QA is not performed.</div><div>...</div><div>> Only run virtualized tests</div><div>> Only support one host distro, an Ubuntu LTS as it has right lifespan</div><div><br></div><div>When the first Yocto LTS release is available, could that become the host distro for automated testing? That would provide Yocto automated testing with supply chain integrity benefits from Yocto. If we take that path, with automated testing based on virtualization, could we add meta-virtualization to the list of Yocto LTS release components?</div><div><br></div><div>Yocto-on-Yocto automated testing could reduce risks [1] that impact software supply chains. A potential topic for the ATS event [2] next week.</div><div><br></div><div>Rich</div><div><br></div><div>[1] <a href="https://www.platformsecuritysummit.com/2019/speaker/sherman/" target="_blank">https://www.platformsecuritysummit.com/2019/speaker/sherman/</a></div><div><br></div><div>[2] <a href="https://elinux.org/Automated_Testing_Summit_2019" target="_blank">https://elinux.org/Automated_Testing_Summit_2019</a></div><div><br></div></div></div>_______________________________________________<br>
Openembedded-architecture mailing list<br>
<a href="mailto:Openembedded-architecture@lists.openembedded.org" target="_blank">Openembedded-architecture@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a><br>
</blockquote></div></div>