Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Donnerstag, 7. November 2019, 16:21:40 CET schrieb Nate Graham:
> On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote:
> > Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:
> >> Quick Charts is a QML module that implements a set of high-performance,
> >> GPU accelerated
> >> charts. Currently the main user of it is a new KSysGuard UI I have been
> >> working on, but
> >> once it is part of Frameworks I also hope to convert several bits of
> >> Plasma to using it.
> > 
> > If there is only one user currently, might it perhaps be a better idea to
> > do some independent releases for a while to get more feedback on the API,
> > before settling to the API freeze by being part of KDE Frameworks? It
> > will be at least a year until KF6 is there to properly fix up any
> > potential API inconveniences which users might find.
> > I would at least recommend to first get some API shaping by real-world
> > exposure.
> 
> Seems like a chicken-egg problem: more exposure would be provided by
> getting it through the review process, no? I can see us porting the
> graphs in KInfoCenter to use this, for example. But since that's
> shipping code, we might not want to do that until it's formally a framework.

If one restricts oneself to use only libraries part of KDE Frameworks, but not 
from the "Extragear" domain, one should reconsider it, this does not make much 
sense as long one also uses non-KDE-party libraries (which also do not follow 
KF rules).

Review process is about passing something from playground into the set of no-
longer-playground repos. Which for libs can be KDE Frameworks domain, but also 
the "Extragear" domain. Both are equally post-review.
And "Extragear" gives the flexibility to do another product version with 
different ABI, once there has been more feedback from more users.
An approach e.g. taken by KUserFeedback. But also compare the concept of Qt 
labs modules.
Having an API mainly done for one user only right now runs a good chance to 
miss the API needs of other potential candidates. Everyone needs a different 
20 % of the API concepts, they say when throwing with numbers ;)

Np chicken-egg problem here. Release-often-and-early should be simply applied 
to KChickCharts as well. But I recommend to do as others and not bind to 
current first ABI for some time to come, like begin of KF6, instead plan for 
some optional ABI-breaking releases in the near future. So be under the rules 
of Extragear, not yet Frameworks.
But people learn best from own mistakes, so feel free to ignore some old 
person's comment-from-experience. ;)
If the API proves to be not perfect and one knows how it would be better, ~12 
months (to KF6) can be very long :P

Cheers
Friedrich