[Openembedded-architecture] Stable releases and version upgrades

[Alexander Kanavin]

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 <trini at konsulko.com> 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
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture