<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 3, 2024 at 9:35 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, 4 Nov 2024, 7:54 am Harald Sitter, <<a href="mailto:sitter@kde.org" target="_blank">sitter@kde.org</a>> wrote:</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Ahoy</div></div></div></blockquote><div><br></div><div>Hi all,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>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).<br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>HS<br></div></div></div>