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. 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. 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. 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. 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! :) Cheers, Richard _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
