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

[Albert Astals Cid]

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