<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body 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 &lt;richard.purdie@linuxfoundation.org&gt; 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. &nbsp;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><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>https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/</span><br></div></blockquote><div><br></div><div>&gt; 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>&gt; Bitbake</div><div>&gt; OE-Core</div><div>&gt; Meta-yocto</div><div>&gt; yocto-docs</div></div><div>...</div><div>&gt; 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>&gt; Only run virtualized tests</div><div>&gt; 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? &nbsp;That would provide Yocto automated testing with supply chain integrity benefits from Yocto. &nbsp;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]&nbsp;<a href="https://www.platformsecuritysummit.com/2019/speaker/sherman/">https://www.platformsecuritysummit.com/2019/speaker/sherman/</a></div><div><br></div><div>[2]&nbsp;<a href="https://elinux.org/Automated_Testing_Summit_2019">https://elinux.org/Automated_Testing_Summit_2019</a></div><div><br></div></div></body></html>