From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by mail.openembedded.org (Postfix) with ESMTP id 96A007F2B5 for ; Thu, 7 Nov 2019 10:41:52 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id z16so1513590qkg.7 for ; Thu, 07 Nov 2019 02:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XvHJkKuFHC6O8T3G1aHNPhMnywZvCGD7ikljzvuSGF0=; b=aaGtka+Y1qaN/s9YlBryXRckeFDS2w8YeKB6nT5XjuMW351611j/pr8ZWnTyFrfyGh Jo9GAbYvodaOFLew6+SZPvGubiBPj6wNDlNJuVeZHQ+YVS5mbb+bPpa2IOWmLdNmEKIo 655+BFGIhasC40ny82AmCZEYeGMGa/f+X/ayoNWAPIAz/h6a+x7eVVT5Z8JzGq7rHwzF udeWUVZxVHJTnZgQ8A6U1aD8e9FXY4UUXPCUTXL3ciU6lmYILtgZg8JlhlAAvELYwFis BnA+1xuOF1mhpP6fa2rRRi96klMjlscU3PmcBgMh4K3krfzXy7Sc/CDn47aiDGjw6blu VkFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XvHJkKuFHC6O8T3G1aHNPhMnywZvCGD7ikljzvuSGF0=; b=CgGdUxu5Om2yYLkwluEmmKDP4KdXwOMro+7koz4Jbp+XHp4v4tquW2l0fn2Rt044hJ 6+G52bKLTTAmZ/WHxBG4zFIG+VyLjIbrWB6SQSEbuEOlqHdE43vAWtylvEgV9S1CgR7F pVdTk7ql5RoFgTgcGa1aqt04unMw7oXVQ5CxV3zTBt3zDoGW5HRYHdB5rfy3XpHHbUE3 zHdYEPT2OfvIAP2CI458wHhyuK05LsVZIvc3oyfHAYAM17UGSVFbpDGgybajj1A4QZoN Vav2hAZiCWWdpbw8dwVqueDbwjQGBIjc40YuS1+vSQOO1j8ayBH9nJAjW0R5xcTsvht1 UnHg== X-Gm-Message-State: APjAAAUo6GZLLai/8QKdR4YajhaH9xnpBZGR1fMMSbNIPbDBWhkj9DLB sZGXNAhiN72Itog+gR9bApBuHpFbGN2jo7YX/QSe9w== X-Google-Smtp-Source: APXvYqxjaB/OsFQxfaCubYMVWCaOshi7DXqs34Veyh5sRUQD/AuRvwquHCJSQMVBC4xUOfiEVQKUqiJ0+uw4BWhWsy4= X-Received: by 2002:a05:620a:1247:: with SMTP id a7mr2097255qkl.16.1573123313299; Thu, 07 Nov 2019 02:41:53 -0800 (PST) MIME-Version: 1.0 References: <20190925122349.14872-1-ross.burton@intel.com> <20191106160618.GC2398@hiutale> <20191107075931.GD2398@hiutale> In-Reply-To: <20191107075931.GD2398@hiutale> From: Ryan Harkin Date: Thu, 7 Nov 2019 10:41:42 +0000 Message-ID: To: Mikko.Rapeli@bmw.de Cc: Patches and discussions about the oe-core layer Subject: Re: maintaining sumo (was Re: [PATCH][thud] cve-check: backport rewrite from master) X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 10:41:52 -0000 Content-Type: multipart/alternative; boundary="000000000000470cef0596bf5059" --000000000000470cef0596bf5059 Content-Type: text/plain; charset="UTF-8" On Thu, 7 Nov 2019 at 07:59, 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@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 --000000000000470cef0596bf5059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 7 Nov 2019 at 07:59, <Mikko.Rapeli@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@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 ne= w patch and
> > > send it
> > > to the list, or is there a process for requesting this is ch= erry-
> > > picked
> > > across?
> >
> > I just posted the port of this and all other CVE scan related cha= nges
> > to sumo
> > http://= lists.openembedded.org/pipermail/openembedded-core/2019-November/288817.htm= l
> >

Thanks Mikko! That's a g= reat help, I guess my question was good timing for our mutual interest in S= umo.

> > But the question is valid :)
>
> Support for sumo officially ended. I can see a case that the broken CV= E
> 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 d= o we go?
> Which kinds of patches are acceptable?
>
> Note that sumo (and earlier) doesn't have much of the QA automatio= n
> which we've now built our processes around so we don't get tes= t
> 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<= br> > from what I remember).
>
> Also, the LTS proposal stated we needed someone to handle this work. W= e
> have no such person, even if we do somehow find them, they can't b= e
> expected to cover all the old releases and effectively turn all of the= m
> 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 dra= w
> 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.<= br> > 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 th= at 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 f= urther when the time comes.
=C2=A0

Providing funding for Yocto Project LTS work is possible but a lot harder f= or 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):


eg. it was tri= ggered when=C2=A0Armin's patch was merged yesterday.

This builds Sumo, based on Linaro's OE-RPB distro for NXP W= aRP7 (imx7s-warp). It then runs the build in our LAVA lab (although the boa= rds 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 configuration= s.


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-co= re 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 eve= n 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 se= e
some co-operation here from other users who are stuck with sumo.

-Mikko

<= /div>
--000000000000470cef0596bf5059--