Hi Johan Thank you for taking the time to look at the source code, share your own experience with KDE and provide some me with some feedback.
> 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 Good idea. I created myself an account. I’ll start looking into that later this weekend. > 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. Am-I correct in assuming that IRC and Matrix are the same thing? > 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 :) There is a lot to read in there. :) I probably should start with then licensing issues and focus all my energy on that. > 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. Great observation. I just updated the CmakeLists.txt. I don’t know how compliant it is right now but at least it compiles and links. https://github.com/cfrankb/lgck-src/blob/develop/src/lgck-builder/CMakeLists.txt I had issues linking against qtGamePad so I left it out to get a successful build. I suspect it’s because cmake is linking against the system-wide libraries rather than the qt sdk. I looked at the CmakeLists from Keysmith and integrated some directives from there. It helped me solve some of the issues I was experiencing. Are there any other projects in KDE that are similar in dependencies or structure to mine own, that I could use as a base for my own CMakeLists 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. It would be nice if I didn’t have to fix right away. > 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). Good catch. Yikes. 100+ files. I swear that I went through all the folders and manually added GPL3 notices *everywhere* (okay, that was a few years ago). Maybe the files just multiplied since then ;) That string is for a trademark not a copyright. I dunno if that makes a difference. GPL3 was only because of qScintilla but since I removed it, I should be able to go for LGPL now. > 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. Deconstructing a reference project is probably the fastest way to get this going. > 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. :) I agree. There is so much to fix. I could start with just reformatting new code as it gets added. I’m going to write a python script to scan the entire source tree for missing notices and add them automatically. I’ll remove the All Rights Reserved from the Windows version headers. Any other GPL non-conformity that are jarring? >> 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. :) You have more experience with this than I do and I still have so much to learn. :) >> 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. Thank you both. I feel optimistic that 2020 will be a good year ! :) Regards. Frank B. On 8/14/20, Johan Ouwerkerk <jm.ouwerk...@gmail.com> wrote: > 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 >
