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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1476): https://lists.openembedded.org/g/openembedded-architecture/message/1476 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]] -=-=-=-=-=-=-=-=-=-=-=-
