Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

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.