On 3/18/19 11:03 AM, akuster808 wrote: > > > 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.
Yes, but the API change was documented in the changelog/release announcement. So it was 'known', and could at least be dealt with -- if we have that information as part of the review process of the upgrade. I think we're in agreement, blinding accepting some change is not the right answer. Starting with an assumption and reviewing the facts [hopefully with limited knowledge and resources] can help avoid these types of issues in most cases. --Mark >> >> 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 > _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
