Re: liquidshell in kdereview
Il giorno Sun, 14 Apr 2019 16:43:54 +0200 Martin Koller ha scritto: > The cmake file is the ultimate source for specifying what the > application depends on. Adding this somewhere else will easily get READMEs can be useful for packagers instead of manually watching the output of CMake or reading CMakelists.txt (fine for simpler projects, but not for large ones). -- Luca Beltrame GPG key ID: A29D259B pgpJP4dfjoxjC.pgp Description: Firma digitale OpenPGP
Re: liquidshell in kdereview
On Sonntag, 14. April 2019 12:44:20 CEST Adriaan de Groot wrote: > On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote: > > > # License issues > > > > > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > > > want to add SPDX identifiers, but that would be the icing on the cake. > > > > Where, which and how would I need to add SPDX identifiers ? > > You don't *need* to. Like I said, icing on the cake, which is like .. vanilla > sauce on the apfelstruedel. Makes it complete and wonderful, but it's > acceptable without it. > > SPDX identifiers are machine-readable, standardised, tags in source files > that > help tooling that works with licensing (meta) data. See spdx.org; something > like (off the top of my head, not necessarily the right identifier or format, > etc.) > > // SPDX-Identifier: GPLv2+ > > at the top of C++ source files does the trick. ok, done. > > Where is this documented in KDE guidelines ? > > Here > > https://community.kde.org/Policies/Licensing_Policy > > I don't find anything. > > It's not. should it ? > > > # Compatibility issues > > > > > > Fails to document that NetworkManager and BlueZ are required. > > > > Not sure I understand. > > Would have been nice to have that in the README, is what I mean. I'm not a fan of doing duplicate things. The cmake file is the ultimate source for specifying what the application depends on. Adding this somewhere else will easily get out of sync. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: liquidshell in kdereview
On Saturday, 13 April 2019 14:08:18 CEST Martin Koller wrote: > > # License issues > > > > None, actually. Well done. Consistent use of GPLv3+ everywhere. You might > > want to add SPDX identifiers, but that would be the icing on the cake. > > Where, which and how would I need to add SPDX identifiers ? You don't *need* to. Like I said, icing on the cake, which is like .. vanilla sauce on the apfelstruedel. Makes it complete and wonderful, but it's acceptable without it. SPDX identifiers are machine-readable, standardised, tags in source files that help tooling that works with licensing (meta) data. See spdx.org; something like (off the top of my head, not necessarily the right identifier or format, etc.) // SPDX-Identifier: GPLv2+ at the top of C++ source files does the trick. > Where is this documented in KDE guidelines ? > Here > https://community.kde.org/Policies/Licensing_Policy > I don't find anything. It's not. > > # Source issues > > > > Doesn't report nicely at end of CMake (use FeatureSummary). > > included now Thanks. > > # Compatibility issues > > > > Fails to document that NetworkManager and BlueZ are required. > > Not sure I understand. Would have been nice to have that in the README, is what I mean. > > Uses bash for things that are POSIX shell scripts. > > What do you mean ? You have a shell script (start_liquidshell). It uses no bash features at all. A POSIX system (ok, liquidshell is for Linux only, so this can be argued) has a /bin/sh for shell scripts. > I did this since I remember having read that /bin/sh is not the correct way. Fine by me. [ade] signature.asc Description: This is a digitally signed message part.
Re: liquidshell in kdereview
On Freitag, 12. April 2019 13:07:41 CEST Marco Martin wrote: > On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić wrote: > > Anyhow, while I do find it strange to market a non-feature in the features > > list, I don't have anything against it. > > I have a bit of a problem about putting doesn't use activities as a > feature, because it's a bit confrontational towards other KDE products > (and as you point out, often not 100% true as kactivitymanagerd will > be very probably started anyways) I have removed the mentioning of activities now > That said, i don't have problems of having a competing shell as a KDE > project, choice is usually good. Thanks for your open mind! -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
