[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framewor
From: Dominik Haumann <dhaumann () kde ! org>
Date: 2019-12-27 13:47:52
Message-ID: CALi_srCSwGa+aOqq0UEOHPr8KVwgUdcCeWLVh6oSR-EXXvZ6sQ () mail ! gmail ! com
[Download RAW message or body]
Hi,
Volker Krause <vkrause@kde.org> schrieb am Fr., 27. Dez. 2019, 11:04:
> On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote:
> > 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?
>
> The opposite actually :) It's about keeping existing API/ABI of frameworks
> with a significant (KDE external) user base when joining KF5, until the
> next
> major release, even if that means making compromises regarding e.g. our
> naming
> conventions.
>
If you are confident that the usually necessary steps to become an
"aligned" framework are going to be done in the kf6 transition, then I
believe this is ok.
That's why I mentioned that these steps should be added to the kf6
workboard.
Let's say Grantlee will not make these steps, then it's as simple as moving
it out of the kf6 circle again.
As I understand, you see a nice opportunity to make the KDE Frameworks more
recognized. I'd say, go for it.
Best regards
Dominik
>
[Attachment #3 (text/html)]
<div dir="auto"><div>Hi,<br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Volker Krause <<a \
href="mailto:vkrause@kde.org">vkrause@kde.org</a>> schrieb am Fr., 27. Dez. 2019, \
11:04:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 26 December 2019 \
19:25:09 CET Albert Astals Cid wrote:<br> > El dimarts, 24 de desembre de 2019, a \
les 13:05:23 CET, Friedrich W. H. <br> Kossebau va escriure:<br>
> > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:<br>
> > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:<br>
> > > > Hi all,<br>
> > > > <br>
> > > > in any case, maybe the discussed points should go to the KF6<br>
> > > > workboard?<br>
> > > > <a href="https://phabricator.kde.org/project/view/310/" \
rel="noreferrer noreferrer" \
target="_blank">https://phabricator.kde.org/project/view/310/</a><br> > > > \
> <br> > > > > I indeed believe that consistency in the KF5 world is \
an important<br> > > > > feature,<br>
> > > > so Friedrich does have a point here. Other framework additions \
had to<br> > > > > adapt<br>
> > > > as well (what comes to my mind is renaming of KQuickCharts or<br>
> > > > KCalendarCore).<br>
> > > <br>
> > > There is one important difference between \
KCalendarCore/KQuickCharts/etc<br> > > > and Grantlee/QKeychain/etc though. \
The former had no previous release<br> > > > promising a public API and \
therefore only KDE-internal users. The<br> > > > latter have such releases \
and guarantees, and a significant<br> > > > KDE-external user base. \
That's what makes me consider a transitional<br> > > > pragmatic \
exemption from certain conventions, if we assume it would<br> > > > help to \
grow our external user base, and thus the pool of potential<br> > > > \
contributors.<br> > > <br>
> > Having to make exemptions shows a principal design flaw though: if the<br>
> > idea is to pull in more libraries into KF, incl. some with previous<br>
> > releases & thus existing userbase hoping on longer-term stable ABI, \
the<br> > > same will also happen in the KF6 series. And even for the \
currently<br> > > discussed two libs Grantlee & QKeychain it means at least \
1 1/2 years &<br> > > longer (assuming KF 6.0.0 is coming then, and see how \
long kdelibs4<br> > > survived) for being just "exemptions". It's \
rather that the "exemptions"<br> > > become part of the rules that \
way.<br> > Which kind of exceptions are we speaking about?<br>
> <br>
> ABI stability? or?<br>
<br>
The opposite actually :) It's about keeping existing API/ABI of frameworks <br>
with a significant (KDE external) user base when joining KF5, until the next <br>
major release, even if that means making compromises regarding e.g. our naming <br>
conventions.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If \
you are confident that the usually necessary steps to become an "aligned" \
framework are going to be done in the kf6 transition, then I believe this is \
ok.</div><div dir="auto"><br></div><div dir="auto">That's why I mentioned that \
these steps should be added to the kf6 workboard.</div><div dir="auto"><br></div><div \
dir="auto">Let's say Grantlee will not make these steps, then it's as simple \
as moving it out of the kf6 circle again.</div><div dir="auto"><br></div><div \
dir="auto">As I understand, you see a nice opportunity to make the KDE Frameworks \
more recognized. I'd say, go for it.</div><div dir="auto"><br></div><div \
dir="auto">Best regards</div><div dir="auto">Dominik</div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic