On Fri, 2022-02-18 at 22:56 +0100, Konrad Weihmann wrote:

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?

In simple terms releases are time based or feature based, you do one or the
other. We're leaning towards getting this in as the objective, which means the
timing has to be flexible.

We were in a really bad position with this feature a week ago and I sounded the
alarm on it. Since then, partly through things I've done and partly through help
from several others we're in a much better position.

We're not there yet but I believe the remaining issues to be solvable in a
reasonable timeframe. I do not have a reputation of taking truly premature
changes and I do not intend to develop one now. The project would be in a better
position if this had been done earlier, yes.

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"?

The feature or the deadline can move. We believe some flexibility in the
deadline might get the feature in.

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.

The changes do not qualify for backporting so they're in the release or they are
not.

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

*Any* new feature ends up with a set of patches after release as people start to
use it. I think that has applied to most I can think of. It isn't any reflection
on the work on the feature, more that most people won't use or test anything
until the release. A sensible approach is to realise this and ensure there is a
stable policy which can quickly handle fixes.

If merged in the state it is in right now I rather see loosing even more
core contributors than one would gain

I respectfully disagree, particularly after your comments about issues with
previous features since you clearly haven't given thought to how these things
evolve in open source.

Pretty much every feature you use in the project evolves in this way, only once
people use things do you find and resolve the majority of the issues. I
therefore don't see this as a particularly strong reason not to put this into
the pending release.

I'd also note that this is the feature freeze date, not the final release date.
There are several weeks of testing between freeze and release to allow for
things to be tested and improved and this is unchanged. The fact few people
participate in that bug fixing is a source of frustration to me as it would help
solve the issue you mention above. The sad fact remains, most people won't test
it until the final release.

Cheers,

Richard