Re: is a BSL licensed service acceptable for sysadminy use cases?
On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote: > So you can use old sentry versions, which are open source. If you are referring to old snapshot of old sentry version then I would say it is fairly impossible to use it given using old sentry version would also mean that we need to use older API version and it also means older libraries for client side (for sending data). It is basically a dep hell which is impossible to overcome. With my sysadmin hat on, I would absolutely oppose to having installation of 3 year old unmaintained software (and its equally outdated dependencies) that are guranteed to get no upates whatsover on our servers in productions. Regards. signature.asc Description: This is a digitally signed message part.
Re: The status of freenode (the IRC network used by KDE)
Hi Christian, First of all thank you very much for your work, and transparency to report this. ❤️ On Wednesday, 19 May, 2021 2:04:26 PM IST Christian wrote: > I tried my very best both to not drag KDE into this situation plus to keep > the network running as I helped running it for the past 10 years, and to > keep your data safe in the hands of the volunteers that curated it for > decades. Personally speaking at moment I am not concerned about public development channels *that much*, but rather private channels including those used by sysadmin, board and other teams should be first priority. We should, either migrate them to new IRC network or migrate them to different platform and in addition disconnect bridges with other networks for example, matrix/telegram temporarily. And yes, what is recommended by other staffers regarding your personal data/ password/email also stands. Thanks.
Gitlab feedback and discussion
Hello community members, Recently we realized that there is no specific place to discuss various issues with KDE's GitLab instance. So I have created (well re-used) a channel where this can be done. You can join on, - IRC #kde-invent - Telegram https://t.me/kdeinvent - Matrix #kde-invent:kde.org This is a place to discuss the issues and feedback related to the KDE's GitLab instance, how we can improve it further. Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Information regarding upcoming Gitlab Migration: clarifications
Good afternoon, [Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] I want to clarify some bits for which we have gotten a questions about, - Non unique naming: There's some teams which prefer if we dropped the namespace- part from their name which we have added. While currently this does not result in the naming conflict right away, we realize this will cause it at one point, for example, maui-dialer -> maui/dialer plasma-dialer -> plasma-mobile/dialer To minimize the impact of the Gitlab move we won't be doing such renames which introduce non-unique names right away. But we would prefer if the existing tooling or infrastructure is ready for this kind of cases at later point. Only way to enforce non-unique naming is one big KDE/ subgroup which we want to avoid. Current naming in the repo-metadata branch[1] I've pointed does not reflect those renames, as we are not planning to do those renames right away during gitlab move, but at a later stage. - Existing configurations: we want to reduce impact on existing release schedule, and existing developer workflow, therefore we will continue to privide the existing anongit.kde.org and git.kde.org (although this will be read-only) with current flat structuring for 3 weeks after actual migration, which will keep the existing scripts/clones working enough to give developers time to change to the new structure. We will also try to provide a script which allows you to migrate your existing clones to new repo paths and as mentioned by Ben in other message, potentially a git-kde script which would allow you to clone individual repository without knowing it's namespace (provided that there is no conflict of it's name). like "git kde karchive" - Translations: we will co-ordinate with the translations team to let them adapt their tooling to updated structure as this requires changes on their side how translations are stored in svn repository Thanks! [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hello Johan, On Tue, Apr 28, 2020 at 06:18:14PM +0200, Johan Ouwerkerk wrote: > I would like to propose that the sysadmin team pick the layout that is > easiest to *implement*, which I suspect is also the most like what we > have now, and that we live with that. Unless there is a pressing need, > like real hard data that we're losing contributors because they can't > find our repos or a sysadmin burden that would be excessively higher > than otherwise... let's keep things as simple and straightforward for > syadmin and tooling maintainers to implement during the Gitlab > migration. > > Let's worry about the perfect project layout once we've identified the > need. That way it's a lot easier to garner consensus for a practical > solution that isn't just a wishlist of all the features we would like > but which Gitlab may or may not have and which tooling is probably > completely unprepared for. Going with flat namespace right now and then making whole thing non-flat means double amount of work for sysadmins, once to migrate everything on invent, and then later to their final home. It is equal amount of work for contributors, once to migrate to invent URL and then migrate to new grouping. If setups needs changing, I'd rather change it now at once then later. > By all means disregard this stuff if the pressing need has already > been identified and I've either neglected to read e-mails properly or > wasn't aware for some other, possibly historical, reason. We have gotten a request for namespacing from projects on multiple occassion, in cgit our workaround has always been that we prefix the repo name with namespace- (i.e wikitolearn-courses-backend). While this works out with our current workflow, it is not really optimal. I've also mentioned various new contributor focused requirements which lead us to this proposal for structuring in previous emails. -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Adriaan, On Tue, Apr 28, 2020 at 01:08:33PM +0200, Adriaan de Groot wrote: > A tool-like actor that I don't think has been mentioned so far is "existing > checkouts". I have a src/kde with all the bits I've looked at "recently". > There may even be some SVN checkouts there -- I'm willing to forget about > those. Surprising and annoying me every time I update those sometime in the > future is not good, but it's only going to annoy me once (per repo, so at > most > 143 times for my clones). We have a plan to provide a script which can change remotes in existing clones. (It would take a top-level directory path for all your clones). > Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. > I'm intermittently interested in the source of some random part of KDE -- > generally because it's mentioned on IRC -- and then I need that source where > I > can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source- > please' doesn't matter much. > > If there's any compiling to be done, the less magic there is between me and > the compile, the better. > > So, yeah: `git clone kde:x` all the way, but I'm also not really invested in > the structure of the label x, or the precise configuration of kde:. > > > > Now, if a simple(ish) script can be created to make > > something akin to the kde: rewriting work, even if what it really does is to > > search gitlab and create a clone with the appropriate command, i could deal > > with that, but having the ability to simply ask for the project name is > > more than a little useful. > > I think we shouldn't underestimate how names are a social construct, though: > the current flat structure comes after a structured SVN naming epoch. But I'd > totes +1 a search-and-redirector, especially if it means I can write `git > clone kde:peruse` and the resulting .git/config has followed the redirects > and > whatnot and ended up with `url: kdeforreal:audio/peruse` One thing to remember is, you can't really have a dynamic insteadOf URL setup. Besides, even if we had a everything under KDE namespace I'd find a setup for this weird enough. Let's assume that everything is under invent.kde.org/kde (and invent.kde.org/sysadmin and invent.kde.org/websites as it is right now). Now you add a following snippet in gitconfig, [url "https://invent.kde.org/KDE/;] insteadOf = kde: [url "g...@invent.kde.org:KDE/"] pushInsteadOf = kde: Which is slightly modified version of the existing kde: URL helper shown here, https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes Now this is perfectly fine for the something which is kde/ so you can do git clone kde:krita and it would happily replace 'kde:' part with 'https://invent.kde.org/KDE/' and would clone 'https://invent.kde.org/KDE/krita' But, now things get interesting when you want to clone the docs-krita-org which is in the websites/ namespace. We will have to keep this things in separate namespace for policy reasons (and same goes for sysadmin stuff). How would you clone docs-krita-org? git clone kde:../websites/krita-org ? add a separate prefix for websites and sysadmin? Let's assume that you added snippet for sysadmin and websites, it's just 8 more lines after all, [url "https://invent.kde.org/websites/;] insteadOf = websites: [url "g...@invent.kde.org:websites/"] pushInsteadOf = websites: [url "https://invent.kde.org/sysadmin/;] insteadOf = sysadmin: [url "g...@invent.kde.org:sysadmin/"] pushInsteadOf = sysadmin: Does this solve all use-cases? I believe no, it still does not support the personal repositories of users. So you also need to add 4 more lines for your own user, and 4 for each user whose repository you want to clone. What our workflow with the kde: prefix so far had been really useful I agree, and I will miss it, but with departure of gitolite which allowed repositories at top-level, we can't easily support this, and we have to accept it. Perhaps solution suggested by Ben in his email could be useful instead and in addition generic invent: snippet which does not include any namespace. [url "https://invent.kde.org/;] insteadOf = invent: [url "g...@invent.kde.org:"] pushInsteadOf = invent: > (That said, bigflatlistofrepositories.kde.org .. or maybe call it > cgit.kde.org > .. could be a particular view onto gitlab which does flattening and search, > but only if there's people around to create it and maintain it) Just to clarify, sysadmins have no plan to support or maintain the cgit instance once we migrate to Gitlab. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Olivier, On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote: > >Because in order to search for something, you need to know it exists. > > > >If you are just casually browsing, then the search can't help you. > > I don't think people casually browse our repos. What use case is more likely > to happen and do we want to support? We don't really want to discard use-cases just because it does not suit our workflow. That is not how we are going to gain new contributors, we should value each contribution, be it drive-by contribution, or focused contribution towards one single project. > Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia > section. After carefully reading the code of two applications and three libs > he starts contributing to Elisa. > > Use case 2 : While using her Ubuntu installation of Elisa / while reading on > reddit about Elisa, Jerry decides to try to contribute to this project/fix > this bug that itches her and searches for it in KDE's forge. Let me add a some more usecases, some of which I've been dealing with in project I maintain. Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma Mobile applications source code Use case 4 : Tom is a student in Germany and is interested in contributing to wikitolearn, and he asks where can I find code of the wikitolearn? Suggestion offered by sysadmin team does not cater to one single use-case, but offers a way to provide a solution to all 4 usecases. For Plasma Mobile team or Wikitolearn team it would be much easier to refer contributors to the https://invent.kde.org/plasma-mobile or https://invent.kde.org/wikitolearn then tell them to go to https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma Mobile. > On the other hand, I think the discussion about spotting open merge requests > (in a derived thread from this one) should be answered, being by relevant > tags, subgroups or whatever. (super personal note) Ironically, Usecase 1 is how I started contributing to KDE 7 years back. While I was inspired by battery monitor re-design in 4.11 release, I wanted to work on "something" so I did literally browse through various repositories to find something where my technical capabilities were enough to work on [1]. Back then it was projects.kde.org (chiliproject installation). [1] https://blog.bshah.in/2013/09/01/hello-planet/ -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Ingo, On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote: > > > 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. No, sadly this does not work, I just tested this, I have two different groups here - https://invent.kde.org/sysadmin/test/test1 - https://invent.kde.org/sysadmin/test/test2 test1 have a repo called foo under it, which is shared with the test2 group. When someone visits test2, they are not offered the list of the shared repositories but they are instead offered the empty page. One have to click on Shared repositories tab to actually see the list. https://invent.kde.org/groups/sysadmin/test/test2/-/shared This defeats the purpose of the creating subgroups (offering easy reachability). -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 06:02:19PM +0530, Piyush Aggarwal wrote: > How long do redirects like this one work? If they will keep working > indefinitely, then maybe we can have all the repos at flat URLs for once > and then move them to respective subgroups? That way we will have access to > our simple URLs through a redirect as I mentioned before, and also the > ability to manage the Invent as recommended by sysadmins. Documentation says that redirect will stay as long as original name is not claimed by the new group, user or project. However there's multiple problems with the workflow of moving something to the KDE/ namespace first and then to respective group. - There will be empty KDE/ group visible which would be confusing for visitors - Workflow of the importing repository becomes complicated without any advantage IMO. For instance to import bshah/kframework into frameworks/ I've to first transfer it's ownership to KDE and then transfer it's ownership to frameworks/ group. - But most importantly, this breaks with the non-unique leaf repository names feature offered by the proposed structure. So, There could be maui/documentation and wikitolearn/documentation. But we would have single KDE/documentation redirect -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hello On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote: > On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote: > > > [1] > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > Maybe it would make sense to keep a kde top-level group for some of the > bigger projects that really don't fit in a category -- I don't think Krita > fits in the graphics group, since we never ever do anything with any of the > other repositories in that category. Slightly off-topic, but, in general idea is that we want to get away from the KDE is software, and more towards KDE is community and people, having a KDE/ namespace is step backward IMHO. > I have to admit, I also dread updating instructions and checkouts everywhere > from invent.kde.org/kde/krita to invent.kde.org/graphics/krita... You don't really have to update the URL, since this project was already on invent.kde.org we would be doing a move, which would automatically add a redirect, so while if you want to update, it is fine, it won't be breaking any of existing links/setups. -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
[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. > 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 -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
In part I am mostly re-iterating what Ben already mentioned in different messages. On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? Yes [Rest of message is with sysadmin hat off and as a developer] > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. I do agree that it maybe small inconvience, but let's be honest, most of us have been using kdesrc-build or some kind of automated tooling for building everything, apart from very rare case we never have to manually clone any of KDE repository, at least it is true for me personally. I am not sure about others. [Very non-scientific test, I did "history | grep 'git clone kde:'" on my machine and only instances were 4, websites/conf-kde-in, kde-build-metadata, sysadmin/irc-notifications, sysadmin/binary-factory-tooling, rest was automatically downloaded by the kdesrc-build] Anyway, getting back on topic, while this option gives some initial setbacks in our own personal workflow, let's look at bigger picture. Let's say I am the new developer who wants to contribute to frameworks. One of reason we are switching to gitlab is better onboarding, current state is that we have cgit.kde.org as a repository browser. By default I open it, I get the sorting by name, first repository is abakus. Commits as old as 14 years(!), after that some more mix of unmaintained repositories and scrolling almost 1.5 page, I get greeted with baloo, first framework in whole list. Let's just assume that name based sorting is bad idea, and we sort by activity instead. Here I get much better results, first framework is solid. But at same time if I was looking for SDK, kdevelop would appear at 3rd scroll-page. Here cgit is able to show many items in single scroll page, you can be assured that on gitlab it would not show kdevelop in first 6-7 pages. You might wonder why search does not help here? So problem with search is you need to know what you are looking for[*], but drive-by contributors, or users who are simply browsing our repositories won't know what they are looking for, they are simply trying to find a thing that interests them. Giving them categories/groups allows them to focus on topic they like and they can contribute to. > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? I agree that categories are something which we can improve upon, but this is something which we can improve upon, rejecting idea of categories just because 7-10 repos are at wrong place is ultimately not going to do anything good. > I really prefer when I don't have to guess this kind of things when > fetching a repository. [*] Ironically, in your case search would be helpful as you know you are looking for knetwalk so you can just add it and search it -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Information regarding upcoming Gitlab Migration
[Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] Hello Community members, In view of upcoming Gitlab migration, we sysadmin team wants to share the recommended structuring for the repositories on Gitlab. We had multiple options, - Flat structure: In this option we would have everything under one single namespace/group: https://invent.kde.org/kde/knetwalk - Subgroups under top-level group: In this option we would have a groups under KDE namespace: https://invent.kde.org/kde/games/knetwalk - Groups at top level: In this option we would establish a series of groups at the top level, e.g. https://invent.kde.org/games/knetwalk We have discussed this with small but representative group of contributors or maintainers, and based on their suggestions, we recommend that we go with option 3. Having sub-groups at top level will allow us to, - Provides good visibility on all reviews, tasks and other items within the groups/modules we define - Provides improvements to discoverability of projects - Makes it possible for groups of projects to establish a group level task board should it fit their needs (for tracking a release for instance) - Makes the most semantic sense, as the ‘KDE’ top level group suggested in option 2 is duplicative considering the Gitlab instance is under kde.org. - The discoverability of projects is maximised, as there is no need to open the top level ‘KDE’ group before going into the subgroup. I've worked on draft "move" of the current set of the repositories in their respective subgroups at the repo-metadata project's branch [1]. You can browse the directory structure to get idea of how final structure on Gitlab would look like. If we don't have any objections we would like to implement this next week and move projects to https://invent.kde.org. Thanks! Bhushan for sysadmin team [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Unused scratch/clones repositories cleanup
Hello community, Curently there's about 1400 repositories in total under the, scratch/ and clones/ namespace. https://cgit.kde.org/scratch/ https://cgit.kde.org/clones/ I am sure many people are using some of this repositories, but some are fairly inactive and unused. We would like to ask community members to go through their own personal repositories and clean-up the unused repositories. Instructions on how to delete or trash personal repositories can be found at: https://community.kde.org/Sysadmin/GitKdeOrgManual#Deleting_personal_repositories Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Help with sorting out unmaintained repos in the playground
Hello community, In preparation for upcoming move of KDE repositories to Gitlab we sysadmins wants to move the unused/inactive repositories to unmaintained/. Current list of all repositories: https://phabricator.kde.org/T12916 We need your help with sorting out what is maintained and what is not. So please comment in task. Thanks, Bhushan for KDE sysadmin team -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
conf.kde.in 2019 call for papers extended
Hello everyone! conf.kde.in 2019 call for participation has been extended uptil 15th Nov 2019. conf.kde.in 2019 will happen at Maharaja Agrasen Institute of Technology, Delhi, 17-18-19 January. If you wish to present your work on KDE community, please submit talk at the following page. https://conf.kde.org/users/sign_in?conference_acronym=cki2020=en Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Invent/gitlab, issues and bugzilla
Everyone, let's take a step back. Original discussion was, if project X can use gitlab issues instead of bugzilla? If the developers/maintainers prefer? Potential arguments to which are either, - No they can't because we forbid it in our manifesto or code of conduct or policies - No they can't because it makes life of other developer harder - No they can't because it makes life of other user harder As we stand neither of this arguments apply ... We have no written point in KDE manifesto which allows community to force a developer tool of their choice on new or existing project, as long as tool or service is hosted within KDE infrastructure and doesn't cost sysadmins or community resources/time maintaining that service. It is important have this freedom, otherwise next day someone can come up with idea that all projects should use cmake or autotools or qmake, because all of KDE community should be using same buildsystem. - Gitlab is hosted on KDE infrastructure and each KDE contributors can access the service using their KDE identity account. - Gitlab service is/will be actively maintained by KDE sysadmin team and using it as bugzilla is not going to cost KDE e.V. any extra money. If developer/maintainer collectively thinks that using gitlab as bug tracker makes their life easier instead of depending on bugzilla I don't understand why other developers would have a problem with that? It's not making their life difficult at all if they want to contribute, as mentioned in earlier point Gitlab is accessible to all users and developers. As for users, let users decide? I mean we can't speak for all of our userbase confidently that they love bugzilla and will stop reporting bugs for other components if certain other project/application starts using Gitlab for bugtracking, can either of you? On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote: > Besides, it's already too easy to make a bug report. Getting more bug > reports is not a priority for me; at this I would prefer to have less > interaction between developers and users than more, because we're > going crazy right now. This is your personal opinion. > And that's the important thing. Bugzilla is a developer tool, not a > user tool. We must have easy tools to triage, query, sort, modify sets > of reports. Bugzilla isn't perfect for that either, but the options > gitlab gives for handling issues are so limited. If bugzilla is developer tool, gitlab is also developer tool, let developer or maintainer decide how to best use it. On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote: > On the other hand, we also need to use tools that make our work > possible. Me being able to do my work, my developers being able to do > their work is also important. These tools are not for marketing, they > are for making the development process go better. And not just for > newcomers, but also for the people actually shouldering the load of > triaging ~150 reports a month. If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting because of either a) choice of maintainer or b) choice of specific sub-community, that decision doesn't affect krita, okular or other KDE applications. > I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But > gitlab's issues feature is not powerful enough to handle the amound of > bug reports I have to handle. In other words, I cannot do my work with > gitlab's issues feature. It might look more modern, but it just > doesn't have the power. This is your personal opinion. On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote: > In our company we multiple times reviewed bug trackers (for migrating > from Bugzilla), but none actually had a good enough feature set to be > considered, beside perhaps Jira (which is non-free/open). > > I would wait for the Bugzilla 6 release to judge if the UI arrives in > the 21th century before making any decisions what to use. Just that > GitLab is more modern doesn't give it all the features one needs. This is your personal opinion. In general, I respect everyone's personal opinion that bugzilla at moment superior to the gitlab issues, but at same time I also want to respect other developers opinion/choices as long as they abide by the KDE manifesto written and supported by our community. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Invent/gitlab, issues and bugzilla
On Tue, Jul 02, 2019 at 11:09:41PM +0200, Albert Astals Cid wrote: > That makes no sense, we incubated projects before we were on gitlab, saying > "oh no, if people can't use gitlab issues the incubation will collapse" is a > bit alarmist IMGO Not my point at all, I am not saying Gitlab issues would be cause which makes the incubation fail. I am saying that if we continue with such twisted policy which denies access to service A already present because service B is used by rest of community is what will make incubation fail. To expand, What I am saying is, - KDE Incubates a project - We have a two differet things for some thing, let's take example of build.kde.org and Gitlab CI. - We introduce a rule that people can't use Gitlab CI despite being there and force them to use build.kde.org That kind of rules are not getting us anywhere. If it was case of someone using Travis CI instead of build.kde.org, we can ask them to not use it or enforce it. But if both services are hosted on KDE infrastructure, requires no further maintainence or other KDE contributors are able to access the service, just because one piece of software is broken or requires change (drkonqi) denying projects use of Gitlab Issues is not a good idea. Projects come to KDE because they find our community attractive, in hope that they get more contributors, but if we want to stick with some old infrastructure, and actively deny them usage of something new, then they better be on infrastructre outside of KDE. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Invent/gitlab, issues and bugzilla
Hello, Thanks Luigi for starting discussion, Adding little bit of context on why this discussion is needed. This discussion was triggered by calindori getting included in the KDE group on gitlab. Calindori previously was developed fully on gitlab and would prefer to use gitlab for as many things as it can. I've also incubated Kaidan[1] which was using self-hosted gitlab infrastructure, and have total of approximately 200+ issues before incubating into KDE, with multiple contributors. Now we have following options, a) force these repositories to use bugzilla instead of gitlab till we come up with the solution to drkonqi problem. b) open a bugzilla product for compatibility with drkonqi and keep using gitlab for internal issues/bugs. I think solution b is least invasive solution to problem. and on personal note, I think if we have some infrastructure (gitlab issues) and if we force projects to not use it. I don't think it makes much sense.. and if it is our stance then we better close incubator projects.. Again this is my personal opinion and doesn't represent the KDE community's or KDE Sysadmin team's opinion. Thanks. On Tue, Jul 02, 2019 at 02:55:41PM +0200, Luigi Toscano wrote: > Hi, > > one of the main point of the gitlab migration has been so far the replacement > for phabricator. We didn't discuss about bug tracking. > > Despite this, I've seen a few projects using issues as replacement for > bugzilla. > > > We can all debate which is better, whether bugzilla or the gitlab issues, but > please consider that: > > - having to ways to report a bug makes like of everyone more complicated for > users reporting bug who need to find the proper place, and for bug triager > > - drkonqi still continue to report to bugzilla. Future versions of drkonqi can > be fixed to support the new system and we would need also a proxy for older > versions of drkonqi, but until such thing exist, a migration is out of > question. > > > My suggestion right now is to disable issues completely, or if they need to be > enable to allow us to replace phabricator tasks, then to reduce their scope to > this. > > -- > Luigi -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Google Season of Docs
Hello Albert, On Tue, Mar 12, 2019 at 12:25:45AM +0100, Albert Astals Cid wrote: > *Important for us* Valorie has mentioned she doesn't have the spare cycles to > lead this, she can lend a helping hand but if we want to part of this we need > an admin. > > Volunteers? As said elsewhere, happy to take a lead here for adminstrative tasks. Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Downtime announcement: www.kde.org
[sending again from right address since my gmail address is not subscribed to somee lists] Hello, On Mon, Nov 05, 2018 at 11:02:43PM +1300, Ben Cooksley wrote: > > In order to allow for hardware maintenance, one of our physical > > hardware hosts will need to be shutdown for a few hours on Monday. > > This downtime will commence around 9:30am UTC and may take several > > hours. The maintenance is now completed, and as far as we are aware, all services are now back up. If you have trouble accessing any of services, please let us know over email or sysadmin ticket. Thanks! > > > > During this time a number of sites will be inaccessible, including: > > - www.kde.org > > - autoconfig.kde.org > > - docs.kde.org > > - ev.kde.org > > - freebsd.kde.org > > - hig.kde.org > > - kdesrc-build.kde.org > > - neon.kde.org > > - releases.neon.kde.org > > - networkcheck.kde.org > > - planet.kde.org > > > > Other websites within KDE.org that are dependent on resources hosted > > on those sites may also experience delayed loading times in browsers > > during this window. > > > > As some of these sites are relied upon by applications to function > > properly, those applications may experience degraded functionality > > during this time. > > > > Affected applications include: > > - Discover > > - Kaffeine > > - Kopete > > - Plasma Network Manager (when behind a captive portal) > > - Any application using GHNS > > > > In addition, any other site which is hosted by the server known as > > "olios.kde.org" will also be unavailable during this time. > > > > Apologies for any inconvenience caused. > > The maintenance window has now commenced. > The above sites will be inaccessible until the maintenance is completed. > > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > Regards, > Ben -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Phabricator BoF(?)
Hello, At akademy one of thing I had in mind was to organize the phabricator BoF. To discuss, - Any improvements we can make with current phabricator workflow? - Any improvements/suggestions we (sysadmins) can forward to upstream? - How better we can make use of phabricator features - More... but seeing as there are limited slots for BoF are available, is there any interest about this? Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Participation of KDE in GCI 2018
Hey Vijay, On Mon, Oct 23, 2017 at 01:42:31AM +0530, vijay krishnavanshi wrote: > My opinion is that we should participate. Thoughts? My personal opinion about GCI this year is we should take a rest this year, this is due to two reasons, 1) Changed timelines of GSoC, we need to prepare and submit GSoC application much more early (even if after GCI ends, we don't have much of time in between0 2) Currently we need ~25 tasks for org applications but for the competition itself we need to have more like 50 unique and ~100 of total tasks IIRC at everytime, this is stressful task for both mentors and org-admins.. (I know people have promised to put tasks, and I trust them, but based on previous year's experience, often this effort is not enough to meet numbers, not blaming anyone). So yeah, my idea is, take a break this year, and use this time to document the junior jobs for next upcoming GCI and also others who want to work on KDE stuff out of this programs. (Also, just to be clear, I am not blocking anyone from participating.. I will be happy to help and mentor ( pun intended :P) willing org-admin.. Thanks! -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Big Hairy Audacious Goal: Privacy Software
Hi Sebastian, On Fri, Aug 18, 2017 at 06:14:22PM +0200, Sebastian Kügler wrote: > "In 5 years, KDE software enables and promotes privacy" Can you please submit this goal to goal settings phabricator board just like other ideas? Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Ambitious KDE Goal: Briding the Gap
On Sun, Aug 20, 2017 at 01:39:59PM +0200, Jos van den Oever wrote: > I feel like I should join in as well in pitching ambitious ideas for KDE. Can you please submit this to goal settings phabricator board just like other ideas? Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: KDE at Qt World Summit 2017 - let's make it the best yet!
On Tue, Aug 8, 2017 at 10:48 PM, Eike Hein <h...@kde.org> wrote: > - Helpers! Who wants to be an awesome person and go to QtWS and rep > KDE there? Who can make it to Berlin in the timeframe? (I know > there's a KDE Edu sprint and a Blue Systems dev sprint going on, > so no excuses! :P) > > Everyone interested and willing to commit please speak up, or get > in touch with me directly. You will be able to express a pre- > ference for booth and talk chairing duty which we'll try to > respect when drawing up the duty roster. You'll get lots of karma > bonus points if you're willing to help with booth setup and tear > down. I would like to join, I'll be able to help with booth duties (demo, and possibly teardown, I won't arrive in Berlin that early to help with initial setup) > > There will be a limit to how many people we can send, so please > don't be upset if we can't bring you along in the end. But please > do try! > > If travel/accomodation expenses would be the only thing keeping > you, get in touch and we can look into that. > > - Figure out what we want to show at the booth this year. Who wants > to make cool demo loops or slides? /me want to help with that, possibly I will make demo loop for plasma mobile > > - Make promo materials. We'll need to review and update our posters > (if anyone has the 2015/2016 posters, please link them in reply) > and flyers. And do it early enough so we can get them refined and > printed in time. Jens Reuterberg has promised to help make things > look great! > > > Cheers, > Eike -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: Official "Going to Akademy" banner by Ivan Čukić
On Fri, Aug 19, 2016 at 11:09 AM, Valorie Zimmerman <valorie.zimmer...@gmail.com> wrote: > > Bhushan, do you see the image in my post? The only post on Planet > where I see the image displayed was on Ken Vermette's blog. When I > checked his source I could see that he uploaded the image and linked > to that, rather than using the HTML snippet given to us on Yes I do see the image in both your post and on planet.. maybe try different browser? -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode
Re: Official "Going to Akademy" banner by Ivan Čukić
On Fri, Aug 19, 2016 at 8:50 AM, Valorie Zimmerman <valorie.zimmer...@gmail.com> wrote: > I used it in my blog post, but it's broken and I don't know why. I see > others who used it on the Planet also broken. Thoughts? > > Valorie > > link: > http://linuxgrandma.blogspot.com/2016/08/wee-akademy-and-qtcon-approaching.html What do you mean by broken? -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode
Re: [kde-community] Register for QtCon
On Fri, Aug 5, 2016 at 4:50 PM, Jos van den Oever <j...@vandenoever.info> wrote: > I did not see anywhere to put in dietary restrictions in the registration > form. You can adjust it in "My profile" -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCon CfP published
On Wednesday, May 18, 2016 12:05:25 AM IST, Sivan Greenberg wrote: As I see the deadline has passed and I missed it (I was under a strong flu for the last 2 weeks) is there room to ask for extension to submit mine ? Actually deadline was extended, and new deadline is 22nd May Thanks -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Distribution outreach program: Where do we go from here?
On Sun, Feb 14, 2016 at 3:27 AM, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote: > Does that make sense to you guys? > And most importantly: Who'd be up for joining the program team? Count me in. :-) -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ 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 Thu, Feb 4, 2016 at 4:08 PM, Ivan Čukić <ivan.cu...@kde.org> wrote: > I am *very* against giving our slots to non-kde projects. We already > had problems with this a few years ago, I would rather avoid the > unpleasantries that happened back then. Just FTR, we don't give away our own slots, but we ask for slots after we decide how many projects we are going to select. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] GCI tasks needed
Hello, As you guys may already know we are participating in Google code in 2015 like previous years. This years contest is starting on 7th December. And we are running very low on tasks this year.. We need total 75 tasks before Monday when contest starts.. If you have small tasks in your project, please head over to https://codein.withgoogle.com and add your tasks. There are total 5 categories in which you can add your tasks: - Code - User interface - Documentation/Training - Quality Assurance - Outreach/Research If you are not yet signed up as mentor of the KDE organization, please ping either me, valorie or Nightrose in the #kde-soc channel with your Gmail or Google sign-in enabled email address and we will invite you then you will be able to add the tasks in the Google code-in website. Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Write our own pull request bot?
On Sun, Sep 20, 2015 at 8:20 PM, Martin Klapetek <martin.klape...@gmail.com> wrote: > > Gnome in their years history of github mirroring had 4 pull requests > (it was mentioned in the other thread...one of the others). Sorry no [1] https://github.com/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+org%3Agnome -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Sun, Sep 20, 2015 at 6:33 PM, Riccardo Iaconelli <ricca...@kde.org> wrote: > exactly, as soon as we could. > But not all tools simply are technical alternatives. Can we replace Facebook? > Sure, we could join Diaspora. But we would be missing out on the community > already present on Facebook. Reasons for being on github are not technical, > they are promotional. We don't need to replace Facebook.. tada. Facebook is not part of our development nor anything.. So lets not compare with facebook.. When we talk about github and do our reviews there. It will be recorded there and if github goes down we will loose our data. Also in case we need to relicense stuff it would be impossible to track down contributor from github. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Sat, Sep 19, 2015 at 2:06 PM, Sune Vuorela <nos...@vuorela.dk> wrote: > I personally feel a bit fucked over right now. All this started with a > KDE github mirror and *just a mirror*. No pull requests. No bugtracker. > No nothing else. Just a mirror. And it was repeatedly said in the thread > that it would be just a mirror. Just a mirror. And when we say mirror and if we start to accept pull request there it will also complicate the sysadmin work if I know correctly How would git.kde.org will stay up-to-date if you merged pull request on github? This is one of the reason currently sysadmin allows pushes on just git.kde.org and not on anongit.kde.org When we say mirror its just mirror and just supposed to replicate our git repository. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Mon, Aug 17, 2015 at 12:54 PM, Jos van den Oever j...@vandenoever.info wrote: There is a (non-standard) instruction for robots.txt which reduces the crawl- frequency. E.g. Crawl-delay: 10 says only 10 requests per second are allowed. Neither projects.kde.org nor quickgit.kde.org are using this atm. http://stackoverflow.com/questions/17377835/robots-txt-what-is-the-proper-format-for-a-crawl-delay-for-multiple-user-agent If we do not let search engines index our primary product (source code), then it's not strange that people cannot find it. There is no point in allowing to index whole source codes IMO. But as sandsmark mentioned above there should be one page of where to find source code, how to get it, and how to contribute further and that should be indexed. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
Hi, Thank you for starting this thread. On Mon, Aug 17, 2015 at 12:24 PM, Jos Poortvliet jospoortvl...@gmail.com wrote: On Monday 17 August 2015 07:46:44 Martin Graesslin wrote: Hi community, over the last months I observed the following: * people not finding our git repositories * people being surprised that our code is not on github * some projects starting to use github in addition to our own infrastructure In my opinion first two are too wrong arguments to begin with.. If our repositories can not be found from outside then it requires improvement from our side. Putting source code on Github is not going to solve this problem. Even if people will use github to search projects eventually they will have to use our infrastructure to contribute. And about people being surprised that our code is not on Github, it is really clear that Github is _not_ standard place to get open source software. I'd say the main benefit of Github is that it makes it easy for the many developers used to it to do a pull request - effectively widening our potential contributor base. Some might send in one or two minor pull requests, not being interested in becoming regular contributors, others might be convinced, after a few patches, to join KDE and then get on our infrastructure. On other side it will be hard project management wise to monitor two places for new patches/contributions.. and eventually people will start to report bugs or issues there and that is going to be mess.. It will be like someone fixes bug on our infrastructure just to realize in end that someone sent pull requests on github. Also there are some problems with Github that I am sure going to make our sysadmins life little bit harder, like email address verification and stuffs like that. We have seen this problems when importing code from the Github. So, In short IMO there is nothing wrong with having Github mirror but that should be read-only and we should have real reason to do it. Currently sysadmins are reworking our git infrastructure. So lets wait little bit and see how it goes and then think of this. Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Your KDE highlight of 2014?
On Fri, Dec 19, 2014 at 3:38 PM, Lydia Pintscher ly...@kde.org wrote: 2014 is coming to an end. This gives us some time for reflection. What are your KDE highlights of 2014? A team that kicked ass? A really good release? An event where you made great new friends? Something entirely different? Personal highlight for me was conf.kde.in 2014 and Akademy, as well as Mentoring programs. GSoC, Season of KDE and Google code in. It was nice experience participating in Google Summer of Code 2014 as student and then sharing same knowledge by mentoring Season of KDE and Google code in. I just 3 this community. Lets hope we will rock upcoming year 2015. -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community