Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > The example you give shows Plasma depending on Gear, this shouldn't > > happen, so > > I'd argue: let's fix that instead. In my opinion the same goes for Gear depending on Plasma. > > > * We currently don't have a stable branch for Framework and it takes > > > often > > > up to one month for fixes to be deployed. The Framework releases is also > > > not in sync with either Gear nor Plasma while these two modules heavily > > > make use of Framework and contribute to Framework. > > Changing the Frameworks release cadence away from monthly isn't going to > get fixes out any faster - as if you are using distribution packages it > still has to be packaged. > If anything it will make them take longer as the Frameworks release would > end up being every couple of months instead of monthly? (you can always > build Frameworks locally if you need the fixes now) For (non-rolling) distributions that update packages on patch releases but not on minor releases it would make a difference if there where patch releases of Frameworks. Not all distributions can follow and backport important fixes in Frameworks. At worst, users will have to suffer a bug in Frameworks until the next LTS release. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 14:26:45 CEST Sune Vuorela wrote: > It might make sense for plasma and gear to follow the same schedule. But > I really like what we have going with frameworks. > > One issue that leads to the 'frameworks stable, release monthly' was > that sometimes, even often, you need to add a *feature* to a framework > to address a *bug* in an application. > > If you can't relatively quickly start requiring the fixed framework, you > end up working around it in the application and forget fixing it in the > framework. I don't follow. How does a quicker Frameworks release cycle helps with this? Do you want to bump the Frameworks requirement in a patch release of the app to get the fix into the patch release? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Help KDE apps comply with FlatHub's new guidelines
On Donnerstag, 11. April 2024 21:36:06 CEST Paul Brown wrote: > On Thursday 11 April 2024 20:38:19 CEST Andy B wrote: > > I realize this is a bit of a project, would Adam Szopa be available to > > coordinate some of this? > > Added to CC. Let's see what he can tell us. And Ingo? He's the app store > engineer person. Surely this would be in his field of expertise. My contract with the KDE e.V. ended end of March. We consider the infrastructure work mostly done. Now it needs people to make use of the infrastructure to bring more apps to the different app stores. I'm still around in case people need assistance (@mahoutsukai:kde.org). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Join the Goals sprint in Berlin!
On Sonntag, 31. März 2024 21:27:14 CEST Ingo Klöcker wrote: > On Samstag, 30. März 2024 16:01:57 CEST Adam Szopa wrote: > > Hi everyone, > > > > In a couple of weeks (20-24th of April, arrivals on the 19th) there is a > > Goals sprint happening in Berlin. > > > > If you'd like to participate, please add your name on the community wiki > > here: https://community.kde.org/Sprints/Goals/2024 > > > > There you can also find some more details as well. The exact location is > > still being confirmed, but nevertheless if you're interested in meeting > > fellow KDE community members and work on the KDE goals please consider > > joining. > > It would be good to know the location because Berlin is huge and I wouldn't > want to book an accommodation too far away from the location. Looks like the location is finally confirmed. Just saw this by accident on https://community.kde.org/Sprints/Goals/2024#Location : The Sprint will be hosted at MBition HQ: Dovestrasse 1, 10587 Berlin. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Join the Goals sprint in Berlin!
On Samstag, 30. März 2024 16:01:57 CEST Adam Szopa wrote: > Hi everyone, > > In a couple of weeks (20-24th of April, arrivals on the 19th) there is a > Goals sprint happening in Berlin. > > If you'd like to participate, please add your name on the community wiki > here: https://community.kde.org/Sprints/Goals/2024 > > There you can also find some more details as well. The exact location is > still being confirmed, but nevertheless if you're interested in meeting > fellow KDE community members and work on the KDE goals please consider > joining. It would be good to know the location because Berlin is huge and I wouldn't want to book an accommodation too far away from the location. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Why (some) KDE software are not available in Android stores?
On Mittwoch, 10. Januar 2024 19:12:03 CET Volker Krause wrote: > On Mittwoch, 10. Januar 2024 15:44:27 CET Ingo Klöcker wrote: > > No. Wait. For new apps there's also a technical reason. For new apps > > Google > > Play requires application bundles (AAB) instead of APKs. We can build AAB > > (at least for Qt 5) on invent, but we cannot sign them yet. Shouldn't be > > to > > hard to add given that it's mostly identical to APK signing. I'm going to > > work on this once signing of Windows binaries is done. > > Related to that: we probably want to use a new key for the AAB signing, as > we have to hand that one out to Google when publishing AABs to their store > AFAIU? Yes, we have to hand the signing key(s) to Google. We should follow Google's advice and use separate signing keys for all new applications. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Why (some) KDE software are not available in Android stores?
On Mittwoch, 10. Januar 2024 15:22:50 CET Filipe Saraiva wrote: > Just a doubt, KDE has several interesting mobile software which support > Android but they are not available in Android stores, like Neochat, > Tokodon, Alligator, Kasts, etc. Those apps are available in our F-Droid "stores": https://community.kde.org/Android/F-Droid But I guess you mean the Google store (and maybe other proprietary Android stores). > Why? Is that some technical reason related to our stack, person-power > hour to work in provide these releases, or other thing? The lack of person-power is the most important reason. The technical process is pretty straightforward nowadays, but someone needs to check if the apps comply with the store policies. No. Wait. For new apps there's also a technical reason. For new apps Google Play requires application bundles (AAB) instead of APKs. We can build AAB (at least for Qt 5) on invent, but we cannot sign them yet. Shouldn't be to hard to add given that it's mostly identical to APK signing. I'm going to work on this once signing of Windows binaries is done. People could start preparing the publication of more KDE apps on Google Play by completing all the administrative tasks. Then we can immediately start publishing those apps when the first signed AABs are packaged. Maybe shortly after the February 2024 MegaRelease. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [discussion] archiving and retiring the Dot
On Dienstag, 3. Oktober 2023 08:53:24 CEST Sune Vuorela wrote: > On 2023-10-02, Joseph P. De Veaugh-Geiss wrote: > > In this context, a radical idea came up: perhaps we can archive and > > retire the Dot altogether. > > I'd like to come up with an alternative proposal: > > Make the dot more used: > - Make it easier to submit articles there > - Retire all project blogs in favour of the dot > - Make planet only for personal blogs - Make planet only for personal blogs about KDE related things. > And that would also leave better room for posts I would love to see on > the planet by KDE contributors: > "I taught my 5-year old to control a plane" > "I reordered my bookshelf by height. This is why" > "I tried vegetarian cooking; this recipe is amazing" > "Please remember to vote in the upcoming election in my home country" I wouldn't want to see any of this on Planet KDE. I'd be on Facebook, Insta, X, whatever, if I was interested in such content. Citing https://invent.kde.org/websites/planet-kde-org/-/blob/master/README.md "Blog content should be mostly KDE themed and not liable to offend. If you have a general blog you may want to set up a tag and subscribe the feed for that tag only to Planet KDE." I fully subscribe to this. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Handling licences for generated files
On Samstag, 9. September 2023 14:58:39 CEST Johnny Jazeix wrote:
> Hi,
>
> for the new project to translate subtitles for KDE videos, we generate
> subtitles files (srt files) from po files.
>
> To generate the translated file, we use the original srt file (which
> is under the licence/copyright of the creator choose) and the po files
> written by the translators (some po files have licence and/or
> copyright, other none of it).
>
> For the generated file, is there a constraint of licence/copyright due
> to how we create them (and from which data)?
>
> Or could I simply consider all the generated files as CC-BY-SA-4.0
> with a generic copyright ("2023 This_file_is_part_of_KDE" for
> example)?
I'd say this depends on the license of the original. The translated files could
be considered derivative works of the original files. Which means they inherit
the license of the original files. And the copyright. Additionally, they get
the copyright of the translators. Just look at how copyright works for
translated literature.
If the original subtitles were automatically transcribed by some (AI) tool,
then they are most likely not copyrightable. Not even if a human being did
some error correction.
I'm not a lawyer. So, that's just my layman understanding of copyright.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Mittwoch, 23. August 2023 17:16:16 CEST Niccolò Ve wrote: > On Wed, Aug 23, 2023, 5:04 PM Ingo Klöcker wrote: > > On Mittwoch, 23. August 2023 16:55:25 CEST Niccolò Ve wrote: > > > > Postponing the deadline is not ideal, since there always will be > > > > people > > > > jumping out saying "Why wasn't I told" "Was it discussed before" again > > > > and again. > > > > > > Please note that the community was never told about this decision before > > > yesterday, and it was never discussed publicly. > > > > https://mail.kde.org/pipermail/kde-community/2023q2/007656.html > > Please read the link and the following emails. It's pretty clear that it's > not an announcement nor a request for discussion. To save others from having to click the link. The Subject of the linked message that was sent by Paul on 12 June 2023 reads "Telegram <-> Matrix bridges will be removed in September" I fail to understand how this is supposed to support your claim that "the community was never told about this decision before yesterday" because clearly Paul made the decision public more than 2 months ago with the linked message. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Mittwoch, 23. August 2023 16:55:25 CEST Niccolò Ve wrote: > > Postponing the deadline is not ideal, since there always will be people > > jumping out saying "Why wasn't I told" "Was it discussed before" again > > and again. > > Please note that the community was never told about this decision before > yesterday, and it was never discussed publicly. https://mail.kde.org/pipermail/kde-community/2023q2/007656.html signature.asc Description: This is a digitally signed message part.
Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos
On Mittwoch, 23. August 2023 09:34:04 CEST Tomaz Canabrava wrote: > (On top of what Paul said, if this happens, should we also stop with the > Reddit and Facebook management, since it’s a closed source software on for > profit companies?) The Telegram bridging is shut down because of unmanageable technical problems and not for political reasons. If it ran smoothly, then I don't think it would be shut down. Don't read more into this than there is. In particular, this isn't a conspiracy against Telegram users. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: using gitlab ultimate
On Mittwoch, 2. August 2023 15:55:44 CEST Harald Sitter wrote: > On Wed, Aug 2, 2023 at 3:48 PM Sune Vuorela wrote: > > On 2023-08-02, Harald Sitter wrote: > > > I don't think so > > > > As such, I have a hard time seeing that these mentioned features is > > important enough to give in on what I feel are our principles of a > > organization doing free software. > > > > I have a hard time finding any featureset where it would be important > > enough. > > It is my understanding that non-trivial amounts of time have been > spent on making a CI dashboard that now nobody uses because it is > defunct or some such. In essence we've wasted valuable free software > time. That seems a pretty compelling reason in my book. No, it's a pretty compelling reason to convince the GitLab folks to make their dashboard available to everyone. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Volunteers - Akademy 2023
On Donnerstag, 22. Juni 2023 14:11:01 CEST Ben Bonacci wrote: > Hi Dina, > > What are the timezones for the volunteer slots listed on the wiki page? Eastern Europe Summer Time (EEST), i.e. UTC+03:00. Regards, Ingo > On 22/6/23 21:27, Dina Nouskali wrote: > > Hello, > > > > Would you like to help us make Akademy 2023 happen? > > > > Feel free to apply to be an online or in person volunteer for Akademy > > 2023 here:https://community.kde.org/Akademy/2023#Be_a_volunteer > > > > Please make sure that you have already registered to attend Akademy: > > https://akademy.kde.org/2023/register/ > > > > Best > > Dina signature.asc Description: This is a digitally signed message part.
Re: planet forwarding to discuss?
On Mittwoch, 21. Juni 2023 16:09:48 CEST Friedrich W. H. Kossebau wrote: > Am Mittwoch, 21. Juni 2023, 15:02:31 CEST schrieb Jonathan Riddell: > > The downside is splitting where discussion happens but it's not a big ask > > to expect KDE devs to visit Discuss at times. > > Being a developer, I think it is ;) I agree. I could never bring myself to use any of our forums. I'm living on mailing lists, our GitLab, and many Matrix channels. I only have that much input capacity. > Personally I never had time left for forums.kde.org, discuss.kde.org does > not change that fact. Exactly my experience and sentiment. On the other hand, our KDE PIM blog on kontact.org doesn't allow commenting. I suppose giving people the possibility to comment on the blog on discuss would be nice even if I probably wouldn't read the comments. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telegram <-> Matrix bridges will be removed in September
On Sonntag, 18. Juni 2023 08:44:25 CEST Adrian Chaves wrote: > On 2023-06-17 12:52, Kenny Duffus wrote: > > On Friday, 16 June 2023 13:31:27 BST Ingo Klöcker wrote: > >> May I ask why you want to be available via Matrix if, apparently, > >> Telegram > >> works so well for you? That's an honest question. > >> > >> 4th option: Stay on Telegram and ignore Matrix. > > > > The main problem with that is forcing people to choose between using > > Telegram or not being part of the discussions > > > > Telegram being non-free is one of the reasons we chose Matrix alongside > > IRC as the place for our community discussions > > Exactly. And we know there *are* people who do not use Telegram but do > use Matrix. And even if they were fewer, it would be wrong to keep them > off a KDE community because they make a choice that aligns better with > KDE's principles, like punishing them for doing the right thing in a > way. Fair enough. As I wrote, I was just asking. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telegram <-> Matrix bridges will be removed in September
On Freitag, 16. Juni 2023 09:10:22 CEST Adrian Chaves wrote: > We have a 3rd option: to try and set them up in our own infrastructure. > But what do we do if KDE decides to take down their bridges later, do we > do the same or would KDE Spain keep ours? I don't see a theoretical > justification for KDE Spain to go rogue on this topic, but at the same > time we suspect that going Matrix-only would be a significant hit to our > 569-people-strong Telegram group. May I ask why you want to be available via Matrix if, apparently, Telegram works so well for you? That's an honest question. 4th option: Stay on Telegram and ignore Matrix. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Forks cleanup
On Sonntag, 19. März 2023 04:30:09 CET Ben Cooksley wrote: > Hi all, > > While doing some routine maintenance and system assessments on our Gitlab > instance over the past week, it has become apparent that in certain > circumstances the de-duplication of objects between parent repositories and > their forks does not work correctly in some circumstances. > > While this isn't a significant issue as the system is well oversized to > handle growth, it is causing backups to take longer than they should to run > and makes certain estimates of future resource needs difficult to determine. > > It would therefore be appreciated if people could please remove any forks > they are no longer using. The button to remove a fork is hidden deep in the General project Settings under the subsection Advanced. See https://stackoverflow.com/a/59153938 for screenshots. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Sonntag, 15. Januar 2023 18:34:50 CET Paul Brown wrote: > On Sunday, 15 January 2023 16:24:48 CET Ingo Klöcker wrote: > > On Sonntag, 15. Januar 2023 08:04:18 CET Ben Cooksley wrote: > > > For blogs.kde.org, I am in two minds as to the best approach here, with > > > Wordpress and Hugo both appearing as candidates for this site. > > > Opinions welcome, especially if you are someone that currently uses it. > > With this I do not want to imply that anybody should use a tool they are > not comfortable with or which they feel gets in the way of their > productivity. But that's why Aniqa and I would prefer WordPress for the > dot. I was specifically talking about blogs.kde.org which, as far as I can tell, is used almost exclusively by developers. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)
On Sonntag, 15. Januar 2023 08:04:18 CET Ben Cooksley wrote: > For blogs.kde.org, I am in two minds as to the best approach here, with > Wordpress and Hugo both appearing as candidates for this site. > Opinions welcome, especially if you are someone that currently uses it. I think I'd very much prefer Hugo because I very much hate Wordpress for making it extremely painful to write simple content if one knows Markdown (and HTML) but has no clue how to use the Workpress plugins that try to hide the "complexity" of HTML by adding unintuitive and complex UIs on top of it. Ideally, writing a blog entry was as easy as writing a README.md. But anything is better than the current blogs.kde.org (which I tried to use for a blog entry just two days ago and probably will still be using because there don't appear to be any sensible, free alternatives if one doesn't want to run a blog on one's own website). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: BSD 3 Clause?
On Samstag, 31. Dezember 2022 11:04:44 CET Lukas Sommer wrote: > If I understand correctly, BSD-3-Clause is allowed for both, public-API > code and CMake code, but unless you must use it (because of upstream > license or other reasons), use BSD-2-Clause instead. In either case, other > existing BSD license variants must never be used. Exactly. > If so, I would propose this clarification to the license wiki page: > > https://community.kde.org/index.php?title=Policies%2FLicensing_Policy%2FDraf > t&type=revision&diff=95465&oldid=95464 Looks good. Would be great if you could add links from "as listed below" to the BSD-2-Clause entry, so that one can easily jump there. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: BSD 3 Clause?
On Mittwoch, 21. Dezember 2022 07:33:18 CET Lukas Sommer wrote: > I have a question about BSD-3-Clause. > > https://community.kde.org/Policies/Licensing_Policy says: > > 13. CMake code must be licenced under the BSD licence listed below > > And: > > BSD-2-Clause > > > > SPDX-License-Identifier: BSD-2-Clause > > SPDX-FileCopyrightText: > > > > A third requirement is sometimes included: BSD-3-Clause > > > > The advertising clause requiring mention in adverts must never be > > included. The Facebook patent grant must never be included. > > Now does this mean that BSD-3-Clause may be used instead of BSD-2-Clause > for CMake code or that it must not be used? Can we clarify the wiki page? I wondered about the same when checking how to license Python code. In the end I decided to use BSD-2-Clause because it didn't see a reason to use BSD-3- Clause. Things might be different if you want to include existing code that is BSD-3-Clause licensed. Re-reading the above I understand that BSD-3-Clause can be used instead of BSD-2-Clause. But I also read this as "Use BSD-2-Clause unless you have very good reasons to use BSD-3-Clause." because using BSD-3-Clause will make sharing code within KDE more complicated since one has to take care to keep BSD-3-Clause if the source of the copied code was BSD-3-Clause licensed. So, unless you must use BSD-3-Clause, please stick to BSD-2-Clause. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
On Montag, 19. Dezember 2022 23:34:11 CET Simon Redman wrote: > But my view don't matter, what matters is what happens in court, in the > event anyone ever accuses KDE of violating license terms. As I am not > qualified to expose KDE to any additional risk, is there a policy (or > accepted precedent) for distributing Apache-licensed libraries? I'm not aware of an official policy for shipping libraries licensed under the Apache license as part of build artifacts published by KDE. Traditionally, we only published source code where this question didn't arise. The KDE licensing policy only applies to "new source code and related data files in KDE repositories". Your question applies equally to the installers for Windows and macOS and the AppImages, FlatPaks, Snaps, etc. which KDE publishes. All of those installers/ packages include loads of third-party libraries and data that is published under all kinds of Open Source licenses. I think our policy could be something like "Everything (executable, libraries, images, data, etc.) included in installers, AppImages, FlatPaks, Snaps, etc. published by KDE must be licensed under an Open Source license.". Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Gitlab update, 2FA now mandatory
On Montag, 24. Oktober 2022 09:19:49 CEST Christoph Cullmann (cullmann.io) wrote: > I think it is rather worse that now first time contributors have this > requirement. Do you have proof for this, e.g. a study, or is this just your Bauchgefühl (gut feeling)? There is plenty of proof (e.g. TBs of leaked password databases) that lots of people use insecure passwords and that lots of people reuse the same "secure" password everywhere. 2FA protects those ignorant people. If the 2FA- requirement on invent helps to make more people aware of 2FA, then that's a good side-effect. Besides, my hope is that with FIDO2 "soon" passwords will be a relic of the past. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Future of Web Single Sign On in KDE
On Montag, 18. Juli 2022 16:40:01 CEST Halla Rempt wrote: > On zondag 17 juli 2022 11:54:27 CEST Ben Cooksley wrote: > > I'd therefore like to move away from both Identity and MyKDE to Gitlab. > > What will that mean for fund.krita.org? That currently uses mykde, and that > already is a problem for quite a few people to figure out how to create an > account and login. One idea is to allow signing in with different commonly used identity providers (like Google, etc.) for our more user-centric websites where we cannot expect most people to have an account at invent.kde.org already. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: How do we feel about non 100% KDE job offers being sent here?
Hi Albert, On Donnerstag, 25. November 2021 14:44:56 CET Albert Astals Cid wrote: > I know a company that would like to hire people with a skill set that > is relatively common inside the KDE community, the job is not strictly > KDE related, one could call it KDE-adjacent. > > How do we feel about such job offers being sent here? I'm not sure whether you are talking about jobs that will benefit KDE because working on KDE's offering (e.g. KDE Frameworks) is part of the job or whether you are talking about some Qt job which will not benefit KDE because the person will work on code that is orthogonal to KDE and maybe even proprietary. I'm not okay with job offers for non-Free Software jobs. There are more than enough portals to look for non-Free Software C++ and Qt jobs. I think I would be okay with Free Software job offers that are "KDE-adjacent". In fact, I might be interested. > Pro: > * We want people of the community to get [potentially better] jobs ... which still allow them to contribute to KDE at least a bit. > Con: > * The list could filled with job offers that are not really KDE > related since it's hard to define what "KDE-adjacent" really means. I think it should be restricted to jobs that benefit the Free Software ecosystem. OTOH, I think I would prefer to use a separate dedicated mailing list for this. I have mixed feelings about mixing community discussions with job advertisements. Maybe it would be okay if the job ads were clearly marked in the subject, e.g. with "[Job]" so that one can easily filter them out (physically or mentally). There should also be a clear policy that replies to job offers must not be send to the list and that job offers should not be commented or discussed on this list. All of this would be much easier with a separate mailing list. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Extending the license policy to allow certain exceptions
Hi all,
it's not clear to me whether our licensing policy allows exceptions or not.
https://community.kde.org/Policies/Licensing_Policy does not mention any
exceptions.
https://community.kde.org/Guidelines_and_HOWTOs/Licensing explains how to use
exceptions and gives an example with the Qt-LGPL-exception-1.1.
I have copied code from GCC's STL to implement a QMutex-compatible replacement
for std::unique_lock (because apparently Windows resp. mingw doesn't have
std::mutex). GCC's code is "GPL-3.0-or-later WITH GCC-exception-3.1". (Ignore
the bogus license id in the .cpp file. I've already fixed it.) Therefore I've
put my Qt'ified copy under the same license.
What now? Did I violate our licensing policy? Should we explicitly add allowed
exceptions to our licensing policy? I guess we don't want to allow all
exceptions listed at https://spdx.org/licenses/exceptions-index.html.
Regards,
Ingo
--- Begin Message ---
Git commit bd610f307dcd08be0e08007b483002f7c4df24ca by Ingo Klöcker.
Committed on 25/11/2021 at 11:01.
Pushed by kloecker into branch 'master'.
Add a QMutex-compatible replacement for std::unique_lock
M +3-0src/CMakeLists.txt
A +149 -0src/utils/uniquelock.cpp *
A +135 -0src/utils/uniquelock.h *
The files marked with a * at the end have a non valid license. Please read:
https://community.kde.org/Policies/Licensing_Policy and use the headers which
are listed at that page.
https://invent.kde.org/pim/libkleo/commit/bd610f307dcd08be0e08007b483002f7c4df24ca
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 561e618..d871dd3 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -103,6 +103,8 @@ target_sources(KF5Libkleo PRIVATE
utils/stringutils.h
utils/test.cpp
utils/test.h
+ utils/uniquelock.cpp
+ utils/uniquelock.h
)
ecm_qt_declare_logging_category(KF5Libkleo HEADER libkleo_debug.h IDENTIFIER
LIBKLEO_LOG CATEGORY_NAME org.kde.pim.libkleo
DESCRIPTION "libkleo (kleo_core)"
@@ -255,6 +257,7 @@ ecm_generate_headers(libkleo_CamelCase_utils_HEADERS
SCDaemon
StringUtils
Test
+ UniqueLock
REQUIRED_HEADERS libkleo_utils_HEADERS
PREFIX Libkleo
RELATIVE utils
diff --git a/src/utils/uniquelock.cpp b/src/utils/uniquelock.cpp
new file mode 100644
index 000..de462cf
--- /dev/null
+++ b/src/utils/uniquelock.cpp
@@ -0,0 +1,149 @@
+/*
+utils/uniquelock.cpp
+QMutex-compatible replacement for std::UniqueLock
+
+This file is part of libkleopatra, the KDE keymanagement library
+SPDX-FileCopyrightText: 2008-2021 Free Software Foundation, Inc.
+SPDX-FileCopyrightText: 2021 g10 Code GmbH
+SPDX-FileContributor: Ingo Klöcker
+
+SPDX-License-Identifier: GPL-3.0-or-later+GCC Runtime Library Exception
+*/
+
+#include
+
+#include "uniquelock.h"
+
+#include
+
+#include
+
+namespace Kleo
+{
+
+UniqueLock::UniqueLock() noexcept
+: mMutex{nullptr}, mOwnsMutex{false}
+{
+}
+
+UniqueLock::UniqueLock(QMutex &mutex)
+: mMutex{std::addressof(mutex)}, mOwnsMutex{false}
+{
+lock();
+mOwnsMutex = true;
+}
+
+UniqueLock::UniqueLock(QMutex &mutex, DeferLockType) noexcept
+: mMutex{std::addressof(mutex)}, mOwnsMutex{false}
+{
+}
+
+UniqueLock::UniqueLock(QMutex &mutex, TryToLockType)
+: mMutex{std::addressof(mutex)}, mOwnsMutex{mMutex->try_lock()}
+{
+}
+
+UniqueLock::UniqueLock(QMutex &mutex, AdoptLockType) noexcept
+: mMutex{std::addressof(mutex)}, mOwnsMutex{true}
+{
+// XXX calling thread owns mutex
+}
+
+UniqueLock::~UniqueLock()
+{
+if (mOwnsMutex) {
+unlock();
+}
+}
+
+UniqueLock::UniqueLock(UniqueLock &&u) noexcept
+: mMutex{u.mMutex}, mOwnsMutex{u.mOwnsMutex}
+{
+u.mMutex = nullptr;
+u.mOwnsMutex = false;
+}
+
+UniqueLock &UniqueLock::operator=(UniqueLock &&u) noexcept
+{
+if(mOwnsMutex) {
+unlock();
+}
+
+UniqueLock(std::move(u)).swap(*this);
+
+u.mMutex = nullptr;
+u.mOwnsMutex = false;
+
+return *this;
+}
+
+void UniqueLock::lock()
+{
+Q_ASSERT(mMutex);
+Q_ASSERT(!mOwnsMutex);
+if (!mMutex) {
+qCWarning(LIBKLEO_LOG) << __func__ << "Error: operation not permitted";
+} else if (mOwnsMutex) {
+qCWarning(LIBKLEO_LOG) << __func__ << "Error: resource deadlock would
occur";
+} else {
+mMutex->lock();
+mOwnsMutex = true;
+}
+}
+
+bool UniqueLock::try_lock()
+{
+Q_ASSERT(mMutex);
+Q_ASSERT(!mOwnsMutex);
+if (!mMutex) {
+qCWarning(LIBKLEO_LOG) << __func__ << "Error: operation not permitted";
+return false;
+} else if (mOwnsMutex) {
+qCWarning(LIBKLEO_LOG) << __func__ << "Error: resource deadlock would
occur";
+return false;
+} else {
+mOwnsMutex = mMutex->try_lock();
+re
Re: 25th Anniversary Fireside Chats
On Mittwoch, 6. Oktober 2021 23:28:04 CEST Albert Astals Cid wrote: > Why is Country a required field to register? Probably because the original developers of Indico were told that it's mandatory for the original use case (e.g. for visa letters for those old- school in-person meetings we used to have in the past ;-) ). Simply select Antarctica or some other country and get over it. And write an MR for Indico which makes this question optional. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Freitag, 28. Mai 2021 12:36:35 CEST Andrius Štikonas wrote: > 2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė: > > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > On 2021-05-26, Anna “CyberTailor” wrote: > > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > > >> period)> > > > > > > So you can use old sentry versions, which are open source. > > > > > > +1. I think we should support free and open source software. > > > > I do too. I'm curious though: How does using the 4 year old software > > support the software more than using the eventually 4 year old > > software? > > By the way, isn't it 3 year old software. That probably doesn't > fundamentally change the discussion. Although, if you use Debian stable or > Centos, you probably are using a lot of 3 year old software. Sure, but in Debian and Centos security fixes (for officially maintained packages) are backported. Are security fixes backported for the now Apache-2.0 licensed versions of Sentry? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: On the reappointment of Richard Stallman as a director of the FSF
On Donnerstag, 1. April 2021 12:48:23 CEST Niccolò Ve wrote: > They Yes, sorry, of course I meant "they", the board. Not, "it". > Il giorno gio 1 apr 2021 alle ore 12:45 Ingo Klöcker ha > scritto: > > On Donnerstag, 1. April 2021 00:27:57 CEST Albert Astals Cid wrote: > > > I feel that making a distinction between "KDE e.V. Board of Directors" > > > and "KDE e.V." is artificial, the board of directors have been > > > democratically elected to talk in name of KDE e.V. > > > > Hmm, okay. The board may talk in the name of the KDE e.V., but that > > doesn't mean it talks in the name of all members of the KDE e.V., the same > > way that a democratically elected government talks in the name of the > > corresponding country as a whole, but certainly doesn't talk in the name > > of each of its citizens. > > They talk in the name of the *country*. If you are elected as a > representative of Italy, you > talk in the name of Italy. Not "part of" Italy, not "most of" Italy, not > "all of" Italy, just Italy. > If you are elected representative of KDE, you speak in the name of KDE. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: On the reappointment of Richard Stallman as a director of the FSF
On Donnerstag, 1. April 2021 00:27:57 CEST Albert Astals Cid wrote: > I feel that making a distinction between "KDE e.V. Board of Directors" and > "KDE e.V." is artificial, the board of directors have been democratically > elected to talk in name of KDE e.V. Hmm, okay. The board may talk in the name of the KDE e.V., but that doesn't mean it talks in the name of all members of the KDE e.V., the same way that a democratically elected government talks in the name of the corresponding country as a whole, but certainly doesn't talk in the name of each of its citizens. Hopefully, they talk at least in the name of the majority. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: On the reappointment of Richard Stallman as a director of the FSF
On Mittwoch, 31. März 2021 21:50:14 CEST Albert Astals Cid wrote: > El dijous, 25 de març de 2021, a les 5:33:29 CEST, Alexander Potashev va escriure: > > It would be nice to clarify whose opinions this linked message represents. > > If this is something that the KDE e.V. Board voted for, then probably a > > signature "KDE e.V. Board of Directors" on the bottom of the page would > > make sense. > > It's in ev.kde.org, who do you think the opinions this linked message > represents? > > Speedy Gonzales? No, but it could be the KDE e.V. as a whole (it's not certain it is), it could be the KDE e.V. Board of Directors (as far as I understood, it is), or it could be some other group of KDE e.V. members. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Formal request to set up a KDE Discourse instance
On Freitag, 12. März 2021 21:44:09 CET Carl Schwan wrote: > Le vendredi, mars 12, 2021 7:49 PM, Ben Cooksley a > écrit : > > It also isn't as simple as just adding more server resources, as in some > > cases the place something will be moving from is a donated machine, and > > we prefer to ensure these are well utilised - meaning something needs to > > move back there in response. We also prefer to move services as little as > > possible to minimize downtime. If we were to simply add more machines, > > then we would end up with empty donated machines - which is a waste of > > the donation, as well as not the best use of eV resources. > > I'm not sure I fully understand your last point. If we add a new machine for > a new service this shouldn't create an empty donated machine. I'm not > really an expert in things related to sysadmins but looking at the price at > for VPS in Hetzner that should be able to handle a service similar to > krita-artists.org in term of storage shouldn't cost the e.V. more than €15 > a month. I think the e.V. can afford that to provide a lively place for the > community to ask questions and discuss things related to KDE. I'm pretty sure that neither hardware nor money is the problem. The problem is that each additional server increases the maintenance burden/cost. And since we are applying for the Blauer Engel certification, we should also try to minimize energy consumption and consumption of resources. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Targeted donations (Re: Fundraising in KDE)
On Sonntag, 4. Oktober 2020 18:43:42 CEST Philippe Cloutier wrote: > Le 2020-10-04 à 11:58, Ingo Klöcker a écrit : > > Currently we have a single big bucket for our money. All money that comes > > in (e.g. several thousand PayPal donations per year) goes into this > > bucket. All money that we spend is taken from this bucket. That's as > > simple as it gets. > > > > If we would allow targeted donations then we would have to sort all > > donations into multiple buckets. And all of our expenses would need to be > > taken from the correct buckets. Additionally, our contractors (e.g. our > > marketing contractors) would probably need to start tracking how much > > time they spend for a specific project (if we have a bucket for it), so > > that we can pay them from the right buckets. > > > > So, maybe it's more a change from O(1) to O(n*m) where n is the number of > > transactions and m is the number of different buckets. > > Thank you, that is much clearer (and way more sensical). I still don't > fully understand though; > > * Would this quantify the resources needed to process a *single* > transaction, or what? No, all of them. > * What resources does this quantify? *Manpower*, or computing resources? Mainly personpower. (Please try to avoid non-inclusive, patriarchaic vocabulary.) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Fundraising in KDE
On Sonntag, 4. Oktober 2020 00:36:56 CEST Philippe Cloutier wrote: > Le 2020-09-27 à 17:29, Ingo Klöcker a écrit : > > On Sonntag, 27. September 2020 22:54:07 CEST Albert Astals Cid wrote: > >> El diumenge, 27 de setembre de 2020, a les 21:36:46 CEST, Vincent Pinon > >> va escriure: > >>> As KDE eV can't allocate > >>> money to a specific project (if I understand correctly) > >> > >> That's more a "historically has not wanted" than a "legally can't". > > > > As one of the auditors of accounting I'll add that tracking money that is > > allocated to a specific project will make book keeping much more > > complicated. I'm not sure whether the simple tracking of income and > > expenses that we currently do will be sufficient. > > > >> It's my hope that with the recent KDE eV board public statements about > >> them > >> wanting to help people make out a living out of doing KDE stuff this may > >> change. > > > > In my opinion, paying people for doing KDE stuff (reminder: we do already > > pay quite a few people for doing important KDE stuff) is orthogonal to > > allocating money to specific projects. Complexity of book keeping would > > change from O(n) to O(n²). > > Can you clarify what you mean? Currently we have a single big bucket for our money. All money that comes in (e.g. several thousand PayPal donations per year) goes into this bucket. All money that we spend is taken from this bucket. That's as simple as it gets. If we would allow targeted donations then we would have to sort all donations into multiple buckets. And all of our expenses would need to be taken from the correct buckets. Additionally, our contractors (e.g. our marketing contractors) would probably need to start tracking how much time they spend for a specific project (if we have a bucket for it), so that we can pay them from the right buckets. So, maybe it's more a change from O(1) to O(n*m) where n is the number of transactions and m is the number of different buckets. I think we are way too small (in terms of cash flow) for allowing targeted donations. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Fundraising in KDE
On Sonntag, 27. September 2020 22:54:07 CEST Albert Astals Cid wrote: > El diumenge, 27 de setembre de 2020, a les 21:36:46 CEST, Vincent Pinon va escriure: > > As KDE eV can't allocate > > money to a specific project (if I understand correctly) > > That's more a "historically has not wanted" than a "legally can't". As one of the auditors of accounting I'll add that tracking money that is allocated to a specific project will make book keeping much more complicated. I'm not sure whether the simple tracking of income and expenses that we currently do will be sufficient. > It's my hope that with the recent KDE eV board public statements about them > wanting to help people make out a living out of doing KDE stuff this may > change. In my opinion, paying people for doing KDE stuff (reminder: we do already pay quite a few people for doing important KDE stuff) is orthogonal to allocating money to specific projects. Complexity of book keeping would change from O(n) to O(n²). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Fundraising in KDE
On Sonntag, 27. September 2020 15:24:45 CEST Julien Tremblay McLellan wrote: > Is there anyone from KDE that focuses on fundraising and grant seeking? Yes, the fundraising working group: https://ev.kde.org/workinggroups/fundraisingwg/ Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: BoF Notes: How Python can help KDE Development?
On Sonntag, 13. September 2020 12:13:48 CEST Adriaan de Groot wrote: > On 2020 setula d. 12id 23:02:27 CEST Ingo Klöcker wrote: > > On Samstag, 12. September 2020 16:13:29 CEST Cristián Maureira-Fredes > > wrote: > > > - A similar project on this topic is PythonQt [3] > > > > > > [3] https://mevislab.github.io/pythonqt/Examples.html > > > > I have worked many years with the maintainer of PythonQt (Florian Link, > > awesome developer and person) and have made extensive use of PythonQt for > > scripting MeVisLab (a Qt-based application framework for medical imaging > > applications). > > That's interesting: PythonQt was also used by Calamares (Calamares also uses > Boost::Python, so offering two ways to embed Python into the C++ > application). PythonQt support is deprecated and will be removed, for two > reasons: > > 1 - nobody was actually using the Qt / UI parts of it to do UI scripting in > Calamares, so the extra API and dependency was not useful, and > 2 - PythonQt is packaged inconsistently and/or weirdly by Linux distro's, > which makes it hard to depend upon. > > That might be a chicken / egg situation though: if it's not packaged, people > won't use it either. I see that Calamares still refers to a SourceForge > home for it -- that's an indication of how old and unmaintained that part > of the Calamares code is. However, after chasing a few redirects, I end up > on GitHub, with no tags, no releases and no indication of anything newer > than Qt 5.12 in that repo. (And it uses QtScript, it seems, although an > own-copy) > > Perhaps that project needs some extra help with documentation and > presentation? I think help would be appreciated. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: BoF Notes: How Python can help KDE Development?
On Samstag, 12. September 2020 16:13:29 CEST Cristián Maureira-Fredes wrote: > * Kross > - Since it's based on QtScript, there might an option to evaluate of > Python can replace it, since QtScript > was deprecated. > - A similar project on this topic is PythonQt [3] > > [3] https://mevislab.github.io/pythonqt/Examples.html I have worked many years with the maintainer of PythonQt (Florian Link, awesome developer and person) and have made extensive use of PythonQt for scripting MeVisLab (a Qt-based application framework for medical imaging applications). MeVisLab and therefore also PythonQt is the basis of many products of MeVis Medical Solutions AG and other companies. This means there's a high probability that PythonQt will be well maintained for years to come. If you want to add the possibility to script your application with Python, I highly recommend to give PythonQt a try. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal: Recurring donations - increase flexibility
On Freitag, 31. Juli 2020 08:28:48 CEST Uli Klinkhammer wrote: > On 2020-07-31 01:35, Aleix Pol wrote: > > https://relate.kde.org is already running CiviCRM at the moment. It's > > the one we are trying to get improvements on. > > Fine to hear, so good luck for everybody involved! :) > > In my opinion, the possibility to send "any amount" should be realized, > at the same time as "anonymous donations" (or better said, without the > need to register). Anonymous one-time donations are already possible via PayPal. There's a form at the bottom of our webpage. > And in my opinion this module should appear in any of the KDE apps. The > best would be to show it at the first start of any KDE program. There is already a "Donate" option in the Help menu of any KDE program (well, I just checked KMail which I'm using for writing this email). I have doubts about showing this at the first start. At the first start of any application I do not yet know whether the application really does what I need and whether I like working with the application. I would certainly not make a donation before having used an application for some time. Anyway, as Aleix wrote: > I'd like to remind everyone we have a Fundraising Working Group. If > anyone wants to join and help, you can reach out to > kde-ev-campa...@kde.org. So, please subscribe to kde-ev-campa...@kde.org and continue the discussion there. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal: Recurring donations - increase flexibility
On Donnerstag, 30. Juli 2020 00:41:26 CEST Nate Graham wrote: > On 7/29/20 12:44 PM, Albert Astals Cid wrote: > > This was voted and approved by the KDE eV membership assembly a while ago, > > it's just that it is not as easy to implement as we would like and thus > > it still has not happened. > > Yeah I think everyone wants this, it's just a matter of getting it done. > Perhaps the board mailing list would be a more appropriate place to > continue the discussion since it's one of their tasks? I don't think that the board mailing list is a more appropriate place to continue the discussion. 1) The board mailing list is a private list and, on top of that, only members of the board (and a few selected others) are subscribed. So it's hardly a good place for a discussion. Not even for a private discussion. 2) The board is not our service team. Everybody (in particular, members of the KDE e.V., but also the wider KDE community) is asked to help the board complete our (not "their") tasks. Anyway. From the board call notes sent to the (private) member ship list it's clear to me that the board is trying hard to get this done. Apparently, it's hard to find competent contractors who are capable of implementing this in CiviCRM. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal: Mailing List owner policy
Hi Valorie, On Dienstag, 28. Juli 2020 04:37:32 CEST Valorie Zimmerman wrote: > Hi Ingo, > > On Mon, Jul 27, 2020 at 12:59 AM Ingo Klöcker wrote: > > On Sonntag, 26. Juli 2020 18:31:08 CEST Philippe Cloutier wrote: > > > An even bigger question, I'm afraid. When nobody steps up, what would we > > > do? I wouldn't mind "moderating" this list today, for instance, since I > > > found the time to read it. But I for one would not *commit* myself to > > > moderate it or any other; I just don't have the required availability > > > and if I had, I wouldn't guarantee I would remain available. > > > > I'm sorry, but I have the feeling that you are making too much of a fuss > > about > > this. Maybe you are misunderstanding what "moderating" entails. Or maybe I > > misunderstood for years what moderation of a mailing list entails. > > > > I am owner of one mailing list and moderator of another. Moderation of the > > second mailing list is restricted to the moderation of posts that are held > > for > > moderation mostly because those post come from unsubscribed senders (99 % > > of > > this is SPAM). I'm not even subscribed to the second mailing list. I don't > > see > > moderation of legit posts (i.e. posts that are not held for moderation) as > > my > > task. This kind of moderation costs almost no time. > > It's true that it costs each of us listowners/moderators "no time" per > list. Albert's point is what happens when such people disappear? While it > may seem like easy work that "anyone" can do, it can be like people > throwing litter into the trashcan instead of into the street. Each such act > takes a mere second, but when it is not done, there are mounds of garbage > (spam). > > If all of us listowner/moderators see ourselves as part of the list *team*, > then we can cover for one another, and recruit new team members when > necessary. I don't see this as a "fuss" but more about turning a small > problem into a small plus for the KDE community. What I perceived as a "fuss" was Philippe's proposals about measuring moderator activity, setting a time limit, marking unmoderated relayed messages, etc. I'd prefer a much more down-to-earth approach and I can see a regular (e.g. quarter-yearly) message to moderators to check whether they are still active and a mailing list for moderators as useful tools. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Proposal: Mailing List owner policy
On Sonntag, 26. Juli 2020 18:31:08 CEST Philippe Cloutier wrote: > An even bigger question, I'm afraid. When nobody steps up, what would we > do? I wouldn't mind "moderating" this list today, for instance, since I > found the time to read it. But I for one would not *commit* myself to > moderate it or any other; I just don't have the required availability > and if I had, I wouldn't guarantee I would remain available. I'm sorry, but I have the feeling that you are making too much of a fuss about this. Maybe you are misunderstanding what "moderating" entails. Or maybe I misunderstood for years what moderation of a mailing list entails. I am owner of one mailing list and moderator of another. Moderation of the second mailing list is restricted to the moderation of posts that are held for moderation mostly because those post come from unsubscribed senders (99 % of this is SPAM). I'm not even subscribed to the second mailing list. I don't see moderation of legit posts (i.e. posts that are not held for moderation) as my task. This kind of moderation costs almost no time. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE Apps name trademarks
On Montag, 20. Juli 2020 01:17:20 CEST Cornelius Schumacher wrote: > The most important thing, though, would be to formulate our trademark policy > so we have a clear base to operate from for now and the future. We should > look at the trademark policies of other projects and use them as > inspiration and maybe something like a template. We do have some kind of trademark policy already for the KDE logo. It's not listed at the KDE e.V. page under policies (where I looked first). I found it at the "KDE Clipart" page: https://kde.org/stuff/clipart.php It reads "The KDE logo can be used freely as long as it is not used to refer to projects other than KDE itself. There is no formal procedure to use it. Copying of the KDE Logo is subject to the LGPL copyright license. Trading and branding with the KDE Logo is subject to our trademark licence. For more details on their usage please see the KDE CIG Logo page." (The "KDE CIG Logo" page which the above refers to only explains when to use which logo style.) Wikimedia Commons cites the above text as trademark license: https://commons.wikimedia.org/wiki/File:Klogo-official-crystal.svg Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: reddit r_KDE uses KDE logo in LGBT colors
On Sonntag, 12. Juli 2020 12:13:34 CEST sabayon11 wrote: > I have a question: > Is it legal for reddit moderators of r_KDE to use KDE logo in LGBT > colors. For me the logo is displayed in blue. Maybe it has been changed back already. (Okay, you wrote "It is now off." at the end of your mail.) I suppose the logo was changed around Pride Day. > Is it consistent with logo license? I'd say yes. "Copying of the KDE Logo is subject to the LGPL copyright license." ([1]) The LGPL allows modifications. The full text on https://kde.org/stuff/clipart.php reads: "The KDE logo can be used freely as long as it is not used to refer to projects other than KDE itself. There is no formal procedure to use it. Copying of the KDE Logo is subject to the LGPL copyright license. Trading and branding with the KDE Logo is subject to our trademark licence. For more details on their usage please see the KDE CIG Logo page." > https://www.reddit.com/r/kde/ > > Is it in line with KDE code of conduct - to support certain groups > that are politically active and be selective in this choice? I'd say yes, as long as those "groups that are politically active" are compatible with KDE's values as spelled out in the code of conduct. In my opinion, this applies to the LGBT community. > For > example: why they don't support women rights in middle-east region? Ask the moderators of Kreddit. I'm sure they are open to your suggestions. > Who have the right to decide? Concerning Kreddit? I guess the moderators of Kreddit decided this. > Do you realize that it can stop certain people from funding KDE? Of > course on the other hand it can make others, like George Soros to fund > but does KDE really want to go in that direction and engage in such > politics. Pretending that it has nothing to do with politics is a pure > lie. KDE is openly pro-LGBTQ+, e.g. we had LGBTQ+ dinners as part of the last few Akademy conferences. > What other KDE contributors think about it? For example: do all KDE > funders support engaging software community in non-software activity? > > I know that reddit is separate website and has nothing to do with this > forum, however this is social and community issue as well. > > What about adding to KDE code of conduct: KDE is not engage in social > or political dispute. KDE doesn't discriminate nor support any groups > other than Free Software. Free Software is highly political. There's no way for KDE not to engage in political dispute. By the way, we also support the climate crisis movement. > Personally I believe there are thousands of other better places on the > Internet to express whatever point of view someone has and KDE and its > community should not be involved in such activities. KDE does not exist in a closed bubble. KDE is part of the world and as such the community will continue to express its point of views. > It is now off. But this doesn't change the meaning of this action. > My first message about it to this list was on 3rd of July but has not > been accepted by moderators yet, so I had to subscribe. Regards, Ingo [1] https://kde.org/stuff/clipart.php signature.asc Description: This is a digitally signed message part.
Re: The KDEPIM / Akonadi situation
On Samstag, 13. Juni 2020 10:35:50 CEST Ben Cooksley wrote: > There is nothing that can be done to delay builds for one repository > on the build of another at this present time. > Neither Jenkins or Gitlab CI provide the necessary support for us to > link jobs together in the way that PIM demands in this case here. > [snip] > > In terms of Gitlab, while it does allow triggering jobs in other > projects as part of a job run (see Minor correction: It does allow triggered pipelines in other projects. > https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is > limited to a dependency chain only. Not sure what you mean by "a dependency chain only". I have implemented dependency trees even with loops (and then taking care that they don't loop too often) in GitLab. What has not been possible was to prevent pipelines from being triggered too often in diamond shape dependency scenarios. > It does not extend to waiting for the parent job to complete. That doesn't matter if the job triggering the pipeline of the dependent project is the last job (i.e. in the last stage) of the parent project's pipeline. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration
On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote: > [adding sysad...@kde.org in CC, please make sure you keep it in CC] > > On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote: > > On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote: > > > That requires that you know it exists. We have 1,043 mainline > > > repositories at the moment, which translates to 53 pages of projects > > > under a flat structure system. > > > Reality is nobody is going to page through that looking for something. > > > > I have to disagree. Whenever I'm looking for a project I browse > > https://projects.kde.org/ (aka https://cgit.kde.org/). > > Using a simple Ctrl+F in my browser allowed me to find what I was looking > > for rather easily. > > > > Having to look into *several* subgroups (because I guess we all know from > > experience that any categorization into several groups never matches our > > expectation) would have been a pain in the ass. > > > > > Please also see my point regarding listing merge requests at the group > > > level > > > > This argument only holds if the subgroups match development teams. It does > > already break down if e.g. a KDE PIM developer wants to see merge requests > > for PIM related frameworks and for PIM applications. > > > > I have experienced exactly this problem at work were we have put repos of > > unrelated projects into different groups. It was extremely inconvenient > > that, while working on more than one project at the same time, I couldn't > > see all MRs I'm interested in on a single page. > > > > IMNSHO the groups in GitLab are not the right solution for gathering all > > repos some dev team, let alone individual devs, is/are interested in, > > because the assumption that different dev teams are interested in > > *disjoint* sets of repos is simply wrong. Moreover, the assumption that > > all members of some dev team are interested in exactly the same repos is > > equally wrong (even if most team members are probably interested in most > > of the same repos). > > > > And while the mapping group to dev team might make sense for something > > like > > plasma or frameworks or KDE PIM, I sure that it makes less or no sense for > > groups like graphics were different teams are working on different > > applications in the same group. > > > > > - you can see an example of what a flat structure ends up > > > looking like at https://gitlab.gnome.org/GNOME > > > > > > For those projects that span multiple repositories, you have just > > > denied them any chance or ability to see a listing of everything > > > related to their wider project. > > > > I'm sorry, but I don't think that this is solved by your proposal for the > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in > > the same group. The same is true for any project which uses some > > frameworks, e.g. graphics and the imageformats framework or whatever > > group kate and kwrite are going to end up in and the ktexteditor > > framework. > > This is something which can be easily solved by Gitlab, Gitlab offers a > solution where project can be shared with another group. > > So e.g. sharing kcontacts with kdepim should be possible, then all merge > requests/issues from kcontacts would show up under pim as well. Great. So we could put all repos into an "all" group (e.g. rename kde to all) and then have every subcommunity decide for themselves which repos they want to see in their group. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration
On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote: > That requires that you know it exists. We have 1,043 mainline > repositories at the moment, which translates to 53 pages of projects > under a flat structure system. > Reality is nobody is going to page through that looking for something. I have to disagree. Whenever I'm looking for a project I browse https://projects.kde.org/ (aka https://cgit.kde.org/). Using a simple Ctrl+F in my browser allowed me to find what I was looking for rather easily. Having to look into *several* subgroups (because I guess we all know from experience that any categorization into several groups never matches our expectation) would have been a pain in the ass. > Please also see my point regarding listing merge requests at the group > level This argument only holds if the subgroups match development teams. It does already break down if e.g. a KDE PIM developer wants to see merge requests for PIM related frameworks and for PIM applications. I have experienced exactly this problem at work were we have put repos of unrelated projects into different groups. It was extremely inconvenient that, while working on more than one project at the same time, I couldn't see all MRs I'm interested in on a single page. IMNSHO the groups in GitLab are not the right solution for gathering all repos some dev team, let alone individual devs, is/are interested in, because the assumption that different dev teams are interested in *disjoint* sets of repos is simply wrong. Moreover, the assumption that all members of some dev team are interested in exactly the same repos is equally wrong (even if most team members are probably interested in most of the same repos). And while the mapping group to dev team might make sense for something like plasma or frameworks or KDE PIM, I sure that it makes less or no sense for groups like graphics were different teams are working on different applications in the same group. > - you can see an example of what a flat structure ends up > looking like at https://gitlab.gnome.org/GNOME > > For those projects that span multiple repositories, you have just > denied them any chance or ability to see a listing of everything > related to their wider project. I'm sorry, but I don't think that this is solved by your proposal for the KDE PIM projects because not everything related to KDE PIM (e.g. relevant frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in the same group. The same is true for any project which uses some frameworks, e.g. graphics and the imageformats framework or whatever group kate and kwrite are going to end up in and the ktexteditor framework. The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single group is insufficient for us (while it's sufficient for most users of gitlab.com). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Help with KDE PIM and Google Privacy Policies needed
On Sonntag, 22. März 2020 15:28:55 CET Alexander Potashev wrote: > For now there may be various cases where the user stays unaware about > how our software handles their data. Consider this scenario for > example: > 1. A user installs KMail and e.g. an E-mail notifier Plasma widget on > the same machine, > 2. The user runs KMail and grant access to their Gmail account, > expecting that it will only be used by KMail, > 3. The user enables the E-mail notifier widget. The widget will just > work without asking the user for permission to access their data from > Gmail account. This conflicts with Google’s API Services User Data > Policy. Quite frankly, that's exactly what I expect from an integrated desktop. I have the impression that Google’s API Services User Data Policy makes assumptions that are true on Android, but that fail completely on any desktop computer where any application can access the data of any other application running in the same user account. > In our https://community.kde.org/KDE_PIM/Privacy_Policy, the red flag > is clearly "It is possible for any locally running software to > interact with Akonadi and thus access, modify or delete any data > stored there." Simply drop "interact with Akonadi and thus" from this policy and you get the reality on desktop computer systems. Akonadi isn't needed. The data files can be accessed, modified and deleted by any application without the help of Akonadi. BTW, the same is true for Thunderbird's data. And for Google Chrome's data. And the data for any other application running in user space. (Probably unless SELinux or AppArmor is enforced in user space.) The same is also true on Windows and macOS. IOW, I don't see a problem that can be solved technically (without reinventing data handling on desktop systems). It's purely a policy issue. So, let's simply delete the above "red flag" from our policy. Why mention something which is obvious for any application storing data locally on a desktop computer. > Here are two approaches that in my opinion would (at least partially) > resolve the issue: > > [Approach #1]. Have all Akonadi clients create and use their own > Google API app IDs/keys. Isolate cached data in Akonadi per app, so > that e.g. an E-mail notifier widget cannot reach through Akonadi API > to access the data downloaded specially for Kmail. It will need to ask > Akonadi IMAP resource to request the same emails again. > This implies huge data duplication in Akonadi in some cases, however > it can probably be deduplicated inside Akonadi to save storage space. The whole point of Akonadi is to have a central hub for all PIM data to avoid unnecessary duplication. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New kde.org/hardware webpage
On Freitag, 24. Januar 2020 15:02:24 CET Philippe Cloutier wrote: > Ahem, wasn't that fast? The mail you quote is not phrased as a proposal, > but as a request for comments. Just a quick first look reveals at least > the following issues: > > The currency units used are unclear. > > > Tuxedo build tailor-made hardware and all this with Linux! > > I suppose s/build/builds/ > > > All the computers and notebooks are assembled and installed in our house. > > "our house"? "in our house" means in the house/building were Tuxedo Computers resides. As opposed to "are assembled and installed in a sweat shop in some cheap-labor- country". Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: New homepage for kde.org
On Sonntag, 8. Dezember 2019 19:59:58 CET Christoph Cullmann wrote: > On 2019-12-08 18:12, Ben Cooksley wrote: > > If you want any form of statistics, then it has to be Piwik (now > > called Matomo btw) > > > > Processing of our logs for web statistics purposes is not permitted by > > our privacy policies (see https://kde.org/privacypolicy.php). > > > > It is also much more problematic to process logs as people have no way > > of opting out from that processing because every request is logged - > > whereas Piwik/Matomo gives them the ability to opt out. > > Hi, > > is this still a legal issue if one anonymizes the IPs during processing? I don't think it matters whether it would be legal. What matters is that people whose browsers are set to send "Do Not Track" (or who have opted out of tracking some other way) shouldn't be tracked in any way. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Dienstag, 12. November 2019 13:11:43 CET Luigi Toscano wrote: > Māris Nartišs ha scritto: > > pirmd., 2019. g. 11. nov., plkst. 16:02 — lietotājs Luigi Toscano > > > > () rakstīja: > >> Alexander Potashev ha scritto: > >>> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano : > Nate Graham ha scritto: > > On 11/9/19 4:50 PM, Nicolás Alvarez wrote: > >> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) > >> escribió: - Experiment conversion to git and see if the resulting > >> repo(s) are of a reasonable size (I vaguely recall seeing bad > >> results with this) > >>> > >>> I expect that a single Git repository would be several GBs in size. > >> > >> For the record, the current checkout (without svn metadata) of > >> trunk/l10n-kde4 (ok, no more needed), branches/stable/l10n-kde4, > >> branches/stable/l10n-kf5, branches/stable/l10n-kf5-plasma-lts, > >> trunk/l10n-kf5 and trunk/l10n-summit is ~11 GiB. The trunk/l10n-kf5 > >> branch alone is 5.3 GiB. > > > > One of pro sides of SVN still is ability to work with a single > > directory instead of whole repo. For Latvian language it means using > > only ~300MB of disk space (I have less than 1GB free space on my > > laptop). Thus if a move to GIT is planned, I would vote to have a > > separate repo for each language. > > Right, but that would make the life of people doing bulk changes (like me) > much more complicated. Right now I can do all the changes in one shot. > That's part of the problem. It's seems this could be solved with tooling. Jack already proposed using git submodules. At work I'm solving the problem with a simple bash-script which loops over 10-20 repos to do a git pull/rebase/push on all of them. Yes, merge conflicts occur from time to time, but they would occur regardless of the number of repos involved. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Montag, 11. November 2019 04:21:44 CET Alexander Potashev wrote: > Also, Lokalize has much more features that a plain text editor: > 1. Interactive merging and reviewing of changes from other .po > translation files. I use it all the time to review and commit > translations from people without SVN accounts. > 2. Translation memory. Boost productivity, improves consistency of > translations. > 3. Other features that improve productivity (insertion of XML/HTML > tags, source string diffs, ...) Sounds as if all that's missing in Lokalize is built-in support for git. Maybe a GSoC or SoK project? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Montag, 11. November 2019 11:26:23 CET Ben Cooksley wrote: > With regards to removal of access for everyone but translators, there > have been two objections noted to this. One concerned compliance with > the Manifesto, whilst the other was concerned with creating obstacles. > Given that restricting access to the websites is still compliant with > the Manifesto despite the lack of a clear clause permitting this I > don't believe that not granting access by default to Subversion should > be an issue, so would like to proceed with this as well. FWIW, I withdraw my objection concerning compliance with the Manifesto since, according to Ben, anyone with a contributor account can, if needed, request access by filing a Sysadmin ticket. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Sonntag, 10. November 2019 16:09:34 CET Luigi Toscano wrote: > Nate Graham ha scritto: > > Again, from a totally non-translation perspective, I am somewhat surprised > > to hear that individual translators are required to be proficient in a > > source control system. Perhaps de-coupling the workflow from direct > > interaction with the SCM would be beneficial? Isn't this what GUI apps > > like KLocalize do? If not, can it be modified to do the SCM interaction? > > This seems like a solvable problem. > > Most of translators are not so technical as the developers. And even > developers can shoot them in the foot with git, I see many issues coming > from unwanted merges. GitLab allows editing files directly in the browser. Maybe that's an alternative to having to deal with an SCM-CLI. > Also, in addition to some of the problem described above (not all of them > are blocker IMHO), more relevant: how would you convert the SVN > repositories into git? > - a unique repository would be the easier way, and > required by people who do changes to all the languages (renamed and moves) > but I can only foresee tons of merging issues when committing (see above). Why do those merging issues not occur with svn? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Sysadmin Load Reduction: Subversion Infrastructure
On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote: > On top of this, i'd also like to remove commit access to it for > everyone but translators and those who need to work on the small > number of websites remaining on Subversion and only provision this for > people on an as-needed basis. > > In the next year or so i'd expect the remaining websites to complete > their migrations to Git, after which only translators would receive > access. Restricting access to the translations repository is against the letter of our manifesto which states "All source materials are hosted on infrastructure available to and writable by all KDE contributor accounts" https://manifesto.kde.org/commitments.html AFAIK, "all source materials" includes translations. There are a few reasonable exceptions for this requirement, e.g. for the sources of our websites, but I don't see a good reason for restricting access to the translations. I think restricting access to the translations will create a precedent for restricting access to other source materials and undermines the values stated in our manifesto. Therefore, I don't think we should go down this route. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: FSF leadership
On Donnerstag, 19. September 2019 14:48:28 CEST John Tapsell wrote: > Now using the term "race" is "copying racists"? Wtf? Language barrier problem. Unlike in English, in German, the literal translation of the term "race", i.e. "Rasse", has a different meaning than the English term "race". In particular, the German term "Rasse" cannot and must not be applied to humans, but only to animals. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Discourse
On Montag, 26. November 2018 18:03:55 CET Martin Flöser wrote: > Am 2018-11-26 09:23, schrieb Ilmari Lauhakangas: > > The main problem in any case will be getting enough engagement. I > > don't think I have ever received a reply from a KDE developer in the > > current forums. > > And that's good! Do you want that developers spend time answering simple > support questions any other user could answer or do you want developers > to code? No company would put their expensive developers on the front > line for support. No company would publish their precious IP (aka source code) as Free Software. Luckily, KDE is not a company but a community of people where everybody, even the most precious developers, can be at the front line for support if they want to be there. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: FOSDEM stall
On Freitag, 15. Dezember 2017 23:00:15 CET Adriaan de Groot wrote: > Anyway, for a FOSDEM booth presence we'll need: > - who's going to be at FOSDEM (in any capacity) I am going ... > - who's going and is willing to help at the booth >- and what's your T-shirt size and am willing to help. T-shirt size is M. > - energy and enthusiasm! \o/ KDE rocks! \o/ Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy
On Sunday 13 August 2017 11:47:28 Volker Krause wrote: > Hi, > > during the KUserFeedback BoF at Akademy there was quite some interest > in collecting telemetry data in KDE applications. But before actually > implementing that we agreed to define the rules under which we would > want to do that. I've tried to put the input we collected during > Akademy into proper wording below. What do you think? Did I miss > anything? Since my other messages in this thread might give a wrong impression, I'd like to clarify that I like Volker's original draft a lot. In my opinion, it's very well thought out and most likely fully compliant with European and German law, but IANAL. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy
On Monday 14 August 2017 19:28:06 Volker Krause wrote: > On Monday, 14 August 2017 14:16:12 CEST Bhushan Shah wrote: > > Can we have policy on how long we can store data? It's just random > > idea but I think it makes sense to tell users that after X period > > of time your data will be invalidated? > > > > This gives the "part-solution" to problem where user wants to delete > > their shared data. > > Good point. I'm unsure on what to pick as a suitable timeframe though. > It's hard to give a specific time right now, we don't know yet how > quickly updates of our software are deployed, which is what is going > to determine the latency of getting the data we want. For that > question alone we are looking at years I think. Maybe this could be > worded as "data is only kept as long as the purpose of the data > collection hasn't been achieved yet", ie. as soon as we have the > answer we were looking for we delete the raw data. For most purposes (e.g. which parts of the software are used how often) it should be possible to aggregate the raw data monthly and then throw away the raw data. > The bigger problem however is that this conflicts with publishing the > data under a free license. At this point we lose any control to > enforce data retention limits. With respect to the considerations to make the collected raw data public I ask you to contact a data protection officer (Datenschutzbeauftragte/r) to get her/his opinion. Quoting https://en.wikipedia.org/wiki/General_Data_Protection_Regulation: "Valid consent must be explicit for data collected and the purposes data is used for (Article 7; defined in Article 4)." Since you cannot state the purposes the data is used for (because once made public it could be used for any purpose), I cannot see how you could get the users' consent for this. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy
On Monday 14 August 2017 22:26:36 Thomas Pfeiffer wrote: > On Sonntag, 13. August 2017 11:47:28 CEST Volker Krause wrote: > > ## Minimalism > > > > We only track the bare minimum of data necessary to answer specific > > questions, we do not collect data preemptively or for exploratory > > research. In particular, this means: > > - collected data must have a clear purpose > > While from a privacy perspective this certainly makes sense, with my > user researcher hat on I'm worried that this might severely limit the > usefulness of the whole operation, at least if changes to what is > being tracked can only be made with each new major release of an > application. > [snip] > > So, long story short: While I agree that we should not just wildly > collect everything we can, being able to start measuring variables > only on the next release after a concrete hypothesis has been > formulated about them could really slow us down. > > Is there any possible way to mitigate this issue? I suggest the same to you as I did to Volker: Contact a data protection officer, e.g. the one assigned to the company you work for, and talk with her about it. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy
On Monday 14 August 2017 21:53:17 Ben Cooksley wrote: > On Sun, Aug 13, 2017 at 9:47 PM, Volker Krause wrote: > > Hi, > > Hi Volker, > > > during the KUserFeedback BoF at Akademy there was quite some > > interest in collecting telemetry data in KDE applications. But > > before actually implementing that we agreed to define the rules > > under which we would want to do that. I've tried to put the input > > we collected during Akademy into proper wording below. What do you > > think? Did I miss anything? > > > > Regards, > > Volker > > > > > > # Telemetry Policy Draft > > > > Application telemetry data can be a valuable tool for tailoring our > > products to the needs of our users. The following rules define how > > KDE collects and uses such application telemetry data. As privacy > > is of utmost importance to us, the general rule of thumb is to err > > on the side of caution here. Privacy always trumps any need for > > telemetry data, no matter how legitimate. > > > > These rules apply to all products released by KDE. > > > > ## Transparency > > > > We provide detailed information about the data that is going to be > > shared, in a way that: > > - is easy to understand > > - is precise and complete > > - is available locally without network connectivity > > > > Any changes or additions to the telemetry functionality of an > > application will be highlighted in the corresponding release > > announcement. > > > > ## Control > > > > We give the user full control over what data they want to share with > > KDE. In particular: > > - application telemetry is always opt-in, that is off by default > > - application telemetry settings can be changed at any time, and are > > provided as prominent in the application interface as other > > application settings - applications honor system-wide telemetry > > settings where they exist (global "kill switch") > > - we provide detailed documentation about how to control the > > application telemetry system > > > > In order to ensure control over the data after it has been shared > > with KDE, applications will only transmit this data to KDE servers, > > that is servers under the full control of the KDE sysadmin team. > > > > We will provide a designated contact point for users who have > > concerns about the data they have shared with KDE. While we are > > willing to delete data a user no longer wants to have shared, it > > should be understood that the below rules are designed to make > > identification of data of a specific user impossible, and thus a > > deletion request impractical. > > Can we change "impractical" to "effectively impossible" here please? > > > ## Anonymity > > > > We do not transmit data that could be used to identify a specific > > user. In particular: > > - we will not use any unique device, installation or user id > > - data is stripped of any unnecessary detail and downsampled > > appropriately before sharing to avoid fingerprinting > > - network addresses (which are exposed inevitably as part of the > > data > > transmission) are not stored together with the telemetry data, and > > must only be stored or used to the extend necessary for abuse > > counter-measures > I'm wary that people might jump on the network addresses bit here. > > Can we please mention that all records that contain network addresses > and other similar information would be stored in such a form that they > could not be associated with telemetry records. > > In terms of the logs - as there are other uses for them, i'd prefer if > we widened that to also allow them to be kept to allow us to maintain > the proper and effective operation of the telemetry system and other > associated services. The time we retain those logs should also be at > our complete and total discretion and if need be should be > indefinite. I'm pretty sure that this would be a violation of the European General Data Protection Regulation. In Germany IP addresses are considered personal data (by rulings of the German constitutional court). Therefore, IP addresses must be anonymized, e.g. by zeroing the last part of the quadruplet (see for example the anonymizeIp setting of Google Analytics), if they are used for anything other than maintaining the security of a service. Even if used for maintaining the security of a service they must not be stored longer than absolutely necessary. Storing IP addresses indefinitely or at least for a long period of time is the "wet dream" of all national law enforcement intelligence institutions -> Vorratsdatenspeicherung (data retention). Luckily, so far those dreams have been stalled by the German constitutional court. The German Minister of the Interior would be delighted if KDE would provide such data. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy
On Sunday 13 August 2017 12:56:27 Martin Flöser wrote: > Am 2017-08-13 11:47, schrieb Volker Krause: > > Hi, > > > > during the KUserFeedback BoF at Akademy there was quite some > > interest > > in > > collecting telemetry data in KDE applications. But before actually > > implementing that we agreed to define the rules under which we would > > want to > > do that. I've tried to put the input we collected during Akademy > > into > > proper > > wording below. What do you think? Did I miss anything? > > To me it looks good! > > I have some additional requests: > * the collected data must be made available to the public (mostly > thinking of research institutes here) I don't think so. And in view of "we do not collect data preemptively or for exploratory research" I think the draft agrees with me. AFAIU, the (raw) collected data is meant to be used by us exclusively to answer specific questions. It is specifically not meant to be used by random researchers to draw conclusions and publish papers about our users. I'm not against publishing aggregates like "25 % of the users of KWin use Wayland", but only once a year or so. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KDE GPG Keyserver
On Montag, 24. Juli 2017 14:47:48 CEST Luca Beltrame wrote: > Il giorno Mon, 24 Jul 2017 12:51:42 +0200 > > Boudhayan Gupta ha scritto: > > You can of course add a new line to ~/.gnupg/dirmngr.conf to add this > > keyserver to your list of keyservers. > > Is this reachable also on port 80? My workplace blocks hkp ports. I recommend using the keyserver (pool) that's recommended by the official GnuPG FAQ [1] or, even better, sticking to the default, unless you have a specific reason for not using those. If you are concerned about your privacy then you should rather look into using a keyserver on the Tor network. Regards, Ingo [1] https://gnupg.org/faq/gnupg-faq.html#new_user_default_keyserver signature.asc Description: This is a digitally signed message part.
Re: KDE GPG Keyserver
On Montag, 24. Juli 2017 12:51:42 CEST Boudhayan Gupta wrote: > Hi Kommunity, > > I've just set up a new HKP Keyserver at hkp://hkp.kde.org Is it sync'ed with the keyserver network, e.g. https://www.sks-keyservers.net/? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Applications Lifecycle Policy
On Tuesday 04 July 2017 23:34:20 Christian Mollekopf wrote: > What I meant to propose was more that instead of being initially in a > temporary location, > and then having to choose one of "proper" ones and go through review, > we would instead > start with a permanent location and then you "could" become part of a > release with requirements > and therefore review. In general I just think the barrier to release a > project from KDE infrastructure > should be lowered not raised. To me this sounds as if you want the KDE infrastructure to become a dumping ground for low-quality, untranslated stuff, i.e. just like github except with the KDE badge. Yes, I'm exaggerating, but essentially that's how I understand what you are saying. I agree with Albert, Ben, and Luigi, that we (at least the four of us) don't want this. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Fwd: Top 15 Mailinglists with messages in moderation
On Saturday 03 December 2016 07:26:11 Ben Cooksley wrote: > Hi all, > > It's that time of month again. > If you're the moderator for one of the below lists, please moderate > it's queue. > 16 kde-bugs-dist That's the list that receives automatic messages for new bugs, right? I'm wondering whether it couldn't be moderated automatically. I mean there's only a single legit sender: bugs.kde.org. Messages from any other sender could automatically be discarded. Just wondering... Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [kde-community] Results from the Mission Survey
On Wednesday 31 August 2016 21:57:10 Alexander Neundorf wrote: > Hi, > > On Monday 01 August 2016 12:05:25 Thomas Pfeiffer wrote: > > On 01.08.2016 11:20, Martin Steigerwald wrote: > > > Thank you for doing this. > > > > > > I am baffled by the extreme coherence between answers of contributors > > > and > > > of users. Seems like a perfect match. > > > > Indeed, I was equally surprised by that. It is true, though (I've just > > re-checked the data to be 100% sure). > > If someone says "KDE has lost touch with their userbase", we can > > confidently say "No, we haven't, look at that > > survey we just did!". At least judging from our attitudes. To the extent > > that our actions match our attitudes, > > we should be all lined up with what our users want. > > Our users should like a Mission Statement derived from these results, then > > > > :) > > so how do we proceed from here ? > Unfortunately I can't attend Akademy, but I guess there'll be some session > for working on the mission ? I don't think so. On https://akademy.kde.org/ there's no BoF registered for working on the mission. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [kde-community] Changes to mailing list behaviour
On Tuesday 02 August 2016 22:49:18 Ben Cooksley wrote:
> Hi all,
>
> Just a heads up on an upcoming change.
>
> As mentioned in an earlier thread, we'll need to change a series of
> settings on our mailing lists in order to maximise compatibility with
> mail providers which have enabled DMARC for their domains.
>
> Any changes the mailing list makes to an email, such as to the
> subject, mail body or certain headers (which varies from provider to
> provider) can cause breakage of DKIM signatures, and therefore a DMARC
> validation failure.
>
> Validation failures can result in messages being bounced or bulk
> (spam) foldered by recipients of messages, and likely harms the
> reputation of KDE.org mail infrastructure as well (impacting
> deliverability for all email). By altering messages and causing these
> failures, we effectively exclude people from our community simply
> because of decisions taken by their mail provider.
>
> We'll therefore be disabling stripping of any attachments or html
> bodies, modification of mail subjects, and removing any mail headers
> or footers which the list is adding into any mails. This will be made
> globally across all lists on kde.org infrastructure some time in the
> next week or two.
Please provide a list of all mailman settings you are going to change. I
guess at least the following settings will be changed:
subject_prefix ->
msg_header ->
msg_footer ->
scrub_nondigest -> No
filter_content -> No
What other settings are you going to change?
What about the Reply-To header munging related settings? Is Reply-To
protected by DKIM signatures?
What about include_sender_header ("Should the Sender header be rewritten
for this mailing list to avoid stray bounces? Yes is recommended.")?
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE Sysadmin and GPG Encryption
On Tuesday 26 July 2016 16:01:15 Luigi Toscano wrote: > On Tuesday, 26 July 2016 19:25:25 CEST Boudhayan Gupta wrote: > > 2) GPG doesn't simply encrypt the email, but also digitally signs > > it. > > Signatures are required to prove the authenticity of the email, and > > to detect if it was tampered with. However, given our email > > infrastructure, a GPG signature is meaningless. Anyone can create a > > GPG key, encrypt the email and send it out. To trust the public key, > > it would have to be either (a) distributed in a trustable way, which > > brings us to the same sitation as the SSH host key, (b) signed by > > another trusted entity (a person), after a face-to-face meeting, or > > (c) signed by members of a web of trust (which recursively requires > > one of (a) and (b)). Given we live in such physically diverse > > location (in fact, Ben lives in New Zealand; meeting enough KDE > > contributors face to face willing to sign his key is prohibitvely > > time, effort and finance consuming). If you can't establish trust > > of a GPG public key, the signature is meaningless. > > I strongly disagree with this. While it is complicated in Ben's case, > we had GPG signing party at the past Akademy and we can rebuild the > web of trust. Debian works like this. We can have one at the QtCon > (with also people from other communities including FSFE). So > *signing* the announcement emails should not be discouraged like it > is in this email. I very much agree with Luigi. IMHO, OpenPGP signatures are the most trustworthy kind of proof of authenticity (provided the key fingerprint has been verified in a way that's as secure as a face-to-face meeting and that the key's owner takes good care of her key). I disagree that it's difficult for the admin team to verify and then sign Ben key. For example, I think that this could be done via a voice chat provided the admin team regularly does voice chats and therefore recognizes Ben's voice. I don't care whether Ben's really called Ben and lives in New Zealand. All that I care for is that the admin known to us as Ben has sent the announcement with the new server fingerprint. And this I could have asserted easily, if the admin team would have cross- signed their OpenPGP keys and I would have verified the OpenPGP keys of one, or better two, admin in a keysigning meeting, e.g. at Akademy. I agree that encrypting the public information about the server fingerprint would not have made any sense, but I guess that the people who complained actually wanted the message to be signed rather than be encrypted. OTOH, claiming that "GPG encryption is fundamentally broken" is unacceptable. GPG encryption is anything but broken (if it's used in the right way, i.e. to encrypt information exchanged between parties who have verified their OpenPGP key). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
On Thursday 14 April 2016 16:18:30 Thomas Pfeiffer wrote: > On Donnerstag, 14. April 2016 15:26:10 CEST Mirko Boehm - KDE wrote: > > > On 14 Apr 2016, at 15:16, Jonathan Riddell > > > wrote: > > > relative metric of numbers of installs not absolute numbers. So > > > I added a machine-id to the URL it checks which is the unique > > > value set at install time by systemd (/etc/machine-id) so now it > > > has a good idea of being able to count the number of installs. > > > > > > But KDE cares about privacy and it's in our Vision and I don't > > > want to be accused of violating that. But currently I can't see > > > how this can violate users privacy any more than an IP address Storing IP addresses is controversial. Some people consider it personal information. That's why Google Analytics has a setting to set the last number of the IP addresses to 0. > > > can so I'm curious to hear what arguments might come up against > > > this. > > > > I believe that as long as we are transparent about it, this should > > be fine. Maybe, just maybe, there could be a way to turn it of for > > very privacy-sensitive users. > > Any potentially privacy-sensitive information transfer should be > opt-in, not opt-out. > I'd assume that the vast majority of users will allow it (given that > it's not personally identifiable and they trust their distro), but > opt-in puts you on the safe side. IMO it must be opt-in. One of my main reason for using Free Software is my (probably naïve) hope that Free Software does not phone home at all. At least not, unless I have explicitly allowed it to do so. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - final version
On Wednesday 16 March 2016 12:09:27 Sebastian Kügler wrote: > On Tuesday, March 15, 2016 10:53:03 PM David Jarvie wrote: > > This may read a bit better, although it does slightly alter the > > emphasis: > > > > "A world in which everyone has control over their digital life and > > enjoys freedom and privacy." Perfect. > I love this. It conveys what we want, and brings in a positive angle > to the freedom and privacy goals. +1 Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Saturday 27 February 2016 21:29:10 Alexander Neundorf wrote: > On Saturday, February 27, 2016 19:42:44 Stephen Kelly wrote: > > Alexander Neundorf wrote: > > >> "A world in which everyone has control over their digital life" > > >> (in -> over) seems a great vision. > > > > > > personally I'd like to have included that this can be done > > > > At least in my view (see my mail), a vision is not 'done' at all. It > > is only for inspiration. > > by "this can be done" I didn't mean "we will do the following to > realize this", but the "do" refers to the action of "having control > over their digital life". > > > > - independent from the commercial interest of companies > > > > Out of scope of the vision. See also my mail. > > > > > - available for everybody to use > > > > The vision Jos and I discuss says 'everyone'. See also my mail. > > Yes, right. > > > > - using solutions which can survive long-term > > > > Implied by the vision. > > > > Actually I take this back. It's not implied by a vision. The > > question is out of scope. > > > > A vision is not done, and a 'solution' is out of scope. > > Isn't this nitpicking on the language ? > > Let me take an example. Let's take whatsapp. > > It is not free of cost, but really cheap. So to me this more or less > qualifies as "available to everyone". Not ideal (free of cost), but > close. Let's assume a Whatsapp user would have fully satisfying > control over his privacy, his data, etc. > This would qualify as "control over his digital life". > Still, this is for me not enough. > > The user still depends on the company to continue the product, to not > change the terms and conditions, etc. > The user still is forced to use a device where the software runs, and > has lost if the app is e.g. not ported to the new mobile OS of the > day, to some new processor, etc. > To me, this is not satisfying. > > Or, IOW, the technology should be available similar to how pen and > paper are available today - very cheap, not dependent on a single > company, notes written today will be still readable in 100 years, the > knowledge how to create them is no secret, etc. > > Does that make clearer what I mean. IMO, WhatsApp cannot give its users control over their digital life precisely for the reasons you write above. The user is a WhatsApp's mercy. This is the exact opposite of user control. The user's digital life is under the control of WhatsApp. They can delete the user's digital life whenever they want to. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Wednesday 17 February 2016 12:46:26 Thomas Pfeiffer wrote: > On Dienstag, 16. Februar 2016 21:20:25 CET Valorie Zimmerman wrote: > > I think it could be stated more gracefully. How about: > > > > KDE aspires to a world where all users of our technology experience > > freedom, privacy and control over their digital lives. > > But doesn't that mean we don't care how many users we have, as long as > those users have freedom, privacy and control? I don't see much > ambition in this, to be honest. It sounds like "Hey, let's improve > the lives of a tiny niche of people!" to me. I had very similar thoughts when I read the above. I immediately thought "No, I don't want only all users of _our_ technology to enjoys freedom, etc." I want all 7+ billion human beings living on this planet (including the ISS) to enjoy freedom, privacy and control. Also, yesterday, after thinking again about what Alex asked/wrote, I wondered whether "KDE creates technology for a world in which everyone has freedom, privacy and control over their digital life." isn't a conflation of vision and mission. I wondered whether the actual vision isn't just the second part, i.e. "a world in which everyone has freedom, privacy and control over their digital life", and whether "KDE creates technology to enable everyone resp. the users of our technology to enjoy or experience this freedom, etc." isn't already part of our mission. Just wondering (and maybe repeating myself :-)). > > Short version: > > > > KDE: freedom, privacy, control of your digital life > > I do like the short version, Me too. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Tuesday 16 February 2016 23:26:58 Alexander Neundorf wrote: > On Monday, February 15, 2016 22:27:14 Thomas Pfeiffer wrote: > > On Montag, 15. Februar 2016 21:49:58 CET Alexander Neundorf wrote: > > > On Monday, February 15, 2016 18:36:18 Lydia Pintscher wrote: > > > > Hi everyone, > > > > > > > > A bit less than two weeks ago we sent the first draft for the > > > > community vision for KDE. We have gotten a lot of useful > > > > feedback and > > > > have now put this into a second draft. It reads as follows: > > > > "KDE creates technology for a world in which everyone has > > > > freedom, > > > > privacy and control over their digital life." > > > > > > just to make sure: this intentionally uses "technology" and not > > > "software" ? > > > > Yes, this is intentional. Since the vision is supposed to merely > > outline the future we want to live in, not how to get there, we did > > not want to restrict ourselves to software. > > On Tuesday, February 16, 2016 19:53:47 Riccardo Iaconelli wrote: > ... > > > We explicitly re-labeled it "technology" to include icons, > > wallpapers and other kind of content which might not be software. > > Is this maybe the reason why we are having those weird discussions, > and we actually have the same in mind ? > > See, here is what the word "technology", used in this context, tells > me: a community, which is well known as a *software* community, now > doesn't use the term "software" anymore. Instead it now uses > "technology". > There must be a reason why they decided not to use "software" anymore. > To me this means, this community decided not to emphasize that it > does software anymore. So it probably also does hardware now, > probably having stuff like Arduino, maybe RPi-based hardware and the > maker-community in mind, maybe more. I would also expect then a plan > for hardware in the mission then. > > What I want to say, in my opinion a guiding statement like a vision > should emphasize the main strengths, the main direction, and doesn't > need to be worded as broad so that it really covers every nuance. The vision is not a guiding statement, the mission is. It's the mission which details/specifies how we intend to fulfill the vision. IOW, the mission statement gives the direction you are seeking for. The mission statement would probably state that we will write software with focus on UI applications to reach this goal. > On Monday, February 15, 2016 22:27:14 Thomas Pfeiffer wrote: > > If, say, 10 years down the road, hard- and software is so much > > intertwined that we cannot influence the future with software alone > > anymore, we don't want people to say "But our vision says we only > > do software!". > > Since we are talking about technology, especially a fast evolving > technology, I'm sure a vision for a technology project could also be > updated. :-) Yes, but if we can avoid it (by using a broader vision in the first place), then we should avoid it. OTOH, the mission is supposed to be updated, e.g. if the world around us changes in a way which makes it unwise not to start creating hardware to fulfill our vision. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Monday 15 February 2016 19:29:32 Ingo Klöcker wrote: > On Monday 15 February 2016 18:36:18 Lydia Pintscher wrote: > > Hi everyone, > > > > A bit less than two weeks ago we sent the first draft for the > > community vision for KDE. We have gotten a lot of useful feedback > > and > > have now put this into a second draft. It reads as follows: > > "KDE creates technology for a world in which everyone has freedom, > > privacy and control over their digital life." > > I like it. My only nitpick is with "freedom, privacy and control over > their digital life", because when reading it, I automatically parsed > it as "freedom over their digital life, privacy over their digital > life and control over their digital life" which doesn't make sense. > [snip] > > What about "[...] everyone has freedom and privacy and control over > their digital life". It's a bit convoluted, but I think it better > avoids the misreading. One more idea: What about replacing "has" with "enjoys", i.e. "KDE creates technology for a world in which everyone enjoys freedom and privacy and control over their digital life." This could even be read two ways (at least by a non-native-English- speaking German like me): Everyone enjoys freedom, etc. in itself. And, everyone enjoys using our technology while enjoying freedom, etc. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Monday 15 February 2016 18:36:18 Lydia Pintscher wrote: > Hi everyone, > > A bit less than two weeks ago we sent the first draft for the > community vision for KDE. We have gotten a lot of useful feedback and > have now put this into a second draft. It reads as follows: > "KDE creates technology for a world in which everyone has freedom, > privacy and control over their digital life." I like it. My only nitpick is with "freedom, privacy and control over their digital life", because when reading it, I automatically parsed it as "freedom over their digital life, privacy over their digital life and control over their digital life" which doesn't make sense. What about "[...] everyone has control over their digital life, freedom, and privacy". Hmm, no. This can be misread as "control over their digital life, control over their freedom, and control over their privacy". What about "[...] everyone has freedom and privacy and control over their digital life". It's a bit convoluted, but I think it better avoids the misreading. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Fwd: KDE Vision – towards “wholesame” solutions
On Sunday 14 February 2016 23:57:56 Alexander Neundorf wrote: > On Saturday, February 13, 2016 13:12:52 Lydia Pintscher wrote: > > On Sat, Feb 13, 2016 at 7:45 AM, Olaf Schmidt-Wischhöfer wrote: > > I agree that integration within our projects is important. And I > > believe it has suffered lately as the cohesion inside KDE became > > less. My gut feeling is that this should go in the mission. > > > > > I would suggest a sentence like the following: > > > “KDE aims to offer complete, well-integrated solutions – while > > > connecting different platforms, devices and online services.” > > > > That sounds good to me. > > To me too, but I still miss the reference that it is about software > with graphical user interfaces (GUI's can also have gesture or voice > input etc.), which Olaf seems to imply too. > I mean, we are not targetting e.g. sensor networks built from 8bit uCs > communicating to some big online server, with no user intervention > (which would fit that description too), or are we ? Please don't speak for me. You've made it absolutely clear that _you_ are only interested in GUI. That's totally fine. We need people who focus on (G)UI applications. But we also need people who focus on non- GUI-stuff. A large part of Frameworks 5 is non-GUI-stuff. Akonadi (and its spin-off) is non-GUI stuff. Therefore, I'm against a-priori excluding anybody who is not interested in (G)UI applications from KDE by restricting ourselves in our vision to (G)UI applications. Of course, the mission statement can mention that we _mostly_ (but not entirely) focus on (G)UI applications and supporting libraries and services. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - first draft for discussion
On Sunday 14 February 2016 20:16:57 Lydia Pintscher wrote: > I am currently going through all the feedback again. Thanks for all > your really useful feedback, Ingo. We'll take over a lot of it for > the second draft. > > On Fri, Feb 5, 2016 at 5:00 PM Ingo Klöcker wrote: > > So, how about > > "KDE enables everyone to control their digital life without > > compromising their > > privacy." > > It seems to me this is pitching control against privacy. If you want > more control you need to give up your privacy. I cannot follow you. Why do you think that you need to give up your privacy if you want more control? I think the opposite is true. If you have full control over your digital life, then (for me) this implies that you have full control over your data. So, we could probably even remove the "without compromising their privacy" part from the vision statement (but we should then add it to an explanatory second sentence similar to how Oxfam explains with a second sentence what they mean by "a just world without poverty"). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - an alternative draft for discussion
On Monday 08 February 2016 17:07:26 Alexander Dymo wrote: > > We define the goal for KDE not in technical terms, but in terms of > > Freedom, user control and privacy. > > I understand this part clearly. I just say that this goal is too > broadly defined, and, therefore hardly reachable by a single > organization like KDE. I think you misunderstand what (the purpose of) a vision is. Let's look at an example. Oxfam's vision is "a just world without poverty". https://www.oxfam.org/en/our-purpose-and-beliefs This goal is hardly reachable by a single organization like Oxfam. > Most free software communities, including KDE, already work towards > that goal. Exactly. Just as many other NGOs are working towards the same goal as Oxfam. > Defining it in writing as the goal of KDE adds neither value nor > attractiveness to KDE as a project. Well, that's debatable (and I disagree with it), but I hope you agree that not defining it in writing as the goal of KDE can only reduce KDE's attractiveness (because some potential contributors might fail to see our goal and decide to join another community). I think your concern is that the vision does not function as differentiation from other free software communities. That's correct, but setting KDE apart from other free software communities is not the purpose of the vision. What differentiates us from other free software communities is not our goal, but the way we want to reach (resp. approach) this goal. And this way should be spelled out in the mission. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - an alternative draft for discussion
On Friday 05 February 2016 23:16:06 Alexander Neundorf wrote: > > A possible vision for KDE derived from your draft but being more in line > > with the example would be > > "KDE enables everyone to make best use of their digital devices without > > compromising their privacy." > > I have to admit, while this certainly matches better the definition of a > "vision", and I agree with it, to me, as a boring German engineer, this > sentence alone is not useful. > When I read it, I think, Ok, that's an introduction, marketing, nothing > concrete, now where is the real stuff ? Such a sentence alone doesn't make > me excited, nor curious. Then it's probably not good/catchy/interesting enough. Let's look at a few examples: Oxfam: A just world without poverty Feeding America: A hunger-free America Human Rights Campaign: Equality for everyone > I have seen enough of those slogans, everybody has > one, they are usually "deep", "thought provoking", "engaging", etc., I'm > actually tired of those. Then a vision is probably not for you. That'd be sad, but maybe you are really looking for a mission, i.e. a concrete plan for action. > Yes, we can tweak the first few sentences so they match that format. > I think an important point this draft wants to make is to spell out what KDE > is trying to achieve in concrete software categories, so a reader > understands what we are doing, and doesn't have to guess and assume. > As I said above, that's maybe vision+mission ? Yes. I think the vision statement needs to be complemented by a mission statement. But I think, before we tackle the mission statement, we should nail down the vision. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Differences between proposed vision drafts (or "inclusive" vs "focused")
On Thursday 04 February 2016 21:16:41 Alexander Neundorf wrote: > the vision draft we present here is not a long term vision which changes the > future of computing. > It presents ambitious, but realistic goals for the next few years. > Currently KDE applications and the desktop are successful on desktop Linux > (and BSD etc.). But there is so much territory to conquer beyond that, while > (for now) staying focused on GUIs. > Let's make KDE applications as well known as Firefox or LibreOffice. > > (This also implies that a vision statement needs updating over the years as > circumstances change.) Please (re-)read https://topnonprofits.com/examples/vision-statements/ and tell me which of those 30 vision statements you think need "updating over the years as circumstances change." As I wrote in my other message, I believe that what you propose is more a mission statement. And mission statements do indeed need to be updated from time to time. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Should we allow non-KDE projects to participate in GSoC under KDE?
On Wednesday 03 February 2016 14:58:54 Martin Klapetek wrote: > So I'd like to have this cleared - does the community agree to > have non-KDE projects, those that do not follow the Manifesto, > participate in our GSoC this year and in the following years? > > Imho this goes against the Manifesto as the projects gets to > "enjoy the benefits" without the complying with "commitments" > of the Manifesto. It's also less transparent overall (not able to > monitor progress as it's not on KDE infrastructure), can lead > to cheating and possibly kicking KDE out of GSoC in the worst > possible outcome. > > On the other hand, every accepted project gets the mentoring > organization some extra money, which is always handy. I'm sorry, but I completely lack the necessary information to give my opinion in this matter. From the thread I gather that there have been issues in the past with at least one non-KDE project. But without a list of the pros and cons and a short summary of the past experience with allowing non-KDE projects how am I supposed to decide? I'm dubious about taking the Manifesto as binding document to make the decision although I think that it makes sense to use the Manifesto for guidance. I don't believe that there should be a hard "You are in./You are out." rule. In any case, I fully trust the GSoC team to make the decision that's in the best interest of KDE, for each non-KDE project individually. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - first draft for discussion
On Wednesday 03 February 2016 10:10:27 Lydia Pintscher wrote: > The first draft reads as follows: > "KDE, through the creation of Free software, "through the creation of Free software" sounds like (part of) a mission statement to me. I'd leave it out of the vision statement. > enables users IMO "users" is too technical as term for a vision. I suggest to replace it with "everyone". > to control their digital life. I like this. > KDE software enables privacy, Yes! > makes simple things easy and complex scenarios possible To me this sounds very not-saying-anything in a complicated way. Also, I think it superfluous because it's already contained in "enables [...] to control their digital life". > while crossing device boundaries." While it may be nice to mention this it's probably better moved to the mission statement. So, how about "KDE enables everyone to control their digital life without compromising their privacy." Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - an alternative draft for discussion
On Wednesday 03 February 2016 22:05:20 Alexander Neundorf wrote: > KDE is an end-user focused, openly governed community of free software > enthusiasts This is a description of what you (and me) think KDE is (or should be), but not what its goal (vision) is, unless you think that our goal should be to be "an end-user focused, openly governed community of free software enthusiasts". > that strives to provide graphical user interfaces and > applications for end-users for all types of computers across the device > spectrum: desktops PCs, laptops, tablets, smartphones, etc. Providing end-user software for all kinds of devices sounds like a mission statement to me, i.e. like a plan to reach some goal. It totally lacks the What and Why, i.e. the greater goal. Why do we strive to provide ...? What is in it for the end-users that they do not get from any other software vendor? > We believe that software should be free and respectful of the privacy of our > users. This sentence seems to hint at a vision I could identify with. Free Software that protects the users privacy. > Our values are stated in the KDE Manifesto. This sentence isn't really part of a vision or mission statement. It makes sense to put it somewhere, e.g. on the page which shows our vision (and mission), but not as part of the vision (or mission). Since Mirko posted a link to this website, I assume that you have read the list of 30 example vision statements. https://topnonprofits.com/examples/vision-statements/ I will cite the vision statement of Creative Commons because they are closest to us: Creative Commons: Our vision is nothing less than realizing the full potential of the Internet — universal access to research and education, full participation in culture — to drive a new era of development, growth, and productivity. As you can see it does not say what Creative Commons is. Neither does it mention any plans how to reach their vision (e.g. by providing licenses). The same is true for the other 29 examples listed on the above page. A possible vision for KDE derived from your draft but being more in line with the example would be "KDE enables everyone to make best use of their digital devices without compromising their privacy." "digital devices" most likely isn't the best term, but I couldn't think of a better concise term for "all types of computers across the device spectrum". Maybe "computing devices"? Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] [RFC] Changing our mailing lists to be DMARC compliant
On Saturday 05 December 2015 08:00:31 Ben Cooksley wrote: > Hi all, > > As you may be aware, mail providers globally are slowly beginning to > enforce a new email authentication standard known as DMARC. Please see > https://dmarc.org/overview/ for more information on it. > > To ensure people are able to subscribe to, send mail to, and be able > to read all mail they receive from our mailing lists we will need to > make some changes. If we do not act, then legitimate mail may end up > being bounced or placed in the spam folder by providers (which could > also lead to people being removed from mailing lists by Mailman, in > addition to mails being missed) > > In short, we will need to cease altering the subject and bodies of > mails. Other than HTML stripping, kde-core-devel is already compliant > in this regard. > > Any objections or comments on this? Hmm. Does this mean that we will have to stop adding the mailing list information footer? Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Blacklisting of free.fr
On Sunday 27 September 2015 09:32:32 Ben Cooksley wrote: > Hi all, > > In 48 hours, i'll be blacklisting the entire of free.fr from KDE email > infrastructure. This is necessary as it has become apparent that the > security of @free.fr addresses is quite poor - allowing for > subscribers accounts to be targeted, hacked, and then used to abuse > KDE infrastructure. > > Please note that this is not the fault of the people using @free.fr > addresses - despite multiple attempts to use different passwords, etc. > their accounts continue to be breached and customer service is > completely unresponsive to complaints surrounding this issue. > > If anyone has any queries regarding this, please let us know. Shall we, the list admins, inform the corresponding subscribers resp. the list(s)? If yes, then it would be great if there was a web page stating the current status and possibly also the past status, so that we can point the affected subscribers to this page. This web page might also put some public pressure on free.fr. Otherwise, I'll refer to your message (https://marc.info/?l=kde-community&m=144329957703751). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On Saturday 19 September 2015 00:17:00 Boudhayan Gupta wrote: > When I first thought of Selfie, I thought of the following: > > * It makes perfect sense (screen taking a self portrait). > * While most other applications and projects take an "appropriate" and > subdued approach to naming their apps, this would be very "with the > times" and culture-appropriate, at this point. > * A fresh jolt from the dreary and monotonous world of coding? > > While it is a bit late now (the repository rename was done yesterday), > I'm still in love with the word Selfie (for the above reasons and > more). I'm heavily considering requesting another rename to Selfie. "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton > Are there any strong objections? My only objection is against the process of name finding. Boudhayan, please choose whatever name you like the most and go with it. Please stop asking other people for objections because you will never reach unanimous assent (not only in KDE, but in any community larger than 1). It's good manner to ask people for their opinion (which you did with the first message in this thread), but once everybody had a chance to make himself heard, you, the thingy's maintainer, have to take the decision (and stick with it). It seems, that you like Selfie the most. So, I suggest that you run with it and stop this thread that's getting sillier and sillier by the minute. ;-) Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On Monday 24 August 2015 18:16:41 Boudhayan Gupta wrote: > A fairly universal sentiment is that no one seems to like KScreenGenie > as a name (including yours truly). > > So I'll leave this up to the community. I'm currently considering > naming it Safelight, with other names I've considered being (in order > of preference) Selfie (a screenshot is literally a computer taking a > selfie), Iris, Kapture, KScreenshot and Snap. After reading the first paragraph about how renaming it to KSnapshot is not a good idea, I thought that KScreenshot would be a good alternative name. And then I saw that it's also on your list. So, +1 for KScreenshot. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Program to show presenter time remaining countdown for Akademy talks
On Thursday 25 June 2015 10:12:08 Kenny Duffus wrote: > Hi > > We are looking for someone with some free time to work on a small > program to take the Akademy schedule which is available in iCalendar, > xCal, XML and JSON formats > > https://conf.kde.org/en/akademy2015/public/schedule > > And show a count down of talk time for the presenter on a small 3" > 480x320 LCD on a Raspberry Pi If a simple HTML+JavaScript "program" running in a web browser is acceptable then I can write it. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure
On Wednesday 17 September 2014 18:17:14 Christian Dávid wrote: > Am Dienstag, 16. September 2014, 16:31:23 schrieb Ingo Klöcker: > > No, the problem is not technical, but legal. If we (resp. the KDE > > e.V. as our legal representative) would host a Kolab instance then > > the KDE e.V. would most likely become an email provider (according > > to German law). And being an email provider in Germany comes with > > lots of legal requirements and responsibilities. > > Hi Ingo, > > I could not find any laws or regulations for email providers in > Germany. Can you tell me where to find them (I speak german)? Among others, I think the Telemediengesetz (or whatever it's called nowadays) applies. I got my "knowledge" mostly from reading the c't. Please ask a lawyer for details / more information. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure
On Tuesday 16 September 2014 16:38:38 Thomas Pfeiffer wrote: > On Tuesday 16 September 2014 16:31:23 Ingo Klöcker wrote: > > OTOH, if we want to host our own Kolab instance (which we probably > > do > > not want to do because see above) then I don't see what needs to be > > worked out with Kolab Systems. > > Well, maybe them helping us to set up Kolab on our infrastructure in > case we have difficulties with that. The very helpful Kolab.org community (https://kolab.org/community) is probably a better address for asking for help. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure
I'm replying to Aaron's and Thomas's message. > On Monday 15 September 2014 16:24:55 Aleix Pol wrote: > > - Kollab: This was already discussed recently in this list, it > > doesn't seem feasible to offer a Kollab instance to the membership > > (let alone the whole community) so I don't think we want to depend > > on it. That said, We might want to ensure we have all the tools to > > use the standards we can rely on, then ensure Kollab is capable to > > interact with them, given it's one of the few platforms we could > > have a say. On Monday 15 September 2014 20:11:32 Thomas Pfeiffer wrote: > Given that Kolab will power the whole of Munich administration soon, I > wonder why it wouldn't work for the - big, but still tiny compared to > that - KDE community, but I am not an admin (I really should > establish the IANAA and IANAD acronyms), so I may totally miss the > difference. Would it require massive server or bandwidth resources > which we don't have? No, the problem is not technical, but legal. If we (resp. the KDE e.V. as our legal representative) would host a Kolab instance then the KDE e.V. would most likely become an email provider (according to German law). And being an email provider in Germany comes with lots of legal requirements and responsibilities. On Monday 15 September 2014 20:04:45 Aaron J. Seigo wrote: > I'm sure we can work sth out with Kolab Systems. Not sure what you mean. AFAIK, nothing needs to be worked out with Kolab Systems. We need to get the ball rolling, not Kolab Systems. If we want to use MyKolab.com: About 3 months ago Georg Greve has sent a message to the KDE e.V. mailing list (sorry, this list is restricted to KDE e.V. members) with a special offer for KDE people who want to use Kolab Systems' MyKolab.com. OTOH, if we want to host our own Kolab instance (which we probably do not want to do because see above) then I don't see what needs to be worked out with Kolab Systems. If you have something else in mind, then please elaborate. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Berlin - Brno road trip
On Wednesday 06 August 2014 21:33:40 Milian Wolff wrote: > I just booked this via the Bahn.de website for ~60€ (with a Bahncard > 25): > > Berlin Hbf (tief) > 04.09. ab 12:46 3 > EC 177 > Brno hl.n. > 04.09. an 20:19 I plan to take the same train (though only from Praha to Brno). Once you have a reservation tell me were I can find you and the others. :-) Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Fundraising
On Friday 18 July 2014 13:30:36 Cornelius Schumacher wrote: > On Friday 18 July 2014 11:09:27 Jos Poortvliet wrote: > > Or support of course, might be the best. After saying each of these > > words 10 times, however, they all sound silly so now I'm confused. > > The best thing is to be open and direct. If you want to get money, ask > for money. Any complicated psychological twist will just make it, > well, complicated. So I think "donate" is the superior term here. I also think so. AFAICT, the "Donate" button seems to be the quasi- standard used across the internet (if only because "Donate" is what's used by default by PayPal). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Tuesday 12 November 2013 21:33:05 Kevin Ottens wrote:
> Hello,
>
> On Sunday 10 November 2013 21:46:41 Ingo Klöcker wrote:
> > On Sunday 10 November 2013 18:28:58 Kevin Ottens wrote:
> > > That's what this email is about, I'd like to apply the attached
> > > patch, it's mostly about small scale changes. I don't see
> > > anything which could be controversial in there.
> > >
> > > Any opinions on this? I'd like to collect feedback before
> > > proceeding
> > > with a vote of the e.V. membership and then a push.
> >
> > It's really a minor point, but I don't understand the change of
> >
> > * Stand on the shoulders of giants
> >
> > to
> >
> > * To stand on the shoulders of giants
> >
> >
> > Why does this phrase now begin with "To"+verb when all other phrases
> > (still) start with a verb without leading "To"?
>
> As Aaron noted, it makes use of an active form instead of passive. To
> be honest it's kind of subtle to me as a non-native speaker I don't
> mind either way. :-)
Same here. I don't get why "Stand" is passive since I read it as "You
stand [...]" which is active (AFAIU) while "To stand" is neither an
active form nor a passive form but the ("to" +) infinitive from. :-)
> > IMHO the leading "To" makes the phrase sound less personal. When I
> > read the other phrases I mentally add a "You" or a "You can", as in
> > "You can make use of KDE infrastructure [...]", "You benefit from
> > [...]", "You get support from [...]", etc. The leading "To"
> > prevents this.
> I don't see why the leading "To" would prevent that.
>
> Now indeed we might have inconsistencies regarding passive vs active.
> If you don't mind, I propose we ignore that point for now, and once
> we're done with this bunch of edits, we try to get a native speaker
> attached to a chair until (s)he make the pages consistent in that
> regard.
Agreed.
Regards,
Ingo
signature.asc
Description: This is a digitally signed message part.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Discussion: KDE Manifesto, "web services"
On Monday 11 November 2013 12:41:29 Kevin Ottens wrote: > On Monday 11 November 2013 10:44:35 Aaron J. Seigo wrote: > > On Sunday, November 10, 2013 19:12:29 Kevin Ottens wrote: > > > "Projects that do not use KDE infrastructure for their online > > > services must > > > work with the KDE sysadmin team on an agreement to ensure > > > continuity."> > > Perhaps it could be stated in the positive: > > > > * Online services associated with the project are either hosted on > > KDE infrastructure or have an action plan that ensures continuity > > which is approved by the KDE system administration team > > > > it’s a bit longer than your nice, tight treatment, but it notes both > > possibilities (KDE infra or not) in the positive and implies that > > KDE > > infrastructure is desired. it also moves the “must work .. on an > > agreement”, which simply says they must be working on such a thing, > > to being a commitment as they “have an action plan" > > Indeed I like that wording better[*]. A bit longer indeed but still OK > compared to what we have right now. > > Anybody disagrees with that proposal? Is the "which is approved by the KDE system administration team" really needed? I think it could be left out. If the fact that the action plan needs to be approved should be stressed then "approved" could be added before action plan, i.e. * Online services associated with the project are either hosted on KDE infrastructure or have an approved action plan that ensures continuity Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Sunday 10 November 2013 18:28:58 Kevin Ottens wrote: > That's what this email is about, I'd like to apply the attached patch, > it's mostly about small scale changes. I don't see anything which > could be controversial in there. > > Any opinions on this? I'd like to collect feedback before proceeding > with a vote of the e.V. membership and then a push. It's really a minor point, but I don't understand the change of * Stand on the shoulders of giants to * To stand on the shoulders of giants Why does this phrase now begin with "To"+verb when all other phrases (still) start with a verb without leading "To"? IMHO the leading "To" makes the phrase sound less personal. When I read the other phrases I mentally add a "You" or a "You can", as in "You can make use of KDE infrastructure [...]", "You benefit from [...]", "You get support from [...]", etc. The leading "To" prevents this. Other than that the changes look good. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
