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.
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
