<div dir="auto"><div>Hi,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> schrieb am Fr., 27. Dez. 2019, 11:04:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote:<br>
> El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. <br>
Kossebau va escriure:<br>
> > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:<br>
> > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:<br>
> > > > Hi all,<br>
> > > > <br>
> > > > in any case, maybe the discussed points should go to the KF6<br>
> > > > workboard?<br>
> > > > <a href="https://phabricator.kde.org/project/view/310/" rel="noreferrer noreferrer" target="_blank">https://phabricator.kde.org/project/view/310/</a><br>
> > > > <br>
> > > > I indeed believe that consistency in the KF5 world is an important<br>
> > > > feature,<br>
> > > > so Friedrich does have a point here. Other framework additions had to<br>
> > > > adapt<br>
> > > > as well (what comes to my mind is renaming of KQuickCharts or<br>
> > > > KCalendarCore).<br>
> > > <br>
> > > There is one important difference between KCalendarCore/KQuickCharts/etc<br>
> > > and Grantlee/QKeychain/etc though. The former had no previous release<br>
> > > promising a public API and therefore only KDE-internal users. The<br>
> > > latter have such releases and guarantees, and a significant<br>
> > > KDE-external user base. That's what makes me consider a transitional<br>
> > > pragmatic exemption from certain conventions, if we assume it would<br>
> > > help to grow our external user base, and thus the pool of potential<br>
> > > contributors.<br>
> > <br>
> > Having to make exemptions shows a principal design flaw though: if the<br>
> > idea is to pull in more libraries into KF, incl. some with previous<br>
> > releases & thus existing userbase hoping on longer-term stable ABI, the<br>
> > same will also happen in the KF6 series. And even for the currently<br>
> > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years &<br>
> > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4<br>
> > survived) for being just "exemptions". It's rather that the "exemptions"<br>
> > become part of the rules that way.<br>
> Which kind of exceptions are we speaking about?<br>
> <br>
> ABI stability? or?<br>
<br>
The opposite actually :) It's about keeping existing API/ABI of frameworks <br>
with a significant (KDE external) user base when joining KF5, until the next <br>
major release, even if that means making compromises regarding e.g. our naming <br>
conventions.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If you are confident that the usually necessary steps to become an "aligned" framework are going to be done in the kf6 transition, then I believe this is ok.</div><div dir="auto"><br></div><div dir="auto">That's why I mentioned that these steps should be added to the kf6 workboard.</div><div dir="auto"><br></div><div dir="auto">Let's say Grantlee will not make these steps, then it's as simple as moving it out of the kf6 circle again.</div><div dir="auto"><br></div><div dir="auto">As I understand, you see a nice opportunity to make the KDE Frameworks more recognized. I'd say, go for it.</div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Dominik</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>