[OE-core] maintaining sumo (was Re: [PATCH][thud] cve-check: backport rewrite from master)

Ryan Harkin ryan.harkin at linaro.org
Thu Nov 7 10:41:42 UTC 2019


On Thu, 7 Nov 2019 at 07:59, <Mikko.Rapeli at bmw.de> wrote:

> Hi,
>
> On Wed, Nov 06, 2019 at 05:53:27PM +0000, Richard Purdie wrote:
> > On Wed, 2019-11-06 at 16:06 +0000, Mikko.Rapeli at bmw.de wrote:
> > > Hi,
> > >
> > > On Wed, Nov 06, 2019 at 02:59:16PM +0000, Ryan Harkin wrote:
> > > > Hi Ross/Richard,
> > > >
> > > > I'd like this applied to Sumo also. Should I create a new patch and
> > > > send it
> > > > to the list, or is there a process for requesting this is cherry-
> > > > picked
> > > > across?
> > >
> > > I just posted the port of this and all other CVE scan related changes
> > > to sumo
> > >
> http://lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.html
> > >
>

Thanks Mikko! That's a great help, I guess my question was good timing for
our mutual interest in Sumo.

> > But the question is valid :)
> >
> > Support for sumo officially ended. I can see a case that the broken CVE
> > tools there are a good reason we could consider merging the patch
> > series but we do need to be able to test it to merge it to the main
> > branch. If we can't test, we're merging blind and the quality the
> > project tries to deliver could be compromised.
> >
> > I have made some tweaks to the autobuilder which bring us closer to
> > being able to test sumo using the workers still around from that
> > release.
> >
> > The things that make me nervous are questions like:
> >
> > Which releases do we "open" for such patches? How far back do we go?
> > Which kinds of patches are acceptable?
> >
> > Note that sumo (and earlier) doesn't have much of the QA automation
> > which we've now built our processes around so we don't get test
> > reports.
> >
> > You mention wanting to change gcc. That means we really do need a full
> > retest of it to merge that (which is why it never happened originally
> > from what I remember).
> >
> > Also, the LTS proposal stated we needed someone to handle this work. We
> > have no such person, even if we do somehow find them, they can't be
> > expected to cover all the old releases and effectively turn all of them
> > into LTS releases. How can we get the funding to try and get some help
> > with handling this workload?
> >
> > I am probably going to try and make a case for sorting the CVE tooling
> > on sumo as I agree its bad and we should do something. Where do we draw
> > the line though.
> >
> > Basically, this looks like it could create a lot of extra work without
> > helping the core project under-resourcing we currently struggle with.
> > You can therefore see why I might be nervous :/.
>
> All this is understood.
>

Agreed. It's an expensive and tricky task.


> I need to maintain sumo in a project for a while longer so I can publish
> that work.
> The CVE checker patches are just a start.
>

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.


>
> Providing funding for Yocto Project LTS work is possible but a lot harder
> for me to do.
> Testing and publishing patches is much easier.
>

Not sure if it helps, but I have a Jenkins job that tests sumo on a trigger
(there is one for Warrior also):

https://ci.linaro.org/job/warp7-openembedded-sumo/

eg. it was triggered when Armin's patch was merged yesterday.

This builds Sumo, based on Linaro'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're normally up). Once the boards are up
again, I'll add ptest to the job, to give it a more thorough workout. I'll
also add the sumo-next branch to the list of build configurations.


> Could you clarify Yocto Project side answers to these questions:
>
> If I continue to publish patches for sumo, can I continue doing so on
> oe-core mailing list?
>
> If I continue to collect patches for sumo, can I do so using Yocto Project
> infrastructure, e.g.
> a sumo-contrib-lts or similar branch in poky git tree?
>
> If I continue to test patches, what would be the patch acceptance criteria
> and required testing?
> I would assume same as stable release rules, but maybe these need to be
> even stricter, e.g.
> only support building on Debian stable, following the LTS proposal. I'm
> testing in my own project
> trees and CI with target HW, and doing world builds on pure poky with qemu
> target. I could some
> kind of ptest execution to plain poky as well.
>
> Would any testing of patches be possible in Yocto Project infrastructure?
>
> All of these things I can do also completely outside of Yocto Project,
> e.g. publish a sumo
> git tree on github, and rely only on my own testing. But I'd like to see
> some co-operation here from other users who are stuck with sumo.
>
> -Mikko


[1] http://git.yoctoproject.org/git/poky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191107/5cd2c201/attachment-0001.html>


More information about the Openembedded-core mailing list