On Sun, Nov 3, 2024 at 9:35 PM Ben Cooksley <bcooks...@kde.org> wrote:
> On Mon, 4 Nov 2024, 7:54 am Harald Sitter, <sit...@kde.org> wrote: > >> Ahoy >> > > Hi all, > > >> >> Currently we have two sets of duplicated metadata one in the ksb format >> and one in yaml. Nico wants to only have one, and I for one agree with >> this. There are also some broader repo-metadata changes coming, not sure >> how much they impact kdesrc-build but the lack of input from the >> kdesrc-build side is concerning at least. So, someone should get involved >> on those (see the issues/MRs on repo-metadata for details). >> > > I can confirm we're looking to make some changes to the general repository > metadata files yes - particularly around removing some keys that don't > quite make sense anymore (like projectpath and repoactive) as needs have > changed and the metadata needs to evolve accordingly. > > My previous plan had been to keep them around for compatibility, however > ideally we could drop them - so it would be nice if someone (who steps up > to update kdesrc-build to use the yaml files that serve as configuration > for kde-builder) could also update kdesrc-build to use the new kind / > lifecycle keys for the metadata at the same time. > Yeah I too was thinking compat is warranted, but realistically we can't keep adding layers of compat rigging, we'll end up with unmaintainable code that nobody can reason through. What I think makes most sense is to deprecate stuff in transitional periods and then throw it away after a set amount of time. Same goes for kde-builder compat for that matter. That way we can keep our code maintainable, allow for growth, and not break things too aggressively. HS
