On Fri, Aug 14, 2020 at 5:33 PM Carl Schwan <c...@carlschwan.eu> wrote: > > Le vendredi, août 14, 2020 4:44 PM, Francois Blanchette > <cfrankb.2...@gmail.com> a écrit : > > > Hi Carl, > > > > Thank you for your reply. > > > > Yes I meant port it to KDE because it is a qt 5.15 compliant > > application already. > > And yes i want to make LGCK builder a KDE application hosted on KDE > > infrastructure as a first step. I would definitely prefer to > > integrate with KDE plasma but I see this as a secondary step. I'm > > trying to find the path forward which makes most sense. > > > > What would you recommend? > > Hi, > > You will need to find a KDE developer who would like to sponsor your project > and make sure that you get developer access to KDE repositories, help you > import your project to invent.kde.org and make sure the process happens > smoothly :) >
As for the first part you can probably start by creating an account with KDE Identity: https://identity.kde.org/ That way you should be able to log in on invent.kde.org (our Gitlab instance and start migrating your repository later. In the meantime since your project started life outside of KDE there is an Incubator process for getting it onboarded: https://community.kde.org/Incubator Additionally, I suggest that you join IRC and/or Matrix, because it is a more convenient and low-latency communications channel than e-mail to sound out potential contributors and sponsors. It is always a good idea to establish a bit of rapport with the people you'll be working with beforehand. :) The chat is also available in your browser via https://webchat.kde.org Given that your code is focused on games, I guess "KDE games" related channels (if any) will be one good place to start announcing your project, as are the main development channels of course. Then during the incubation process you can start preparing for the KDE Review of your project by fixing issues that will likely be flagged. The entire review process is somewhat documented here: https://community.kde.org/Policies/Application_Lifecycle#kdereview Of course you can already start work beforehand if you know what you need to do :) >From experience (having gone through Keysmith review) a few things stand out: 1) CMakeLists.txt etc. should integrate with KDE conventions. Keysmith got lucky and Friedrich Kossebau fixed most of it for us, but expect to put in some work here given that your project is a lot bigger/more complex and has a 20 year history or thereabouts. :) You will probably want to re-evaluate your meta-tooling (Python generator) here, at least for the CMakeLists.txt files. 2) I18n support. For KDE projects the ki18n framework is expected, including some additional boilerplate shell scripts which are used by translators and/or automated KDE tooling. However there *are* KDE projects (frameworks) using the Qt i18n support with tr() as well, so maybe this will be accepted. One argument in your favour is the relative maturity of your code base here, at least you do have i18n support whereas Keysmith did not when it was submitted for review. 3) Licensing and copyright needs to hold up, be consistent and be acceptable under KDE policy guidelines. This is going to be the main sticking point if any issues crop up because KDE takes the FL aspect of FLOSS seriously. One particular thing is for instance are the strings in version.h of your easydoc tool where there is an "All rights reserved" stanza, which is patently in violation of the GPL which the project source code appears to be licensed under. Similarly nearly all your *.cpp files lack licensing and copyright information (presumably you intended for the header to serve for both, but that cannot work because people can contribute significantly to a header or to a cpp file without touching the other thing). Note that we are in an ongoing transition w.r.t. how licensing is flagged in source files, we are adopting SPDX licensing headers as our preferred format. If you choose to adopt SPDX you can use the REUSE tool to gauge how well you are doing in terms of how well your licensing and copyright information is expressed for automated tools (reus) to make sense of. For licensing the following two links are going to be very important, you will want to study them a bit to see how well your project is doing: * https://community.kde.org/Guidelines_and_HOWTOs/Licensing * https://community.kde.org/Policies/Licensing_Policy 4) I'm not sure how important code style is, but at least for KDE frameworks a code style is defined and you might wish to adopt it to better fit in: https://techbase.kde.org/Policies/Frameworks_Coding_Style Personally I would hold off on reformatting all your code until people really start to complain, and then use it to show yourself to be a good KDE citizen rather than put in all the work up front. Fix up licensing first, I'd say. :) > > Unfortunately, I don't have the time to take care of this process myself, I mostly don't really have the expertise to "judge". For Keysmith we were "lucky" in that the project was started by Bhushan Shah who as a KDE member knew what he was getting into and kept a watchful eye on code contributions for any potential issues. :) > I'm sure someone here will volunteer and help you. Your project looks very > nice and I think it will be a positive addition to KDE and hope that being > part of KDE will also help LGCK Builder. Fully agreed. Regards, - Johan
