Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)
Albert Astals Cid
aacid at kde.org
Thu Dec 26 18:25:09 GMT 2019
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?
> 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 :)
> 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.
More information about the kde-core-devel