Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
El divendres, 27 de desembre de 2019, a les 11:03:25 CET, Volker Krause va escriure: > On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote: > > El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. > Kossebau va escriure: > > > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause: > > > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote: > > > > > Hi all, > > > > > > > > > > in any case, maybe the discussed points should go to the KF6 > > > > > workboard? > > > > > https://phabricator.kde.org/project/view/310/ > > > > > > > > > > I indeed believe that consistency in the KF5 world is an important > > > > > feature, > > > > > so Friedrich does have a point here. Other framework additions had to > > > > > adapt > > > > > as well (what comes to my mind is renaming of KQuickCharts or > > > > > KCalendarCore). > > > > > > > > There is one important difference between KCalendarCore/KQuickCharts/etc > > > > and Grantlee/QKeychain/etc though. The former had no previous release > > > > promising a public API and therefore only KDE-internal users. The > > > > latter have such releases and guarantees, and a significant > > > > KDE-external user base. That's what makes me consider a transitional > > > > pragmatic exemption from certain conventions, if we assume it would > > > > help to grow our external user base, and thus the pool of potential > > > > contributors. > > > > > > Having to make exemptions shows a principal design flaw though: if the > > > idea is to pull in more libraries into KF, incl. some with previous > > > releases & thus existing userbase hoping on longer-term stable ABI, the > > > same will also happen in the KF6 series. And even for the currently > > > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years & > > > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4 > > > survived) for being just "exemptions". It's rather that the "exemptions" > > > become part of the rules that way. > > Which kind of exceptions are we speaking about? > > > > ABI stability? or? > > The opposite actually :) It's about keeping existing API/ABI of frameworks > with a significant (KDE external) user base when joining KF5, until the next > major release, even if that means making compromises regarding e.g. our > naming > conventions. Can you give an example here of the naming conventions that are being broken? Is this about the ** a) include dirs below subdir KF5/ b) CMake modules with KF5 prefix c) CMake imported target in KF5 namespace ** stuff? We can fix that by simply doing it both ways, no? I.e. doing it the "right KF5 way" but still keeping the old way for a while for compat. Cheers, Albert > > Regards, > Volker >
Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
Hi, Volker Krause schrieb am Fr., 27. Dez. 2019, 11:04: > On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote: > > El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. > Kossebau va escriure: > > > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause: > > > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote: > > > > > Hi all, > > > > > > > > > > in any case, maybe the discussed points should go to the KF6 > > > > > workboard? > > > > > https://phabricator.kde.org/project/view/310/ > > > > > > > > > > I indeed believe that consistency in the KF5 world is an important > > > > > feature, > > > > > so Friedrich does have a point here. Other framework additions had > to > > > > > adapt > > > > > as well (what comes to my mind is renaming of KQuickCharts or > > > > > KCalendarCore). > > > > > > > > There is one important difference between > KCalendarCore/KQuickCharts/etc > > > > and Grantlee/QKeychain/etc though. The former had no previous release > > > > promising a public API and therefore only KDE-internal users. The > > > > latter have such releases and guarantees, and a significant > > > > KDE-external user base. That's what makes me consider a transitional > > > > pragmatic exemption from certain conventions, if we assume it would > > > > help to grow our external user base, and thus the pool of potential > > > > contributors. > > > > > > Having to make exemptions shows a principal design flaw though: if the > > > idea is to pull in more libraries into KF, incl. some with previous > > > releases & thus existing userbase hoping on longer-term stable ABI, the > > > same will also happen in the KF6 series. And even for the currently > > > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years & > > > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4 > > > survived) for being just "exemptions". It's rather that the > "exemptions" > > > become part of the rules that way. > > Which kind of exceptions are we speaking about? > > > > ABI stability? or? > > The opposite actually :) It's about keeping existing API/ABI of frameworks > with a significant (KDE external) user base when joining KF5, until the > next > major release, even if that means making compromises regarding e.g. our > naming > conventions. > 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. That's why I mentioned that these steps should be added to the kf6 workboard. Let's say Grantlee will not make these steps, then it's as simple as moving it out of the kf6 circle again. As I understand, you see a nice opportunity to make the KDE Frameworks more recognized. I'd say, go for it. Best regards Dominik >
Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote: > El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. Kossebau va escriure: > > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause: > > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote: > > > > Hi all, > > > > > > > > in any case, maybe the discussed points should go to the KF6 > > > > workboard? > > > > https://phabricator.kde.org/project/view/310/ > > > > > > > > I indeed believe that consistency in the KF5 world is an important > > > > feature, > > > > so Friedrich does have a point here. Other framework additions had to > > > > adapt > > > > as well (what comes to my mind is renaming of KQuickCharts or > > > > KCalendarCore). > > > > > > There is one important difference between KCalendarCore/KQuickCharts/etc > > > and Grantlee/QKeychain/etc though. The former had no previous release > > > promising a public API and therefore only KDE-internal users. The > > > latter have such releases and guarantees, and a significant > > > KDE-external user base. That's what makes me consider a transitional > > > pragmatic exemption from certain conventions, if we assume it would > > > help to grow our external user base, and thus the pool of potential > > > contributors. > > > > Having to make exemptions shows a principal design flaw though: if the > > idea is to pull in more libraries into KF, incl. some with previous > > releases & thus existing userbase hoping on longer-term stable ABI, the > > same will also happen in the KF6 series. And even for the currently > > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years & > > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4 > > survived) for being just "exemptions". It's rather that the "exemptions" > > become part of the rules that way. > Which kind of exceptions are we speaking about? > > ABI stability? or? The opposite actually :) It's about keeping existing API/ABI of frameworks with a significant (KDE external) user base when joining KF5, until the next major release, even if that means making compromises regarding e.g. our naming conventions. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. Kossebau va escriure: > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause: > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote: > > > Hi all, > > > > > > in any case, maybe the discussed points should go to the KF6 workboard? > > > https://phabricator.kde.org/project/view/310/ > > > > > > I indeed believe that consistency in the KF5 world is an important > > > feature, > > > so Friedrich does have a point here. Other framework additions had to > > > adapt > > > as well (what comes to my mind is renaming of KQuickCharts or > > > KCalendarCore). > > > > There is one important difference between KCalendarCore/KQuickCharts/etc and > > Grantlee/QKeychain/etc though. The former had no previous release promising > > a public API and therefore only KDE-internal users. The latter have such > > releases and guarantees, and a significant KDE-external user base. That's > > what makes me consider a transitional pragmatic exemption from certain > > conventions, if we assume it would help to grow our external user base, and > > thus the pool of potential contributors. > > Having to make exemptions shows a principal design flaw though: if the idea > is > to pull in more libraries into KF, incl. some with previous releases & thus > existing userbase hoping on longer-term stable ABI, the same will also happen > in the KF6 series. And even for the currently discussed two libs Grantlee & > QKeychain it means at least 1 1/2 years & longer (assuming KF 6.0.0 is coming > then, and see how long kdelibs4 survived) for being just "exemptions". > It's rather that the "exemptions" become part of the rules that way. Which kind of exceptions are we speaking about? ABI stability? or? Cheers, Albert > > And this would add exceptions which have to be found out about on a case-by- > case base, as nothing in the individual name suggests which KF modules follow > all KF patterns and which not. Who in some wees remembers which modules are > exceptions and which not? So this makes things also for current KF modules > more complex and thus KF a worse meta-product. > More complex and worse for all of users, support people & contributors. > > Ruining the current consistent rules for some hunt on some bigger numbers of > "external user base" of KF by adding more libraries might result in a net > loss > of users though, as KF would get more confusing and thus less interesting. > I guess at least I am not the only one who prefers simple & thus easy things > to create solutions from :) > > So, IMHO if libraries do not follow KF rules, they should not use the > "KF"/"KDE Frameworks" label. Anything else just blurs the concepts and lowers > the quality of this meta-product. > > My 2 cents as mainly KF user and only casual contributor :) > > Cheers > Friedrich > > PS: And yes, even current KF set of libs has some pattern issues which > confuse > and thus steal time & joy now and then, so ideally would be fixed. > Like KSyntaxHighlighting having a non-pattern repo name "syntax-highlighting" > still, where one expects it to be "ksyntaxhighlighting". > Or modemmanager-qt/networkmanager-qt/bluez-qt being off the KDE naming > pattern, setting them apart a bit, not feeling full kdeframeworkish. > > >
Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause: > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote: > > Hi all, > > > > in any case, maybe the discussed points should go to the KF6 workboard? > > https://phabricator.kde.org/project/view/310/ > > > > I indeed believe that consistency in the KF5 world is an important > > feature, > > so Friedrich does have a point here. Other framework additions had to > > adapt > > as well (what comes to my mind is renaming of KQuickCharts or > > KCalendarCore). > > There is one important difference between KCalendarCore/KQuickCharts/etc and > Grantlee/QKeychain/etc though. The former had no previous release promising > a public API and therefore only KDE-internal users. The latter have such > releases and guarantees, and a significant KDE-external user base. That's > what makes me consider a transitional pragmatic exemption from certain > conventions, if we assume it would help to grow our external user base, and > thus the pool of potential contributors. Having to make exemptions shows a principal design flaw though: if the idea is to pull in more libraries into KF, incl. some with previous releases & thus existing userbase hoping on longer-term stable ABI, the same will also happen in the KF6 series. And even for the currently discussed two libs Grantlee & QKeychain it means at least 1 1/2 years & longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4 survived) for being just "exemptions". It's rather that the "exemptions" become part of the rules that way. And this would add exceptions which have to be found out about on a case-by- case base, as nothing in the individual name suggests which KF modules follow all KF patterns and which not. Who in some wees remembers which modules are exceptions and which not? So this makes things also for current KF modules more complex and thus KF a worse meta-product. More complex and worse for all of users, support people & contributors. Ruining the current consistent rules for some hunt on some bigger numbers of "external user base" of KF by adding more libraries might result in a net loss of users though, as KF would get more confusing and thus less interesting. I guess at least I am not the only one who prefers simple & thus easy things to create solutions from :) So, IMHO if libraries do not follow KF rules, they should not use the "KF"/"KDE Frameworks" label. Anything else just blurs the concepts and lowers the quality of this meta-product. My 2 cents as mainly KF user and only casual contributor :) Cheers Friedrich PS: And yes, even current KF set of libs has some pattern issues which confuse and thus steal time & joy now and then, so ideally would be fixed. Like KSyntaxHighlighting having a non-pattern repo name "syntax-highlighting" still, where one expects it to be "ksyntaxhighlighting". Or modemmanager-qt/networkmanager-qt/bluez-qt being off the KDE naming pattern, setting them apart a bit, not feeling full kdeframeworkish.
