On 3/18/19 8:49 AM, Alexander Kanavin wrote: > If you do package version upgrades regularly in master, I’d say that you > eventually learn about whether stable releases can be trusted. I wouldn’t > need to do any research to say that boost shouldn’t be touched but OpenSSL is > fine, and can similarly split the rest of what I maintain.
well openssl broke core and several other layers a few year back and there was an API change do to security issues and it was done in the minor dot release. So even that is not guaranteed never to happen again. > > Alex > >> On 18 Mar 2019, at 16.39, Tom Rini <[email protected]> wrote: >> >>> On Mon, Mar 18, 2019 at 03:32:17PM +0000, Richard Purdie wrote: >>>> On Mon, 2019-03-18 at 10:46 -0400, Tom Rini wrote: >>>>> On Mon, Mar 18, 2019 at 02:01:37PM +0000, Burton, Ross wrote: >>>>> 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. >>> I have no examples, I know nothing of the boost situation other than it >>> likely on balance shouldn't have gone in. >> Lets set aside boost then, as that is drawing attention away from the >> general question. >> >>> My main point was I wanted to re-document the "no upgrades" rule into >>> something which matches modern practises and what I think we as a >>> project need to do. >> I agree with this both in idea and general recommendation (I recall >> seeing what you mentioned from Greg elsewhere possibly and that's >> somewhere on my mind, with my U-Boot hat on). >> >>> In this specific thought experiment, if an upstream has a stable branch >>> which doesn't work for us we should educate them about the issues we >>> experience. Either things improve and we can use it or we can't. We >>> should document the ones we can use. >> Agreed. >> >>> Its likely even an upstream stable branch may screw up at times. In >>> those cases its then a question of judging on how they help recover the >>> situation IMO. >> Agreed. >> >>> What I don't want is people getting burnt once and then making bad >>> decisions based on that one experience. For example, if Armin should >>> now decide that stable branch maintenance is too stressful and go and >>> do something else it would be a loss to the project. I will freely >>> admit there are times when I feel like walking away as maintainer as >>> the bulk of what you get are complaints. I also recognise that is the >>> nature of the system, clearly I enjoy pain or something! :) >> Agreed on all parts. >> >> What I was hoping to ask / discuss is, should we go with "assume >> upstream stable branch works for us unless proven otherwise" OR "assume >> upstream stable branch DOES NOT work for us unless we research first". >> I believe Ross is saying we should do the second thing, and I am saying >> we should do the first thing. >> >> -- >> Tom >> _______________________________________________ >> 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 _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
