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. 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. > 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 -- Denys > On 17.02.22 18:35, Saul Wold wrote: > > > > > >On 2/17/22 04:32, Richard Purdie wrote: > >>On Thu, 2022-02-17 at 10:17 +0000, Richard Purdie via > >>lists.openembedded.org > >>wrote: > >>>On Tue, 2022-02-15 at 12:08 +0000, Richard Purdie via > >>>lists.openembedded.org > >>>wrote: > >>>>In all the above cases there are still the issues that: > >>>> > >>>>1) showing errors doesn't make bitbake exit or stop the build > >>>>2) It won't handle variables from the shell environment. > >>>>This will likely need > >>>>special code in bitbake. > >>>>3) There are probably some variables which are removed and no longer > >>>>used/supported which we should also tell the user about > >>>>(show a message instead > >>>>of a rename?) > >>>>4) The current code doesn't handle overridden variables. > >>>>This is easier to add > >>>>to c) but something for b) should be possible. > >>>> > >>>>I had been wondering about c) above and keeping overhead > >>>>down but I think we'll > >>>>just have to go back to b) and try and work through the > >>>>issues above. I worry > >>>>that stopping the builds on error in particular is going to > >>>>be problematic. I > >>>>felt I should at least share some of the complexities of > >>>>this with people so > >>>>that if it doesn't end up happening, the complexity of the > >>>>issue is at least > >>>>more visible. > >>> > >>>Let me follow up on where things are now at. I worked on the > >>>bitbake level > >>>rename support and we have a patch which resolves some of the > >>>issues above. 2) > >>>is fixed, 4) partially works and may still need tweaking. 1) > >>>was fixed but I > >>>think may have regressed again as the autobuilder didn't stop > >>>builds the way I > >>>expected it to. 3) still isn't done. > >>> > >>>Joshua was able to fix the erroronce/warnonce log > >>>implementation, thanks. > >>> > >>>Thanks to patches from Saul and Scott we have: > >>> > >>>* a conversion script in master-next which converts metadata > >>>to match renames > >>>* patches for bitbake and oe-core to transition to several of > >>>the new names > >>> > >>>I was able to get the changes in master-next to run on the > >>>autobuilder with > >>>unconverted layers being the failure cases. > >>> > >>>The remaining things I'm aware of that need to be done are: > >>> > >>>a) Resolve BB_DISKMON_DIRS in bitbake (last remaining bitbake rename) > >>>b) Add some mechanism to show an error about now unused variables > >>>c) Check builds really stop at parsing if errors are shown > >>>d) Tweak the code for checking if overridden versions of > >>>variables are set > >>>e) bump bitbake version and change the OE-Core minimum version > >>>requirement > >>>f) consider changing the layer compatibility string to match for this > >>>g) Handle ICECC_USER*/ICECC_SYSTEM* changes > >>>h) Do something with the WHITELIST_(ANY LICENSE) variable > >>>i) Scan over OE-Core for whitelist/blacklist variable name > >>>usage in python code > >>>and propose patches for the issues > >>>j) translate the names in the docs (the script should handle that) > >>>k) document the conversion script and write the migration guide entry > >> > >>b), d), e), f), g) are now in master-next but will need > >>debugging and impact > >>other layers. > >> > >Thank RP for all that you have done, I will have a patch to > >master-next for the script shortly. > > > > > >>I think a), c) and h) probably block merging, the remainder can > >>follow post > >>merge for core. > >> > >I will start looking at the WHITELIST_<license> changes and review > >the old emails. > > > >Sau! > > > >>Cheers, > >> > >>Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1471): https://lists.openembedded.org/g/openembedded-architecture/message/1471 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]] -=-=-=-=-=-=-=-=-=-=-=-
