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
signature.asc
Description: PGP signature
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
