<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 7 Nov 2019 at 07:59, &lt;<a href="mailto:Mikko.Rapeli@bmw.de">Mikko.Rapeli@bmw.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, Nov 06, 2019 at 05:53:27PM +0000, Richard Purdie wrote:<br>
&gt; On Wed, 2019-11-06 at 16:06 +0000, <a href="mailto:Mikko.Rapeli@bmw.de" target="_blank">Mikko.Rapeli@bmw.de</a> wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt; <br>
&gt; &gt; On Wed, Nov 06, 2019 at 02:59:16PM +0000, Ryan Harkin wrote:<br>
&gt; &gt; &gt; Hi Ross/Richard,<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; I&#39;d like this applied to Sumo also. Should I create a new patch and<br>
&gt; &gt; &gt; send it<br>
&gt; &gt; &gt; to the list, or is there a process for requesting this is cherry-<br>
&gt; &gt; &gt; picked<br>
&gt; &gt; &gt; across?<br>
&gt; &gt; <br>
&gt; &gt; I just posted the port of this and all other CVE scan related changes<br>
&gt; &gt; to sumo<br>
&gt; &gt; <a href="http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.html" rel="noreferrer" target="_blank">http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.html</a><br>
&gt; &gt; <br></blockquote><div><br></div><div>Thanks Mikko! That&#39;s a great help, I guess my question was good timing for our mutual interest in Sumo.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; &gt; But the question is valid :)<br>
&gt; <br>
&gt; Support for sumo officially ended. I can see a case that the broken CVE<br>
&gt; tools there are a good reason we could consider merging the patch<br>
&gt; series but we do need to be able to test it to merge it to the main<br>
&gt; branch. If we can&#39;t test, we&#39;re merging blind and the quality the<br>
&gt; project tries to deliver could be compromised.<br>
&gt; <br>
&gt; I have made some tweaks to the autobuilder which bring us closer to<br>
&gt; being able to test sumo using the workers still around from that<br>
&gt; release.<br>
&gt; <br>
&gt; The things that make me nervous are questions like:<br>
&gt; <br>
&gt; Which releases do we &quot;open&quot; for such patches? How far back do we go?<br>
&gt; Which kinds of patches are acceptable?<br>
&gt; <br>
&gt; Note that sumo (and earlier) doesn&#39;t have much of the QA automation<br>
&gt; which we&#39;ve now built our processes around so we don&#39;t get test<br>
&gt; reports.<br>
&gt; <br>
&gt; You mention wanting to change gcc. That means we really do need a full<br>
&gt; retest of it to merge that (which is why it never happened originally<br>
&gt; from what I remember).<br>
&gt; <br>
&gt; Also, the LTS proposal stated we needed someone to handle this work. We<br>
&gt; have no such person, even if we do somehow find them, they can&#39;t be<br>
&gt; expected to cover all the old releases and effectively turn all of them<br>
&gt; into LTS releases. How can we get the funding to try and get some help<br>
&gt; with handling this workload?<br>
&gt; <br>
&gt; I am probably going to try and make a case for sorting the CVE tooling<br>
&gt; on sumo as I agree its bad and we should do something. Where do we draw<br>
&gt; the line though.<br>
&gt; <br>
&gt; Basically, this looks like it could create a lot of extra work without<br>
&gt; helping the core project under-resourcing we currently struggle with.<br>
&gt; You can therefore see why I might be nervous :/.<br>
<br>
All this is understood.<br></blockquote><div><br></div><div>Agreed. It&#39;s an expensive and tricky task.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I need to maintain sumo in a project for a while longer so I can publish that work.<br>
The CVE checker patches are just a start.<br></blockquote><div><br></div><div>Yes, the same is true for me. I need to maintain a Sumo distro until mid-2020, at least. It uses the poky merge branch [1]. My support may extend further when the time comes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Providing funding for Yocto Project LTS work is possible but a lot harder for me to do.<br>
Testing and publishing patches is much easier.<br></blockquote><div><br></div><div>Not sure if it helps, but I have a Jenkins job that tests sumo on a trigger (there is one for Warrior also):</div><div><br></div><div><a href="https://ci.linaro.org/job/warp7-openembedded-sumo/">https://ci.linaro.org/job/warp7-openembedded-sumo/</a></div><div><br></div><div>eg. it was triggered when Armin&#39;s patch was merged yesterday.</div><div><br></div><div><div>This builds Sumo, based on Linaro&#39;s OE-RPB distro for NXP WaRP7 (imx7s-warp). It then runs the build in our LAVA lab (although the boards have gone down recently, they&#39;re normally up). Once the boards are up again, I&#39;ll add ptest to the job, to give it a more thorough workout. I&#39;ll also add the sumo-next branch to the list of build configurations.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Could you clarify Yocto Project side answers to these questions:<br>
<br>
If I continue to publish patches for sumo, can I continue doing so on oe-core mailing list?<br>
<br>
If I continue to collect patches for sumo, can I do so using Yocto Project infrastructure, e.g.<br>
a sumo-contrib-lts or similar branch in poky git tree?<br>
<br>
If I continue to test patches, what would be the patch acceptance criteria and required testing?<br>
I would assume same as stable release rules, but maybe these need to be even stricter, e.g.<br>
only support building on Debian stable, following the LTS proposal. I&#39;m testing in my own project<br>
trees and CI with target HW, and doing world builds on pure poky with qemu target. I could some<br>
kind of ptest execution to plain poky as well.<br>
<br>
Would any testing of patches be possible in Yocto Project infrastructure?<br>
<br>
All of these things I can do also completely outside of Yocto Project, e.g. publish a sumo<br>
git tree on github, and rely only on my own testing. But I&#39;d like to see<br>
some co-operation here from other users who are stuck with sumo.<br>
<br>
-Mikko</blockquote><div><br></div><div>[1] <a href="http://git.yoctoproject.org/git/poky">http://git.yoctoproject.org/git/poky</a> </div></div></div>