<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 3/18/19 12:34 PM, Khem Raj wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMKF1sok5O=2x2QPUfJzYtP-GCifPRzSGfdWQyiZTD2O=d9Y_A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2019 at 5:49
AM Richard Purdie <<a
href="mailto:richard.purdie@linuxfoundation.org"
moz-do-not-send="true">richard.purdie@linuxfoundation.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Since we
established the stable branch maintenance guidelines for OE-<br>
Core the world has changed a little. I'd like to propose we
update the<br>
guidelines to reflect this changing world and the current
best<br>
practises.<br>
<br>
Partly this change has been influenced by a discussion I was
part of<br>
where GregKH talked about the kernel stable branch policies.<br>
<br>
In short, its very very hard to tell the difference between
a security<br>
issue and a bugfix. You can't easily know whether a NULL
pointer<br>
dereference is exploitable or not.<br>
<br>
Add to this that OE is not an expert on much of the code we
consume, we<br>
need the expertise of the upstreams we take code from to
know what is<br>
important to fix.<br>
<br>
Then add in that there are often security fixes which don't
have CVE<br>
numbers.<br>
<br>
My proposal is therefore that where an upstream has a stable
release<br>
mechanism, we should work with that in OE-Core, taking
direct stable<br>
version upgrades. We've been doing this already for the
kernel and<br>
recipes like openssl. I'd propose we should be doing this
more widely.</blockquote>
</div>
</div>
</blockquote>
<br>
The last 6 stable branches have been getting package updates:<br>
<br>
<a class="moz-txt-link-freetext" href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=krogoth&id=08e0391d9c3d6db4cf2a5531f5bbd7e08119fcfb">http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=krogoth&id=08e0391d9c3d6db4cf2a5531f5bbd7e08119fcfb</a><br>
<br>
and the trend has be growing since Krogoth.<br>
<br>
<blockquote type="cite"
cite="mid:CAMKF1sok5O=2x2QPUfJzYtP-GCifPRzSGfdWQyiZTD2O=d9Y_A@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<div dir="auto">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 <br>
</div>
</div>
</div>
</blockquote>
<br>
Package update testing should be not be any more aggressive in a
stable branch than master when accepting a package update. <br>
<blockquote type="cite"
cite="mid:CAMKF1sok5O=2x2QPUfJzYtP-GCifPRzSGfdWQyiZTD2O=d9Y_A@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<div dir="auto">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</div>
</div>
</div>
</blockquote>
<br>
<br>
<blockquote type="cite"
cite="mid:CAMKF1sok5O=2x2QPUfJzYtP-GCifPRzSGfdWQyiZTD2O=d9Y_A@mail.gmail.com">
<div>
<div class="gmail_quote">
<div dir="auto"><br>
</div>
<div dir="auto">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 <br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
- armin<br>
<br>
<blockquote type="cite"
cite="mid:CAMKF1sok5O=2x2QPUfJzYtP-GCifPRzSGfdWQyiZTD2O=d9Y_A@mail.gmail.com">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
I appreciate its hard for the stable maintainer to know
which upstreams<br>
focus on this. I therefore believe we should make a list of
recipes<br>
where this is acceptable, either in the policy/wiki or
through recipe<br>
markup or some other mechanism. I don't worry too much about
the<br>
mechanism, we can figure that out, I do believe we need to
change our<br>
"no upgrade" rule to be more adaptable.<br>
<br>
To be clear, the "no upgrade" rule does make sense in many
cases. If<br>
upstream is breaking APIs (without a security cause) that
would be a<br>
strong indication their definition of stable isn't
compatible with<br>
ours.<br>
<br>
Recently this issue came to light around some lttng* version
upgrades.<br>
I do think that particular upstream is in keeping with what
we'd<br>
need/want from a stable branch.<br>
<br>
Does anyone strongly object to this?<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
_______________________________________________<br>
Openembedded-architecture mailing list<br>
<a
href="mailto:Openembedded-architecture@lists.openembedded.org"
target="_blank" moz-do-not-send="true">Openembedded-architecture@lists.openembedded.org</a><br>
<a
href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openembedded-architecture mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openembedded-architecture@lists.openembedded.org">Openembedded-architecture@lists.openembedded.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a>
</pre>
</blockquote>
<br>
</body>
</html>