On Mon, Mar 18, 2019 at 02:01:37PM +0000, Burton, Ross wrote: > On Mon, 18 Mar 2019 at 12:49, Richard Purdie > <[email protected]> wrote: > > 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 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. > > I don't really have a strong opinion on the mechanics behind > documenting the behaviour, but how do we decide what upstreams have a > suitable stable release? We don't want to trust every upstream that > says they've a 'stable branch' until they can demonstrate that they > are competent at the job.
I would be inclined to go the other way. If a project says they're doing a stable release mechanism, and then, well, aren't, we should bring that up with the project and see what they mean by stable. Is there an example here? If so, is it boost? And if that's also true, is there a second example? If it's just boost, we could/should note that they don't follow the expected rules. But I would hope the general case is that projects that say they do a stable branch keep it, well, stable. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
