Re: Inclusive Language changes - design choices
On Fri, 2022-02-18 at 22:56 +0100, Konrad Weihmann wrote:
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 feature or the deadline can move. We believe some flexibility in theThe Yocto TSC has even discussed the idea of slipping the code freeze andAnd even drop the proposed target deadline, just to "make it work"?potentially delaying the LTS release due to this not being fully
deadline might get the feature in.
The changes do not qualify for backporting so they're in the release or they areThe document doesn't even mention that very special case here, asOr asking differently: just imagine this will be implemented forStable and LTS policies and procedures are outlined on the Wiki (specifically,
Just to be clear, I'm not opposing the idea of having that non-technical*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 moreI 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.