[Openembedded-architecture] Stable releases and version upgrades

[akuster808]

On 3/18/19 12:34 PM, Khem Raj wrote:
>
>
> On Mon, Mar 18, 2019 at 5:49 AM Richard Purdie
> <richard.purdie at linuxfoundation.org
> <mailto:richard.purdie at linuxfoundation.org>> wrote:
>
>     Since we established the stable branch maintenance guidelines for OE-
>     Core the world has changed a little. I'd like to propose we update the
>     guidelines to reflect this changing world and the current best
>     practises.
>
>     Partly this change has been influenced by a discussion I was part of
>     where GregKH talked about the kernel stable branch policies.
>
>     In short, its very very hard to tell the difference between a security
>     issue and a bugfix. You can't easily know whether a NULL pointer
>     dereference is exploitable or not.
>
>     Add to this that OE is not an expert on much of the code we
>     consume, we
>     need the expertise of the upstreams we take code from to know what is
>     important to fix.
>
>     Then add in that there are often security fixes which don't have CVE
>     numbers.
>
>     My proposal is therefore that where an upstream has a stable release
>     mechanism, we should work with that in OE-Core, taking direct stable
>     version upgrades. We've been doing this already for the kernel and
>     recipes like openssl. I'd propose we should be doing this more widely.
>

The last 6 stable branches have been getting package updates:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=krogoth&id=08e0391d9c3d6db4cf2a5531f5bbd7e08119fcfb

and the trend has be growing since Krogoth.

>
> I am on board with such an approach since in RDK we have been doing
> something similar and in some cases more aggressively since backports
> testing also needs equal amount of testing as it needs to do a version
> upgrade

Package update testing should be not be any more aggressive in a stable
branch than master when accepting a package update. 
>
> The key however is testing since upstream release even though declared
> stable would require a bit of more or less system testing level raised
> up a bit then what we do today and I believe with latest auto builder
> changes will let us achieve it


>
> We need a process where a version upgrade can be approved for stable
> upgrade and clearly understood by concerned end users if they are
> interested

I think the first step is to be consistent with sending out stable
branch pull requests.  This gives the community a chance to review and
comment on any package updates included.  The seems the  to have the
lest overhead.  If the community is absent from this review then maybe
something as mentioned above may have to be pursued.

- armin

>
>
>     I appreciate its hard for the stable maintainer to know which
>     upstreams
>     focus on this. I therefore believe we should make a list of recipes
>     where this is acceptable, either in the policy/wiki or through recipe
>     markup or some other mechanism. I don't worry too much about the
>     mechanism, we can figure that out, I do believe we need to change our
>     "no upgrade" rule to be more adaptable.
>
>     To be clear, the "no upgrade" rule does make sense in many cases. If
>     upstream is breaking APIs (without a security cause) that would be a
>     strong indication their definition of stable isn't compatible with
>     ours.
>
>     Recently this issue came to light around some lttng* version upgrades.
>     I do think that particular upstream is in keeping with what we'd
>     need/want from a stable branch.
>
>     Does anyone strongly object to this?
>
>     Cheers,
>
>     Richard
>
>
>
>     _______________________________________________
>     Openembedded-architecture mailing list
>     Openembedded-architecture at lists.openembedded.org
>     <mailto:Openembedded-architecture at lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20190318/79676050/attachment-0001.html>