On Mon, Mar 18, 2019 at 5:49 AM Richard Purdie < [email protected]> 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. 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 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 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
