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. > Whatever decision is made here, imho there should/must be the objective to > get it fixed for KF6. Absolutely. Regards, Volker > Best regards > Dominik > > Friedrich W. H. Kossebau <kosse...@kde.org> schrieb am So., 22. Dez. 2019, > > 00:55: > > Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly: > > > On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote: > > > > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly: > > > >> Great, Grantlee is now available at g...@git.kde.org:grantlee.git. > > > >> > > > >> I've pushed a few commits to make it depend on ECM etc. > > > >> > > > >> Once the review period is finished it can be part of KF5 releases. > > > > > > > > There are quite some things which yet need to be done for now: > > > > to be a true KF module there is a set of policies which needs to be > > > > met, > > > > > > see https://community.kde.org/Frameworks/Policies > > > > > > > > 1) Framework directory structure: > > > > moving stuff into src/, autotests/ & docs/ > > > > > > > > 2) Framework documentation: > > > > current system needs adaption to both online (KApiDox) and > > > > offline (ECMAddQCH) systems > > > > > > Cool, I wonder if there's another multi-library framework for > > > comparison? > > > > With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their > > multiple libs. > > > > With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit > > (not involved there), > > Olivier (cc:ed) should be able to hint you what is possible. > > > > > > Another challenge would be moving into the KF5 namespace for the > > > > library > > > > > > artifacts (at least I would expect/recommend this to happen, for > > > > consistent > > > > user experience) > > > > a) include dirs below subdir KF5/ > > > > b) CMake modules with KF5 prefix > > > > c) CMake imported target in KF5 namespace > > > > > > I don't support changing things like this in the KF5 timeframe. > > > > IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, > > where > > the namespace gives consistent developer experience and product messaging. > > > > Having Grantlee being a special kid, with unregular CMake modules names > > and > > differently namespace imported CMake targets, makes things more complex. > > > > Being consistent is what we so like about Qt, and KF should not stay > > behind, > > no? > > > > Perhaps joining the "Release Service" (formerly known as "KDE > > Applications") > > is a better place then, it also contains a set of libraries already. > > That would serve the purpose of having releases happening regularly. > > > > Cheers > > Friedrich
signature.asc
Description: This is a digitally signed message part.