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. > > >
