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

[Mikko.Rapeli at bmw.de]

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
> > 
> > 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.

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.

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

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