On 18.02.22 21:44, Denys Dmytriyenko wrote:
On Fri, Feb 18, 2022 at 08:51:58PM +0100, Konrad Weihmann wrote:
Just out of curiosity: is this all considered to be part of
kirkstone release?
This was originally planned as one of the major "features" for the next LTS
release:
https://lists.openembedded.org/g/openembedded-architecture/topic/85488159
Lately I got the impression that neither the deprecation mechanism
nor the list of potentially variable renamings are fully matured.
https://lists.openembedded.org/g/openembedded-architecture/topic/75821819
https://lists.openembedded.org/g/openembedded-architecture/topic/84043114
https://wiki.yoctoproject.org/wiki/Inclusive_language
https://lists.openembedded.org/g/openembedded-core/topic/88650128
https://lists.openembedded.org/g/openembedded-architecture/topic/88899288
So from my perspective this shouldn't part of a potential LTS
release, even if it's considered a big thing by some.
Not having it in the next LTS will potentially be a huge PR nightmare for
the whole project (and its architect personally) for the next 2-4 years.
So the idea is to have rather something "premature" (intentional in
quotes) in LTS than something that is technical sound and valid?
The Yocto TSC has even discussed the idea of slipping the code freeze and > potentially delaying the LTS release due to this not being fully
ready yet.
And even drop the proposed target deadline, just to "make it work"?
Or asking differently: just imagine this will be implemented for
kirkstone release and after the release there will be additional
findings... what's the take of the project on backporting vs. not
backporting these changes?
Stable and LTS policies and procedures are outlined on the Wiki (specifically,
"Stable/LTS Patch Acceptance Policies" section) and should be followed:
https://wiki.yoctoproject.org/wiki/LTS
The document doesn't even mention that very special case here, as
there's technically speaking no reason for the applying any of the
inclusive language patches on an once released branch - for me this is
neither a bugfix, nor a security issue nor a technical necessity - so my
take would be that none of the patches would be backported in any way.
---
Just to be clear, I'm not opposing the idea of having that non-technical
feature, I just want to avoid of merging/releasing it prematurely (not
to offend anyone, but SBOM feature for instance got a ton of patches
after the release, not making the best impression to the people I talked
to).
If merged in the state it is in right now I rather see loosing even more
core contributors than one would gain
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1474):
https://lists.openembedded.org/g/openembedded-architecture/message/1474
Mute This Topic: https://lists.openembedded.org/mt/89158954/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
