Re: [announcement] ATTENTION PLASMA THEME, WIDGET, & ADD-ON DEVELOPERS
Hello Joseph, thank you very much for the e-mail, with my extension developer hat on: I am currently trying to port my hoppla plasmoid. And "trying" is a pretty good description. The documentation is unfortunately quite lacking in some parts and incomplete / outdated in others e.g. also the tool to convert the .desktop to json (desktoptojson) does not add lines that are required by plasma but not documented, and the only way to find that out is to either start plasma or a plasmoid viewer on a command line and look for stdout / stderr output. (inb4 "then pull request a documentation fix" answers. I am already short on time as per below, so unfortunately I can't also, at least for now, write down all the obstracles I ran into and get them fixed, I am really sorry.) Changes made to Qt6 also come into play, e.g. QtGraphicalEffects. So you need multiple sources of documentation open at the same time, and e.g. the KDE API documentation (https://api.kde.org/ etc) seems to lack an easy option to switch between versions and the current docs linked there seem to be for plasma / frameworks / apps 5, not 6. Layouting / containers have undergone quite a lot of changes, and even when porting everything to the equivalent stuff in KF6, my plasmoid is completely unusable because controls end up out of view / too small / too big etc. And of course there are real time chats (IRC, Matrix, Telegram, whathaveyou) and forums, but trying to get in touch with the right people at the right time is hard, and given that I work on KDE stuff in my spare time, the delay between when I need the information, when someone is around, gives the information, I can answer their questions etc. is massive and there is no way my plasmoid will be even remotely ready in time. So the best option is to look at existing code. Problem there is: even if you look at official, first party plasmoids, you find out that the very same thing is achieved quite differently between different plasmoids. Given there is very very very few actual deep documentation that covers more than the very basics, there is no way for me to know which way is proper. There are very few third party extensions available on the KDE store, and those that are are rather simple on the GUI end. I assume that quite some of the other third party extension developers are facing similar issues that I am, so it will take quite a while until more are available, both for users and fellow devs. (Not to mention that coding and testing is currently quite hard, I had to set up a VM so I don't have to install a distro that even has plasma 6 or dual boot all the time, both of which is also not easy) tl;dr: the experience for third party developers is, at least in my opinion, sub par, the documenation far from sufficient and this can be quite frustrating. I don't want to point fingers and I know that people doing all of this are volunteers, too. Just trying to give KDE developers an insight from a third party extension dev. I hope that things will get better over time and with more people on plasma 6 and more documentation available, and I will try my best to still be able to port my plasmoid over in a decent timeframe, definitely not ready for release though. And given I already started a while ago (given people asked on GitHub for me to port it), I assume other devs catching your e-mail now won't be even nearly ready for release. That aside, I am looking forward to the plasma 6 release (I definitely won't switch myself before 6.1 / 6.2), and I wish us all great success and I want to send a huge thank you out to all developers, documentation writers, designers and all other helpful people whose work will make this big release possible. Kind regards, Christian (Fuchs) Am Freitag, 23. Februar 2024, 13:19:27 CET schrieb Joseph P. De Veaugh-Geiss: > Apologies for the all caps, but now that I have your attention :) > > With Plasma 6, various breaking changes affect existing Plasma > look-and-feel themes, widgets, and ad-ons. > > We love all your stuff, but you need to port it for it to work in Plasma > 6. We have created some handy, easy-to-follow guides: > >https://develop.kde.org/docs/plasma/widget/porting_kf6/ > >https://develop.kde.org/docs/plasma/theme/theme-porting-to-plasma6/ > > Porting is quite straightforward and should not take you long. > > Keep our users happy! Port your stuff! :) > > Cheers, > Joseph > > (H/t Paul Brown and Nate Graham for the above announcement)
Re: Plasma 6 new logo poll
Hi all, as someone who did participate in the poll and would like to keep the current version as the most favoured option: I just took the lack of "keep current" option as a "if we are going to change, which would would you like best", so I gave my vote to the option which is my second choice, after "keep current". I think that brands are way too quick these days with throwing something built up and recognizable over board, but iff we really have to change, then this one is the one I think would be the best. Only after Ilya's mail I do indeed see that people could interpret the result as a "people want change", which will put pressure on. If e.g. 20 more people felt like me and would choose their second best favourite, this might look like there are 20 more people who support change, and fewer who want to keep what we have currently. Therefore I suggest we take this poll with a grain of salt. Kind regards, Christian Am Mittwoch, 6. Dezember 2023, 16:01:06 CET schrieb Nate Graham: > Hi Ilya, > > This is mostly my fault as the poll did indeed have a "keep the current > logo" option in the beginning, but I recommended removing it after > seeing the poll live on discuss.kde.org. The reason for that > recommendation was because the results of the poll are themselves a set > of options for the Plasma devs to consider, and they (we) always have > the option of not taking any of them. So from that perspective a "keep > the current logo" option would be redundant and have the potential to > reduce the number of options available for the Plasma devs to consider. > > However I also see how the lack of a "keep the current logo" option > makes people who don't want any chance and who aren't or don't see > themselves as Plasma devs feel silenced. That was definitely not the > intention, even though I can see how the result was perceived that way > anyway. > > And to reiterate, there was never intended to be any pressure on Plasma > devs to choose a new logo. As I understand it, the ideal behind the poll > was to pick the three most popular options and weigh them against the > current logo. > > Nate > > On 12/6/23 00:34, Ilya Bizyaev wrote: > > Hello Paul, > > > > Could you explain why there is no option for the current Plasma logo? I > > would like to vote for keeping the existing logo, as I prefer it to the > > options listed in the poll. Shouldn't Plasma developers be able to see > > how the votes for the new logos compare to the current one, to make an > > informed decision? > > > > Not voting at all is not a solution because it is ambiguous: it could be > > interpreted as not caring or supporting whichever new logo that poll > > ends up "electing". "Non-bindingness" is also not an answer, because the > > developers will feel pressured by the community to comply with the poll > > results, even though they will be incomplete. > > > > Best regards, > > Ilya > > > > On 5 December 2023 21:17:53 CET, Paul Brown wrote: > > Dear Community Members, > > > > We have trimmed down all the proposals from KDE aficionados for the > > new Plasma > > logo taken from here: > > > > https://discuss.kde.org/t/how-about-a-new-logo-for-plasma-6/6206 > > <https://discuss.kde.org/t/how-about-a-new-logo-for-plasma-6/6206> > > > > to 6 (you know: as in Plasma _6_) and made a poll to determine the > > all time > > favourite. > > > > If you would like to vote on the poll, please go here: > > > > https://discuss.kde.org/t/plasma-6-logo-final-selection-and-poll/8001 > > <https://discuss.kde.org/t/plasma-6-logo-final-selection-and-poll/800 > > 1> > > > > The three most voted options will be passed on to the Plasma > > developers for > > their consideration. Please note that this poll is **NON-BINDING** and > > changing the logo will depend on the willingness of the Plasma devs. > > They will > > have the final say. > > > > Either way, the change, if it happens, is unlikely to occur in time > > for Plasma > > 6.0, as the project is currently in Feature Freeze. This means that > > only > > corrections, bug squashing, and minor tweaking is going on. Nothing > > new may be > > added at this stage. So if the devs do decide to change the logo, > > this won’t > > happen until at least Plasma 6.1. > > > > This poll will finish and be closed in one week. > > > > May the best design win! > > > > Cheers > > > > Paul
Re: Matrix <-> IRC Bridging
Hi, as a former member of Libera.Chat staff and knowing their peoplepower in the infra department, you might also want to ensure early that a reasonably sized i-line is in place for when you use your own bridge instead of the EMS one. Just as a reminder, other than that I'll stay out of it, thanks for your work. Fuchs Am Montag, 7. August 2023, 21:16:13 CEST schrieb Kenny Duffus: > Hi > > As many of you are aware the public Matrix bridge to the Libera.Chat IRC > Network was disabled on Saturday due to some stability issues > > KDE used that bridge to connect our Matrix rooms to our IRC channels > > We had been planing before this to migrate to setting up and using our own > bridge to Libera.Chat in the coming months after load testing etc > > We are in the process of getting this infrastructure in place more urgently > so we can rejoin our split community. This is unfortunately taking a bit > longer than hoped to get all the pieces up and running and talking to each > other. We hope to start re-bridging the higher priority rooms in the next > couple of days, then adding the rest of the rooms after that > > We will keep you updated with the progress on this > > Thanks > > P.S. This list is not the correct place to start ranting about > IRC/Matrix/Matrix.org Foundation/EMS/Libera.Chat etc
Re: Retirement of IRC Services and KDETalk.net (Jabber)
Am Mittwoch, 24. Mai 2023, 15:06:12 CEST schrieb Carl Schwan: > On Monday, 22 May 2023 00:26:09 CEST argonel wrote: > Hi, > > > I would argue that the low usage is in part due to lack of awareness. > > It has a one-line mention on the "Internet Relay Chat" community wiki > > page (which wasn't added until 2019) that doesn't even explain the > > benefits of using it. > I understand that this requirement is due to some technical issues, as IRC > doesn't support having so many connections open at the same time but it's a > bit wrong to blame Matrix for that. I do wonder why BNC is not affected by > this policy, but I suppose it's because there are way less users using IRC. A bit offtopic, but since the question was in the room: Due to Element in the past (and still, plus other issues) was very very bad at cleaning up dead / zombie connections, duplication issues partially due to reasons already mentioned, a very shaky bridge which produces lots of noise during (multiple) restarts ... this was a requirement that we (Libera we) set on Element. Also wrt i-lines: these are indeed still needed, and given loads of inactive connections, the i-line for Element had to be _huge_ (and we don't talk twice or four or six time the size of others, it was magnitudes of multitudes more) which is quite a risk and thus was also not sustainable long time. None of this applies to BNCs, plus with most if not all of the BNC providers being a lot more cooperative when it comes to issues, especially wrt abuse, noise and spam, they need fewer restrictions. But yes, for this restriction Matrix the protocol is not to blame. > Cheers, > Carl Kind regards, Christian
Re: Retirement of IRC Services and KDETalk.net (Jabber)
Am Montag, 22. Mai 2023, 10:24:48 CEST schrieb Ben Cooksley: > > So instead of shuttering the service, I recommend that more attention > > be drawn to it. > > There are currently 114 people registered to use the BNC, so it appears to > be rather well known among our community members. > The decline in it's usage has correlated rather well with the rise of > Matrix, so it appears that those that favour a BNC type experience find > Matrix works just as well / better. That seems more of a personal preference / your interpretation than fact, given that Halla wrote literally the opposite, to quote "we're still using irc in preference to matrix, since matrix is more complicated to use and not as reliable." Other than that, given what Kenny wrote, given that IRC is still officially supported by KDE and was done so by a vote, personally I think we should offer the services necessary to improve the experience for KDE folks, given it's (znc, in this specific case) a very low cost service. > Thanks, > Ben Kind regards, Christian
Re: Retirement of IRC Services and KDETalk.net (Jabber)
Am Sonntag, 21. Mai 2023, 21:12:25 CEST schrieb Ben Cooksley: Hi Ben, thanks for the answer, > Pursuivant is responsible for the announcement of commits and bugs. > As of late we have only seen removals of this functionality (see > https://invent.kde.org/sysadmin/irc-notifications/-/commits/master?ref_type= > heads) from channels, hence why i'm slating it for decommissioning. > > > Bouncer wise: 30 connections isn't exactly none, especially if that > > contains > > active people. These would be forced to migrate to a service (and register > > at > > such) which is not under KDEs control and, as far as I am aware, has a > > mandatory registration. As far as memory serves some communities, e.g. I > > think krita, still had active devs / maintainers on IRC. > > Yes, there is a cost-benefit analysis to all services we run however - and > if there is a minimal number of people benefiting from it, sometimes it is > time to retire a service. I guess we have at least found one community in KDE, a bigger one I'd say, that spoke up that they are using it, so maybe best check with them first. Also given that so far the vast majority of answers was not in favour of decommissioning, given the (from what I see) very low cost it should probably be re-evaluated. Of course that doesn't apply to the systems that have to be replaced due to them no longer being maintained / supported, but unless we run into security issues it would be nice to have a, from what I gather already planned, replacement before they are taken out. Kind regards, Christian
Re: Retirement of IRC Services and KDETalk.net (Jabber)
Hi Ben, while I can't comment on the Jabber side, some questions about IRC and the Telegram bridges. The latter seems to be still in use in some of the more graphically oriented communities, e.g. quite a handful of people in the VDG chat seem to be using it, do we have numbers on that, also what services does that bridge to? The name suggests Mattermost (?), but I don't think we have that. Depending on which services it bridges to, some channels might like to have that. If it's none of importance, then yeah, probably that can be gone. Skreamer / Pursuivant: I'd retire these when the replacement is there, and not before it. I also seem to have missed which part does the auto announcement of e.g. bug reports, since that was active / fetching, and if I understand site previews correctly, that is passive. As in: no automatic notice of new bug reports, but only when someone / something actively links them, correct? Bouncer wise: 30 connections isn't exactly none, especially if that contains active people. These would be forced to migrate to a service (and register at such) which is not under KDEs control and, as far as I am aware, has a mandatory registration. As far as memory serves some communities, e.g. I think krita, still had active devs / maintainers on IRC. I understand that we'd like to remove old cruft, but some parts of this seem to be in active use and low maintenance, so personally I wouldn't sunset them, at least not before a proper replacement is in place and not just planned. Kind regards, Christian Am Sonntag, 21. Mai 2023, 11:37:45 CEST schrieb Ben Cooksley: > Hi all, > > For some time now, the level of use of our IRC services - notably being > Pursuivant and the Telegram Matterbridge, but also including sKreamer - has > been on the decline. > > I'd therefore like to permanently retire all three of these services. > > Depending on the level of community interest, we may opt to retain > pursuivant however i'd like for it to be rebuilt as a Matrix native service > rather than being a continuation of our existing irker based bot that > occasionally has issues and falls off. > > Given that we are now fairly well migrated to Matrix, the need to maintain > our Telegram bridging is much reduced, and i'd therefore like to retire > that without replacement. > > In terms of sKreamer, it's primary utility has been to provide > announcements of Forum posts and bugbot services. With Matrix providing > site previews, and the Forum in imminent replacement by Discourse, both of > these are no longer necessary - so i'd like to retire it without > replacement as well. > > The only remaining service of contention here is the BNC, which has > significantly less use now than it did many years ago - with only 30 active > connections at the time of writing. It therefore appears to be of much less > need than it was in years past, and i'd also like to retire it as well. > > Finally, many years ago (prior to my time in Sysadmin) we started providing > Jabber services for the domains KDETalk.net and KDE.org. Due to abuse > however, we have for a long time had to have registration on KDETalk.net > disabled (KDE.org was always a manual registration). Much like the BNC, > this appears to only have 19 active clients at the time of writing. As our > official channel for chat is essentially Matrix now, I would like to retire > this as well. > > Together, all of these retirements will allow us to retire one of our > smaller DigitalOcean servers (the load all of these generate is > computationally small and thus cheap, however they do occupy mental > headspace that is better served focusing on other areas of our > infrastructure). > > Comments on the above? > > Thanks, > Ben
Re: Recurrent <5$ USD monthly subscription.
+1 for liberapay, it works pretty well for us (Libera.Chat, unrelated despite similar name) Am Dienstag, 28. Februar 2023, 00:26:38 CET schrieb Nicolás Alvarez: > Maybe we should consider liberapay? It allows donations as low as > €0.01/week (which is paid in advance to reduce payment processor > fees).
Re: Gitlab update, 2FA now mandatory
Personally I'd recommend Aegis (https://f-droid.org/packages/com.beemdevelopment.aegis/) over FreeOTP(+) due to the possibility to disable screencaps, the privacy focussed settings such as tap to reveal and encrypted exports (afaik FreeOTP only does unencrypted) and the possibility to import entries from Google Authenticator, which will make the migration a lot easier. In either case, any of them will work. Kind regards, Christian Am Sonntag, 23. Oktober 2022, 21:18:27 CEST schrieb Bernie Innocenti: > I was going to recommend andOTP for Android, but sadly the author no > longer has time to maintain it: > >https://github.com/andOTP/andOTP > > Looks like FreeOTP+ is actively maintained, so I'll look into migrating > to it. > > On 24/10/2022 03.38, Sune Vuorela wrote: > > On 2022-10-23, Ben Cooksley wrote: > >> (such as a Yubikey) or TOTP (using the app of choice on your phone) > > > > There seems to be some questions about what possible "app of choice" is > > available. > > > > kde has keysmith > > f-droid have freeotp+ > > sailfish has sailotp somewhere > > > > In the less privacy oriented ecosphere, but should not actually use this > > data for their nefarious purposes, > > > > - microsoft has a authenticator > > - google has a authenticator > > - github has a authenticator > > > > There is probably others in both the google and apple stores and maybe > > also other stores. > > > > /Sune
Re: How do we feel about non 100% KDE job offers being sent here?
Am Donnerstag, 25. November 2021, 17:17:52 CET schrieb Ingo Klöcker: > [snip] > 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. Personally I'd also prefer a dedicated mailing list. Especially when people discuss about what is appropriate and what is not, I expect the line to be hard to draw and since this is a public mailing list, there is a good chance that some people decide it's a good space for head hunting, which will clutter the list a bit up. If we do have a dedicated list, personally I would be less strict about the FLOSS requirement, since if the job does teach people things that they can and will use to contribute to KDE (or other FLOSS) in their spare time, I'd still count that as a net win. > Regards, > Ingo Kind regards, Fuchs
Re: Chat blocking under 16s from KDE
Am Montag, 2. August 2021, 11:58:20 CEST schrieb Jonathan Riddell: > If KDE is restricting who can take part in our activities, against our > historical practice, without prior discussion and solely because we are > reliant on a third party service we should move to a different service. They can connect via IRC, if they prefer a webchat https://web.libera.chat/ and https://web.libera.chat/gamja/ are available. We (Libera) do not collect data unless they register an account, in which case we only collect the information simply needed to have that account. https://libera.chat/privacy Depending on how the room they want to participate in is bridged, Telegram may also work. Usually all rooms should be bridged at least IRC and Matrix, so people who can't join via Matrix should be able to join via IRC. However, recently some (semi-)official rooms were created without bridging, if that is the case here, this should be fixable though. As far as the "move to a different service" goes: please not again. Also this age restriction is due to local laws (e.g. COPPA) and will most likely affect every commercial third party service we use, so unless we want to start self- host or use something existing that isn't affected (which is a bit limited) I doubt there are many options left. Mostly because these services, for user convenience, do have to store data, including chat log, which makes them subject to these laws. Right now we do have an option, it is IRC, and it is usable by people who do not want their information collected / who do not want to register an account / who can't or don't want to use Matrix for other reasons. > Jonathan Christian
Re: KDE Documentation & new Job
Thank you and good luck and lots of fun with your future endeavors :) Kind regards, Christian
Re: The status of freenode (the IRC network used by KDE)
As an update: last night, new freenode staff seized control over the linux, free software foundation and python channels, banning long term members on the way to do so. https://twitter.com/marklu/status/1403956182524387330 https://twitter.com/fsf/status/1403941542532952067 https://nedbatchelder.com/blog/202106/goodbye_freenode.html The rule that single-# channels are official is no longer in place, and people not endorsed by FSF were granted operator status in the FSF channel. Even though I know that we can't speed up the Matrix migration, I highly recommend we cut ties with freenode as soon as possible, and I expect us to be screwed over during the migration as well, so expect some turbulence. Kind regards, Christian
Re: The status of freenode (the IRC network used by KDE)
Hullo, Last I heard from our favourite Matrix doggo, Half-Shot, the bridge should leave beta state and be ready to be "released" beginning this week. No idea about the EMS state of course, not involved there. Thanks for the work and looking forward to say hi on the Libera side, Christian Am Montag, 7. Juni 2021, 13:23:06 CEST schrieb Kenny Duffus: > On Monday, 7 June 2021 11:02:35 BST Adriaan de Groot wrote: > > On Thursday, 27 May 2021 10:58:00 CEST Adriaan de Groot wrote: > > > On Wednesday, 26 May 2021 11:36:01 CEST Kenny Duffus wrote: > > > > On Wednesday, 26 May 2021 09:56:08 BST Dmitry Kazakov wrote: > > > > > Is there any KDE-wide decision on that? Is there any work done on > > > > > migration > > > > > from freenode to libera? > > > > > > > > Only a coordinated change would be good for our community. This would > > > > obviously be communicated to the community if everything that we need > > > > was > > > > prepared and ready to happen > > > > It **seems** to me that bridging to Libera.Chat is now working normally: I > > have joined #freebsd-desktop:Libera.Chat in Matrix, for instance, and that > > gets me the IRC channel. Some other Libera.Chat channels work too. This > > suggests it's "good enough"? > > The issue is migrating all the bridged kde matrix rooms (most of which are > freenode portal rooms) that we use to be instead using libera.chat > > While the portal rooms to libera.chat can already be accessed, the bridge is > only considered to be in a beta state > > However we are trying to avoid every single matrix user having to change > every room they are in and having to manual remove the :kde.org room alias > and then set it on libera.chat rooms. EMS are working hard on getting that > ready for us
Re: The status of freenode (the IRC network used by KDE)
Dear KDE community, it appears that over night, the now new management of freenode started to revenge-ban former staff from their servers, therefore I am now unable to connect to freenode and connect to / help out with KDE there. They also post heavily cropped private chatlogs on their blog so that they push their views. https://freenode.net/news/for-foss full chat log at the bottom of the mail, since the cropped part was released without me being asked, I have to assume it's fine to release the rest as well. In addition to that, former official channels from projects that moved to a different place were taken over by the new management. https://mastodon.sdf.org/@kline/106299403921451814 https://twitter.com/UndeadDrMcCoy/status/1397400278916386820 I've been asked in a KDE channel by a member on why I suggest moving, so: yeah, this is it. Seizing official channels you do not represent and banning members of the community for no reason other than revenge, even though I am obviously biased, I really think this is the kind of place that FLOSS projects should abandon. On more positive sidenotes: We had a very constructive chat with Matrix folk earlier this week and are now building up stuff to allow briding, so should KDE want to move over, we'd hopefully soon have a Matrix (and thus also Telegram) bridge available. Kind regards and thanks for the decade of support on freenode, Christian --- Full chatlog that got croppedly released by Andrew Lee. As usual, people are free to make up their own opinion if they have the full information, and not just bits and pieces. cat 2021-05-11.log [19:45:43] Hey there, please join #freenode-board -- this is an official message sent in my capacity as the owner of Freenode. Additionally, if you can please use my gpg key and share with me all of the credentials of Freenode. Thank you in advance. Just to be clear, this is an official message from the ownership of Freenode. [21:05:30] Hi Fuchs, do you have plans to comply? This is an official request from the Freenode Board cat 2021-05-25.log [21:15:32] well, good evening, "sole board member and chairman of freenode" [21:15:49] I assume that didn't go exactly as you planned when you unleashed your bloodhounds, and when you called for my resignation [21:16:20] free tip for next time: money might buy you domains or assets, but it will never buy you the right people, it will never buy you true loyality and, most importantly, it will never buy you a community [21:16:49] go and build one, with dedication and hard work. Good luck. [21:17:54] ? [21:19:01] Fuchs, you know very well my support for FOSS has been strong, what happened here, and why. [21:19:16] trivial: [21:19:35] you sent your bloodhound lawyers after a well respected community member, after _you_ misunderstood blog posts and resignation letters [21:19:45] I know christel already corrected you on your gist, shame you never updated that [21:19:57] I assume by now you also know that there never was a "merger" between OFTC and freenode planned [21:20:01] You are very incorrect Fuchs. [21:20:11] Secondly, you sent your mob on me. [21:20:19] and then you tried to throw out respected members of the community, and you replaced them with people that have 0 credibility in the FOSS world, in some cases even a negative one [21:20:21] The same mob you leashed on others and I, now I know I was wrong to, protected you. [21:20:25] I can't believe why you're doing this. [21:20:33] then you really can't be helped, I guess [21:20:36] good luck in your reality [21:20:51] and enjoy the scorched earth and smoking ruins and ashes that you inherited, killer of IRC [21:21:02] Fuchs, you are wrong to speak ill of the new freenode volunteers. [21:21:08] They've done quite a bit for FOSS and are respectable people. [21:21:11] Attack me all you want. [21:21:17] Not the volunteers. Fair? [21:21:39] Oh, I don't attack them. The community already has spoken on them, I'm rather sure, from the logs I have [21:21:46] and I don't attack you either [21:21:52] I explain to you what you seem to not want to understand [21:21:55] But, can you personally refrain from propelling negativity toward the team members? [21:22:15] if you prefer ingorance: go ahead, and watch the rest of the communities, projects and sponsors leave you as well. And keep asking yourself why. [21:22:23] you went after my friends, Andrew [21:22:26] In the meantime, let me try to save freenode. If you want to come back in the future let me know. I can forgive you, honestly. [21:22:32] what I did here was way more friendlynes than you deserve [21:22:43] Thank you for that. [21:22:47] if you don't want it: fine. Good luck, king of the scorched earth that once was freenode. [21:23:00] haha, _you_ forgiving _me_, that's gold [21:23:11] good luck then, I shall leave you alone and go build better. [21:23:27] I
Re: The status of freenode (the IRC network used by KDE)
Hi, brief, because in between work calls: thanks for the support. New network is up and running, but currently both our human and our computer ressources are a bit overwhelmed with the huge amount of people migrating, registration and the likes might take a while. I shall give more info later when I have more time at hand. So ar thank you very much ♥ Am Mittwoch, 19. Mai 2021, 14:30:10 CEST schrieb Bhushan Shah: > 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.
Re: The status of freenode (the IRC network used by KDE)
Hi Halla, Libera, mentioned in my resignation letter, should open soon. It is ran by now / soon to be ex-freenode staff, under a swedish non profit so this can't happen again, but with the same goals and values as freenode. OFTC would be an other option coming to mind, but I'd love to see you lot on libera, of course. Sorry that this was a bit rushed, one of us really couldn't live with us handing over the data (well, to be honest, none of us can, but he decided to go public before we could) and thus we now are a bit in a rush mode, I'll try to give more updates as soon as I can, I'm currently at work and my time is very limited. Kind regards, Christian
The status of freenode (the IRC network used by KDE)
Dear KDE community, KDE has been using the free services of the freenode IRC networks for a little bit more than two decades, and hopefully happily and successfully so. During the last few weeks, freenode was a bit in troubled waters due to what was perceived as a potential serious threat of a takeover of the network Due to that, a good amount of us who have been building and running freenode for the past decades prepared their resignation letters. Some of these got leaked a few days and made it to the hackernews frontpage and various other sites. The leaks included a personal draft of a resignation letter. Due to this leakage, Andrew Lee (former PIA/LTM, now shells.com) learned of the new situation and asked democratically elected freenode volunteers to step down from their position, as seen in the logs linked on [4] [5] [6] Therefore making the takover attempt and some details public. Included in these logs are also logs from third party users that show that associates from Mr Lee, namely the user rdv / nirvana, contacted various people and offered them oper access on the new network for money or revenge. It sickens me to the stomach to see our community that we built in the last 20 years to be lost to this kind of management. As you can imagine, the community was unhappy as well and we got loads of feedback. Thank you very much, this means a lot to us. We've also seen channel ops standing up to the potential new management, see e.g. [7] 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. As you can imagine, this whole mess makes me even less want to spend any of my volunteering time for the potential new management, and I wouldn't want to be responsible for sensitive user data under that management, either. Therefore I resigned from my volunteer position as a freenode staffer, along with some colleagues, and I assume a lot more will follow. I had all my access removed, so that I could not hand it or any data over to a third party, even if I wanted or if I were forced to. My resignation letter, along with some details, can be found at https://fuchsnet.ch/freenode-resign-letter.txt Big thanks to the KDE community for having been with us for more than twenty years, and despite IRCs shortcomings and new solutions available still being part of the freenode IRC network. Kind regards, Christian (commonly known as Fuchs)
Re: reddit r_KDE uses KDE logo in LGBT colors
Hi Sabayon11, while I do not know why after taking it to Reddit, then the forums, then IRC you now have to take it to the mailing list, especially as the answers you were given were mostly all the same: Yes, it is consistent, allowed, wanted and very much in the philosophy of KDE being open and welcoming for everybody and showing support to various marginalized groups. LGBTQ people still face discrimination in various places, in some way more severe than others, so I think it's good to show them that within the KDE community they are welcome and hopefully safe. As Nate already wrote, this does not mean that we aren't open and welcoming for other groups; quite the contrary. And we gladly show support for them, where it makes sense and where it is appropriate, too. If that openness and support for people scares off a sponsor, contributor or otherwise from KDE: probably KDE wasn't the right place for them anyway and I am not going to be sad about that loss. Kind regards, Christian Am Sonntag, 12. Juli 2020, 12:13:34 CEST schrieb sabayon11: > I have a question: > Is it legal for reddit moderators of r_KDE to use KDE logo in LGBT > colors. Is it consistent with logo license? > > 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? For > example: why they don't support women rights in middle-east region? > Who have the right to decide? > > 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. > > 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. > > 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. > > 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.
Re: The chat situation
Am Freitag, 12. Juni 2020, 22:13:09 CEST schrieb Andras Mantia: > Hi, > > On Friday, June 12, 2020 11:03:30 PM EEST Christian Loosli wrote: > > We use it at work with one our partners, and I was pondering to set it up > > for a project I am involved in (no, neither KDE nor freenode) where we do > > not want to use Matrix. Do you happen to know by chance how well it > > bridges? These are a requirement (Telegram and IRC, mostly). > > Documentation > > on that seems to be a bit stale / sparse, unless I am missing something. > > Unfortunately I have no experience with bridging it at all. > > Regarding using it in KDE (I know you asked for another project): Yeah, by coincidence it would also have been mostly valid for KDE. Time for me to spin up docker on one box and install it then, I guess. Thanks anyway :) > I'm not > convinced for a project as KDE any of the alternatives mentioned would be as > easy to use as freenode, most of them need an account, self hosting, > managing probably a lot of users and a big database, and has the problems > you mentioned about the legality of storing the conversations. Neither am I. Hence I'm pretty sure that no matter what solution we choose: it will contain multiple protocols / solutions, or it will alienate people for very valid reasons and fragment us, which I'd rather avoid. So I'd prefer fixing the papercuts in the existing solutions, and fortunately aside from Telegram (where only the client is) every thing we use is FOSS and specified (fsvo for IRC, I am aware), and we are a rather big communtiy with lots of devpower, so we should be able to. Or throw money at it if we really have to. > > Andras Kind regards, Christian
Re: The chat situation
Am Freitag, 12. Juni 2020, 22:00:58 CEST schrieb Andras Mantia: > Hey, > > On Friday, June 12, 2020 12:50:25 AM EEST Martin Steigerwald wrote: > > Carl Schwan - 11.06.20, 15:15:36 CEST: > > > Maybe it is the time to consider other open-source alternatives like > > > Mattermost or Rocket Chat... GNOME did it, Blender did it, we even > > > have a Rocket Chat client in KDE now! > > > > We do have Rocket.Chat at work and I can say I am quite happy with it. > > It is not perfect, but good enough, for me at least. Although especially > > threads are cumbersome UI wise. Sharing images or other files works quite > > well. > > > > I am using the official Electron client still, but there is a KDE/Qt based > > one, called Ruqola? Never tried it out so far. > > Rocket Chat has its share of problems, it can suffer e.g from lags and the > clients (except Ruqola) are using a lot of memory. Ruqola is already usable, > but not so pretty yet (sorry guys ;) ). > Otherwise feature wise Rocket Chat is nice. I don't like its (or Slack's) > threads, but YMMV. We use it at work with one our partners, and I was pondering to set it up for a project I am involved in (no, neither KDE nor freenode) where we do not want to use Matrix. Do you happen to know by chance how well it bridges? These are a requirement (Telegram and IRC, mostly). Documentation on that seems to be a bit stale / sparse, unless I am missing something. > Andras Kind regards, Christian
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 15:45:29 CEST schrieb Kevin Ottens: Hello Kevin, > Incidentally it's been the top discussion topics for the past few KDEPIM > sprints. And also during BoFs at Akademy. I even think there's been > discussions about that on the pim list and IRC channels. that is great to hear! Sounds like it is a rather long-term / time consuming process, therefore: do you think there could be something KDE could do to help? As in: would more attention (which a goal would likely achieve) help? Would (sponsored) sprints help? Developers? Money? Or do we just need to be more patient? I'm just afraid that we might indeed lose people or whole distributions to other products if the frustration level is too high, I know mine occasionally is and I do try out other products, too. > Regards. Kind regards, Christian
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 15:04:34 CEST schrieb Friedrich W. H. Kossebau: > I am missing what this email thread here should achieve, despite being > demotivating for those whose product is talked about or even bad-mouthing > them. We all know there are big and small flaws. Those get fixed by people > working on them. Not by people showing off their knowledge that there are > flaws. And I doubt the developers of the products do not know about the > flaws. They just do not have the resources left to handle them, given > resources are limited. My personal hope would be that some solutions could be discussed, e.g. on how to get more developers, if some parts should be dropped / rewritten instead of fixed etc. I definitely don't say that other KDE apps or Plasma do not have issues, but in my personal, daily workflow, PIM is the place where I get stuck more often than not. Most recent example is the one I mentioned in my initial reply, that kmail would not let me reply to an e-mail for a minute with a semi-helpful popup message with an cycling-progressbar. Personally I'd prefer the discussions being non-ranty and non heated, but removal of KDEPim was not discussed in the Phab task you linked for the first time, I remember a rather lenghty rant from a Gentoo packager, too. (Who was proposing to ship pre-akonadi KDE PIM as long as possible). These rants are obviously hurtful to people working on the software, but I also think they might show a bigger frustration that needs to be addressed. So I think if we can shift focus a bit on pieces of a "KDE distribution" that are vital for work (and I consider PIM very vital) that need more (urgent) attention than others, then that would be great. That's why we have specified goals, it is to focus. And focus does not mean laying blame on people, I'm sure the KDE PIM developers do their very best with the limited ressources and the complexity they have to tackle. It means trying to help. > Cheers > Friedrich Kind regards, Christian
Re: The chat situation
with one single product, requirements per group (e.g. VDG) are simply too different. > Nate Kind regards, Christian
Re: The KDEPIM / Akonadi situation
Hi Martin, thank you very much for bringing this up. I had a minor rant about the situation on the enterprise list back when I also used KDE apps at work, I'm afraid from what I can see the situation is mostly the same. I ended up with a messed up DB a couple of times that I was only able to solve by simply deleting and re-adding the IMAP account. As a funny bit of irony, I tried to reply to your message earlier, but kmail wouldn't let me because it asked me, with a pop up, to wait for transmission of the message for a couple of minutes. Unfortunately I also don't have any ready-made solution for it, we can't really force people to work on a certain product, and the whole akonadi-stack is probably also not something terribly new-person-friendly. I know that there was an alternative being worked on, but I lost track of that as well. Maybe making it a goal could help, or to have some sort of sprint around it. Or, even though I personally am usually very much against these, some sort of bounty. In any case I think the situation needs improvement and I'm glad you brought it up, so this is mostly in support of the request, because it stayed reply- less for a while. Kind regards, Christian
Re: The chat situation
Hi Carl, Am Donnerstag, 11. Juni 2020, 15:15:36 CEST schrieb Carl Schwan: > The problem with Matrix in KDE is that I'm not even sure someone is actively > working on improving the situation. > > I know the KDE sysadmins are not maintaining it and instead, in case of > problem, people should go to #kde-matrix-support:kde.org. So I tried asking > multiple times about why my matrix account doesn't get any message from the > irc and telegram bridge and never got an answer. So far my experiences in there were okay, but it might depend on various things, such as timezones, day of the week or just being lucky. Our KDE instance is, as far as I am aware, sponsored, so we (KDE, also for follow-up-we) do not only not give them any money, but by using their support sort of "costing them" money. This is an issue we will have with any chat system: either we are willing to maintain our own (which I assume we'd have to with Rocket), so we'd need to check if we have the ressources, both server- and people wise. Or, as we currently do with freenode IRC and Matrix, we outsource that, then we need to see if we trust the entity we outsource to, and if we are happy with their support. > The major reason why we chose Matrix was, because it allowed > communication with people still using IRC and was more user friendly. But > actually to be able to interact with those peoples, a new user should > register their nick on Freenode and using this nick on Matrix by using > some commands that need to be repeated every few weeks. I don't think this > process is very user friendly. Uh, I'm not sure where you got that, but: 1) nickserv registration is _not_ mandatory. IRC on freenode, compared to other solutions, does not force you to register and thus giving an e-mail address (Matrix), phone number (like Telegram) or similar. However, we (freenode) give channel operators the possibility to (temporarily or for good) make the channel only accessible to registered users, which can be used to cut down abuse / spam. However, I haven't seen any of that in recent months, so channels should be fine without this setting. 2) the process should not have to be repeated. You only have to register once, and unless Matrix is doing something silly, you should auto-authenticate on connect. 3) the process itself could be improved, however, we (freenode) on the IRC side can't really do anything more on that end, that would have to come from Matrix (I assume it shouldn't be too hard to have a proper GUI for that) > Maybe it is the time to consider other open-source alternatives like > Mattermost or Rocket Chat... GNOME did it, Blender did it, we even have a > Rocket Chat client in KDE now! I'd have to go back to the requirement collecting and voting process we had in 2017 on why Rocket didn't make it (because it was a candidate), as far as I remember it isn't trivial to maintain (only docker? Something like that) and I am not aware of any company or entity that would sponsor us an instance and take care of it, so if we wanted to switch, we'd need to ensure that our infra is willing and able to set it up and maintain / support it. Kind regards, Christian
Re: The chat situation
Hi all, couple of inputs from my side, with both a KDE and a freenode hat on: First of all, I do agree that the situation is not great and could be improved. However, I doubt that "switching to a single product" / "abandon bridging" would really improve the situation. Projects that went that path, e.g. Mozilla, suffered from even more community fragmentation, because some people are not happy with $product for various valid reasons (forced registration, not-open, lack of well integrating or accessible clients etc.) This is something we wanted to avoid back when the discussion came up that did lead to the current situation. Also Matrix, from what I can see, seems to have bridging issues that do not include IRC, so e.g. bridging Telegram and Matrix directly might improve the situation, but not fully solve it. And while IRC is improving (and you are very welcome to participate e.g. in #ircv3 or #freenode-dev on freenode) two of the main pain points people mention (lack of an endless scrollback / offline history, uploading media directly) are unlikely to fully happen on freenode / IRC, due to both technical and privacy / legal reasons. There is very likely to be (offline) backlog, but it will be time-limited due to the above constraints. Not having these constraints means someone else (neither freenode nor probably KDE) has both the storage and the legal willingness to store that data, with all implications this brings (DSVGO, security and privacy, ...) These are usually profit oriented companies, and having to rely on these brings up some new issues. Some of these issues can be solved already though, various well improving bouncer solutions have been mentioned, and exchanging media / displaying it can be solved in the frontend, as some clients already do. It just means relying on an external service, but we already do that in other areas. On the XMPP / messenger end I can't really say much other than the situation being most likely not satisfactory, but as people around me stopped using these protocols and switched to (semi)proprietary solutions, so unfortunately did I. Kind regards, Christian
Re: Planet KDE posts not about KDE (was: Re: Please don't make planet.kde.org into a politics feed)
Am Mittwoch, 11. Dezember 2019, 03:55:15 CET schrieb Martin Klapetek: > [...] > > I'm afraid the problem is already there. The problem starts from the > > moment a member posts an unrelated post, when someone who is not > > interested in it starts reading. > > But how is that problem of the Planet? I guess it is a matter of expectations. From the feedback that I got, a couple of people consider the planet to be about KDE and are thus estranged when controversial subjects such as politics do come up. > If the reader decides to > read something, then the reader can't blame the medium for giving > them the opportunity to read that. It's always up to readers to decide > whether they want to read something or not. The choice is theirs already. Sure, due to how the planet is set-up and depending on the blog post(s) in question, it can be a bit cluttered up / makes it harder to find the content the above named people came to planet for. Hence offering the idea of a filter, which would allow these people to read what they came to the planet for, which is directly KDE related content. Of course one can decide that we do not want to create that opportunity for these people due to technical, effort-versus-gain or many other valid reasons, that will in my opinion just to lead to these people being alienated and not reading the planet. Which is why I think a filter would be nice, but I'm most certainly not going to die on that hill. > Cheers > -- > Martin Klapetek Kind regards, Christian
Re: Please don't make planet.kde.org into a politics feed
And as per the suggestion, a task with a filter solution was separately created: https://phabricator.kde.org/T12322 Feel free to comment there (again, kindly keep it civil and objective, I know politics often aren't) Am Donnerstag, 5. Dezember 2019, 14:06:54 CET schrieb Christian Loosli: > Someone created a task on phab for people interested, > https://phabricator.kde.org/T12321 > > Please keep it civil and objective, thanks :) > > Kind regards, > > Christian > > Am Donnerstag, 5. Dezember 2019, 12:52:36 CET schrieb Christian Loosli: > > Dear Community, > > > > I'm 100% sure this topic came up in the past due to the same blog, but I > > can't find it on the mailing list, so I assume it happened on forums or > > chat: > > > > currently the top blog post on planet.kde.org is about voting for a > > specific political party. I understand that in these times there are many > > countries with heated and important political debates, and some very > > important global topics as well. However, these already occupy all the > > news site. > > Now if every blog appearing on the planet would target a political subject > > that is very important to the blogger, planet.kde.org would be yet another > > political news/opinions feed. > > > > If I want politics, I go to one of these. If I want to read about KDE, I > > go > > to planet.kde.org. > > > > Please dear bloggers: there are categories, and you can choose which of > > your blogs do show up on the planet. I know that some topics are very > > important to you and obviously you are free to blog about them, but > > please keep the planet.kde.org feed free of it, so it doesn't become a > > mess where it's hard to find the content people actually go there for. > > > > Thanks and kind regards, > > > > Christian
Re: Please don't make planet.kde.org into a politics feed
Am Donnerstag, 5. Dezember 2019, 13:44:09 CET schrieb Eike Hein: > I don't think we're likely to achieve consensus on making the KDE community > an escapist outlet where we can hide from the world around us. Completely is unlikely indeed, but the world is not black and white, and we can steer a bit what places are affected and what places are not (e.g. the comment in the other thread about "please no politics on the mailing lists"). Professional environments seem to manage quite fine to get up some sort of separation, so maybe we can, too. > Cheers, > Eike Kind regards, Christian > On December 5, 2019 1:39:57 PM GMT+01:00, Christian Loosli wrote: > >Kindly don't throw in false accusations, I don't dislike that > >particular blog > >post at all (probably it's even mostly my position), I dislike in > >general that > >things get more and more political, so you it's getting really hard to > >find > >projects and places where you don't have to deal with $topic (insert > >controversial stuff like Brexit, Bolsonaro, Trump, Fidesz, ... I'm sure > >every > >country and region has its fair share) because you originally came to > >these > >places for something other than politics. > > > >As the bar has a different height for different people, I already made > >a > >suggestion: simply create a category for it and allow to filter, as we > >already > >allow to filter by language. > > > >Kind regards, > > > >Christian > > > >Am Donnerstag, 5. Dezember 2019, 13:36:36 CET schrieb Eike Hein: > >> If and when the Planet becomes majority political content, that's a > > > >problem > > > >> we can acknowledge and deal with at that time I would say. As a > > > >community > > > >> we're smart enough to understand that it's a different reality from > > > >an > > > >> occasional post. Let's have that trust. > >> > >> But let me say it again: We discussed this before. The hypothetical > > > >you've > > > >> laid out is not a new one. You're not explaining how the situation is > >> different now from back then and why we need to review the consensus > > > >we > > > >> already had achieved, which was informed by other thoughts like > > > >having the > > > >> Planet be a place where we can get to know each other and the cost of > >> losing a venue for that. The Planet is not a corporate outlet or a > > > >news > > > >> feed, it's a community aggregator. > >> > >> Starting a thread because you don't like a particular personal blog > > > >post is > > > >> not meeting the necessary bar. Let's not prolong it until you come up > > > >with > > > >> something. > >> > >> > >> Cheers, > >> Eike > >> > >> On December 5, 2019 1:26:58 PM GMT+01:00, Christian Loosli > > > > > > > >wrote: > >> >Am Donnerstag, 5. Dezember 2019, 13:24:30 CET schrieb Eike Hein: > >> >> But they don't, so your calculation is about solving a problem > > > >that > > > >> >doesn't > >> > > >> >> currently exist. > >> > > >> >I consider that a tricky argument that leads to a slippery slope, > >> >because > >> >whenever people will at political stuff, it will be "but the other > >> >person was > >> >allowed, too!", so in my opinion it's a matter of fairness. > >> > > >> >> Cheers, > >> >> Eike > >> > > >> >Kind regards, > >> > > >> >Christian > >> > > >> >> On December 5, 2019 1:21:08 PM GMT+01:00, Christian Loosli > >> > > >> > > >> > > >> >wrote: > >> >> >For me it's a rather simple calculation: if every contributor on > >> > > >> >planet > >> > > >> >> >would > >> >> >post as many articles on politics as e.g. you do, the planet > > > >would > > > >> >be > >> > > >> >> >simply > >> >> >overcrowded with it. > >> >> > > >> >> >Given we already have filters for languages, maybe there could be > > > >a > > > >> >> >filter for > >> >> >non-KDE stuff, so that people who to go planet.kde to read about, > >> > > >&
Re: Please don't make planet.kde.org into a politics feed
Kindly don't throw in false accusations, I don't dislike that particular blog post at all (probably it's even mostly my position), I dislike in general that things get more and more political, so you it's getting really hard to find projects and places where you don't have to deal with $topic (insert controversial stuff like Brexit, Bolsonaro, Trump, Fidesz, ... I'm sure every country and region has its fair share) because you originally came to these places for something other than politics. As the bar has a different height for different people, I already made a suggestion: simply create a category for it and allow to filter, as we already allow to filter by language. Kind regards, Christian Am Donnerstag, 5. Dezember 2019, 13:36:36 CET schrieb Eike Hein: > If and when the Planet becomes majority political content, that's a problem > we can acknowledge and deal with at that time I would say. As a community > we're smart enough to understand that it's a different reality from an > occasional post. Let's have that trust. > > But let me say it again: We discussed this before. The hypothetical you've > laid out is not a new one. You're not explaining how the situation is > different now from back then and why we need to review the consensus we > already had achieved, which was informed by other thoughts like having the > Planet be a place where we can get to know each other and the cost of > losing a venue for that. The Planet is not a corporate outlet or a news > feed, it's a community aggregator. > > Starting a thread because you don't like a particular personal blog post is > not meeting the necessary bar. Let's not prolong it until you come up with > something. > > > Cheers, > Eike > > On December 5, 2019 1:26:58 PM GMT+01:00, Christian Loosli wrote: > >Am Donnerstag, 5. Dezember 2019, 13:24:30 CET schrieb Eike Hein: > >> But they don't, so your calculation is about solving a problem that > > > >doesn't > > > >> currently exist. > > > >I consider that a tricky argument that leads to a slippery slope, > >because > >whenever people will at political stuff, it will be "but the other > >person was > >allowed, too!", so in my opinion it's a matter of fairness. > > > >> Cheers, > >> Eike > > > >Kind regards, > > > >Christian > > > >> On December 5, 2019 1:21:08 PM GMT+01:00, Christian Loosli > > > > > > > >wrote: > >> >For me it's a rather simple calculation: if every contributor on > > > >planet > > > >> >would > >> >post as many articles on politics as e.g. you do, the planet would > > > >be > > > >> >simply > >> >overcrowded with it. > >> > > >> >Given we already have filters for languages, maybe there could be a > >> >filter for > >> >non-KDE stuff, so that people who to go planet.kde to read about, > > > >well, > > > >> >KDE, > >> >could filter all that stuff out. > >> > > >> >Kind regards, > >> > > >> >Christian > >> > > >> >Am Donnerstag, 5. Dezember 2019, 13:04:35 CET schrieb Jonathan > > > >Riddell: > >> >> Planet KDE exists to allow KDE people to share information about > >> > > >> >themselves > >> > > >> >> as well as their KDE contributions. A hard Brexit will affect KDE > >> >> significantly which is why I include it here. The idea that > > > >talking > > > >> >about > >> > > >> >> politics is dangerous or anti-social really scares me and is one > >> > > >> >reason why > >> > > >> >> the populists have taken over so much of the political discussion > >> >> currently. I often get people thanking me for my political opinion > >> > > >> >blogs. > >> > > >> >> If you don’t want to read it then don’t read it. > >> >> > >> >> The rule we came up with is "The majority of content in your blog > >> > > >> >should be > >> > > >> >> about KDE and your work on KDE. Blog posts about personal subjects > >> > > >> >are also > >> > > >> >> encouraged since Planet KDE is a chance to learn more about the > >> > > >> >developers > >> > > >> >> behind KDE." I've never heard anyone suggest changes to that > > > >rule. > > &
Re: Please don't make planet.kde.org into a politics feed
Am Donnerstag, 5. Dezember 2019, 13:24:30 CET schrieb Eike Hein: > But they don't, so your calculation is about solving a problem that doesn't > currently exist. I consider that a tricky argument that leads to a slippery slope, because whenever people will at political stuff, it will be "but the other person was allowed, too!", so in my opinion it's a matter of fairness. > Cheers, > Eike Kind regards, Christian > On December 5, 2019 1:21:08 PM GMT+01:00, Christian Loosli wrote: > >For me it's a rather simple calculation: if every contributor on planet > >would > >post as many articles on politics as e.g. you do, the planet would be > >simply > >overcrowded with it. > > > >Given we already have filters for languages, maybe there could be a > >filter for > >non-KDE stuff, so that people who to go planet.kde to read about, well, > >KDE, > >could filter all that stuff out. > > > >Kind regards, > > > >Christian > > > >Am Donnerstag, 5. Dezember 2019, 13:04:35 CET schrieb Jonathan Riddell: > >> Planet KDE exists to allow KDE people to share information about > > > >themselves > > > >> as well as their KDE contributions. A hard Brexit will affect KDE > >> significantly which is why I include it here. The idea that talking > > > >about > > > >> politics is dangerous or anti-social really scares me and is one > > > >reason why > > > >> the populists have taken over so much of the political discussion > >> currently. I often get people thanking me for my political opinion > > > >blogs. > > > >> If you don’t want to read it then don’t read it. > >> > >> The rule we came up with is "The majority of content in your blog > > > >should be > > > >> about KDE and your work on KDE. Blog posts about personal subjects > > > >are also > > > >> encouraged since Planet KDE is a chance to learn more about the > > > >developers > > > >> behind KDE." I've never heard anyone suggest changes to that rule. > >> > >> Jonathan > >> > >> On Thu, 5 Dec 2019 at 11:53, Christian Loosli > > > >wrote: > >> > Dear Community, > >> > > >> > I'm 100% sure this topic came up in the past due to the same blog, > > > >but I > > > >> > can't > >> > find it on the mailing list, so I assume it happened on forums or > > > >chat: > >> > currently the top blog post on planet.kde.org is about voting for a > >> > specific > >> > political party. I understand that in these times there are many > > > >countries > > > >> > with heated and important political debates, and some very > > > >important > > > >> > global > >> > topics as well. However, these already occupy all the news site. > >> > Now if every blog appearing on the planet would target a political > > > >subject > > > >> > that is very important to the blogger, planet.kde.org would be yet > >> > another > >> > political news/opinions feed. > >> > > >> > If I want politics, I go to one of these. If I want to read about > > > >KDE, I > > > >> > go to > >> > planet.kde.org. > >> > > >> > Please dear bloggers: there are categories, and you can choose > > > >which of > > > >> > your > >> > blogs do show up on the planet. I know that some topics are very > > > >important > > > >> > to > >> > you and obviously you are free to blog about them, but please keep > > > >the > > > >> > planet.kde.org feed free of it, so it doesn't become a mess where > > > >it's > > > >> > hard to > >> > find the content people actually go there for. > >> > > >> > Thanks and kind regards, > >> > > >> > Christian
Re: Please don't make planet.kde.org into a politics feed
For me it's a rather simple calculation: if every contributor on planet would post as many articles on politics as e.g. you do, the planet would be simply overcrowded with it. Given we already have filters for languages, maybe there could be a filter for non-KDE stuff, so that people who to go planet.kde to read about, well, KDE, could filter all that stuff out. Kind regards, Christian Am Donnerstag, 5. Dezember 2019, 13:04:35 CET schrieb Jonathan Riddell: > Planet KDE exists to allow KDE people to share information about themselves > as well as their KDE contributions. A hard Brexit will affect KDE > significantly which is why I include it here. The idea that talking about > politics is dangerous or anti-social really scares me and is one reason why > the populists have taken over so much of the political discussion > currently. I often get people thanking me for my political opinion blogs. > If you don’t want to read it then don’t read it. > > The rule we came up with is "The majority of content in your blog should be > about KDE and your work on KDE. Blog posts about personal subjects are also > encouraged since Planet KDE is a chance to learn more about the developers > behind KDE." I've never heard anyone suggest changes to that rule. > > Jonathan > > On Thu, 5 Dec 2019 at 11:53, Christian Loosli wrote: > > Dear Community, > > > > I'm 100% sure this topic came up in the past due to the same blog, but I > > can't > > find it on the mailing list, so I assume it happened on forums or chat: > > > > currently the top blog post on planet.kde.org is about voting for a > > specific > > political party. I understand that in these times there are many countries > > with heated and important political debates, and some very important > > global > > topics as well. However, these already occupy all the news site. > > Now if every blog appearing on the planet would target a political subject > > that is very important to the blogger, planet.kde.org would be yet > > another > > political news/opinions feed. > > > > If I want politics, I go to one of these. If I want to read about KDE, I > > go to > > planet.kde.org. > > > > Please dear bloggers: there are categories, and you can choose which of > > your > > blogs do show up on the planet. I know that some topics are very important > > to > > you and obviously you are free to blog about them, but please keep the > > planet.kde.org feed free of it, so it doesn't become a mess where it's > > hard to > > find the content people actually go there for. > > > > Thanks and kind regards, > > > > Christian
Please don't make planet.kde.org into a politics feed
Dear Community, I'm 100% sure this topic came up in the past due to the same blog, but I can't find it on the mailing list, so I assume it happened on forums or chat: currently the top blog post on planet.kde.org is about voting for a specific political party. I understand that in these times there are many countries with heated and important political debates, and some very important global topics as well. However, these already occupy all the news site. Now if every blog appearing on the planet would target a political subject that is very important to the blogger, planet.kde.org would be yet another political news/opinions feed. If I want politics, I go to one of these. If I want to read about KDE, I go to planet.kde.org. Please dear bloggers: there are categories, and you can choose which of your blogs do show up on the planet. I know that some topics are very important to you and obviously you are free to blog about them, but please keep the planet.kde.org feed free of it, so it doesn't become a mess where it's hard to find the content people actually go there for. Thanks and kind regards, Christian
Re: FSF leadership
Hi all, I mostly agree with Agustin and Jens: I think that people should be elected into positions based on their suitability for that position, which means that things like sex, gender, race, cultural background, sexual orientation etc. pp. should neither be an advantage nor a disadvantage. Otherwise people with backward mindsets thinking that "$xy can't do $z" will go "Oh, you only got into position $z due to being $xy", which doesn't help. Also worst case, but exaggerated, if indeed people are picked not based on suitability, you could e.g. pick someone for a communicative job that is rather introvert or someone for a finance job that doesn't like numbers, then people with the above mentioned mindset would feel that their odd views are even more confirmed, that $xy can't do $z. >From a personal point of view, I e.g. do not think that someone from the LGBTQ+ spectrum would represent me any better on a board. What is important to me is that I feel welcome and an not harassed / discriminated due to that. And that is what we need to achieve: our community needs to be inclusive and welcoming, so we shall not tolerate discrimination based on sex, gender, cultural heritage etc. pp. When we have a diverse base, chances are obviously high that people elected into positions have all kind of different backgrounds. And that is what I think we need to recommend to other communities, so that FOSS as a whole is a place where everybody feels welcome and nobody suffers from discrimination based on who they are. On the other hand, I do not feel that we are in the position to make strong pushs or even build up public pressure when it comes to elections and choices of other organizations. I don't know how FSF elections internally work, but if we map it to KDE, I'd see it as very awkward if an external organization would interfere with our board elections and say "You should pick candidate $x or you must add candidates $y and $z". tl;dr: I think we need to ensure that both we and FOSS has a diverse, broad base and work on issues preventing that, not interfering with other organizations elections and processes. Kind regards, Christian Am Donnerstag, 19. September 2019, 04:59:09 CEST schrieb Valorie Zimmerman: > As many of you know, Richard Stallman has stepped down from the FSF. > However, his supporters on the FSF Board remain. The FSF is on our Advisory > Board, according to https://ev.kde.org/advisoryboard.php > > Accordingly, I would like us (the KDE Community) to advise them to > diversify their Board, as RedHat has done here: > https://www.redhat.com/en/blog/open-letter-free-software-foundation-board-di > rectors. If we cannot do this as a community, I would like to ask the Board > to do this on our behalf. > > All the best, > > Valorie
Re: KDE now has its own Matrix infrastructure
Am Montag, 18. März 2019, 11:08:39 CET schrieb Boudewijn Rempt: > On maandag 18 maart 2019 11:06:26 CET Eike Hein wrote: > > On 3/18/19 6:38 PM, Boudewijn Rempt wrote: > > > I'm sure people are working hard on fixing things up, but right now > > > webchat.kde.org just does not work. If I look in at the Krita channel > > > on webchat.kde.org, the last message is from 23:01 yesterday.> > > The Matrix folks told us they're working with freenode on an i:line and > > spinning up an instance of the bridge on our server (currently the > > bridging is running through the overloaded matrix.org homeserver). They > > say this should help a lot. The freenode side is ready (and has been for a few days). There was a short delay there due to the i-line request going through a specific person instead of through the official ways, so when KDE folk poked me, I had to poke that person first. > Would that also help with the delays when communicating on webchat.kde.org > with other matrix users? I'd be surprised if, since the bridge, from my understanding, should only affect Matrix <-> IRC and not Matrix <-> Matrix. I might be and I hope that I am wrong, best ask the Matrix Matthew in #kde-matrix-support. Kind regards, Christian
Re: KDE now has its own Matrix infrastructure
Hello all Terribly sorry to interrupt here, but would it maybe make sense to move this topic into its own, separate thread? It seems to not be much about the Matrix Infrastructure or related articles. This would make it easier to search, find and filter. Thanks for considering and kind regards, Christian
Re: KDE now has its own Matrix infrastructure
Am Dienstag, 26. Februar 2019, 17:54:38 CET schrieb Paul Brown: Hello Paul, > > The workboard item is https://phabricator.kde.org/T10477, it wasn't > > tagged KDE promo, it wasn't sent to the dot-editors list > > This is true. However, there were good reasons for keeping things under > wraps: > > Firstly nobody wanted it to pop up on some place like Reddit, have a bunch > of people cascade into the servers before they were ready, then moan on > line how KDE can't get anything right and "bring back KDE 3!". Safeguarding > KDE's reputation is one of Promo's prime directives. well, in my opinion we managed quite the opposite, to be honest. Not only did we publish an article that was wrong and looked a bit unprofessional, personally I also think having at least some more testing before going public by a group would have been helpful. First of all, we did have performance issues when it got live. First due to a bug that is, as far as I am aware, now fixed. Now due to the bridge being the shared matrix bridge, which is under quite a load, hence having a couple of seconds of delay between sending messages and seeing them / message order mixup, which is to be solved (likely by switching over to a dedicated bridge) That, and the few bugs reported (and some of them fixed) in the matrix kde support channel right after release are all things I think could have been ironed out before release if tested. In addition to that, the internal-only approach seems to have lead to a rather biased / sided article which, according to Lazlo, still comes across as biased / sided. This is of course debateable, but I can see where he is coming from. So I think some "not getting it right" moaning is warranted, and the "bring back KDE 3" people will always be there, and everything looks a nail if all you have is a hammer, so no matter what we do and how we do it: it can be used as an argument. That all in mind is why I think the approach was maybe not the best one and should be reconsidered for future events and articles. > Cheers Thanks and kind regards, > Paul Christian
Re: KDE now has its own Matrix infrastructure
Hi Jonathan, thanks for the wrap-up. I am less interested in pointing blame, and more interested in - how this could have happened - what our learnings are so this doesn't happen again in the future? It still is unclear to me how non-true accusations without further explanation made it into the article. Even for people who are not familiar with the subject, this imho should never happen. If you are not sure, you don't throw around accusations of things being insecure. It bothers me even more that there is a lengthy discussion on the subject (and a follow up survey and result) available to the people who participated in this, the article looked to me like this discussion, survey and result (that we did put a lot of time and effort in) were ignored. >From what I gathered it even was given to the right people to proof-read, but the article was released without waiting for a reply. How can that happen, and why was it so urgent to push that article out? So to avoid this in the future, I'd like to see us following a process that does involved proof-reading by people familiar with the subject, so we look as professional as we as KDE should be by now, and usually are. As a last but not least, I'm also not terribly happy when people involved were also the ones still, in public, making statements against one of the technologies we decided to use and support, stating we should abandon them. Together with the flawed article this doesn't look good. I'd love to see people at least try to not let their personal views bias them too much, especially not when a group decision was made. I have my personal views and preferences on this too, but I try my best to accept the decision taken and support it. Thanks and kind regards, Christian
Re: Don't shoot the messenger (was Re: KDE now has its own Matrix infrastructure)
Hello Paul, in this case please do let me know who passed that text through, because it is simply wrong and misleading, and I'm not terribly happy with that being on the dot. It doesn't look terribly good when we spread wrong information about a product we still actively use. And I also wonder why this text was (at least I assume) not given to people familiar with the technology to proof-read it, as this should have been immediately noticed, as you can see from the initial replies. tl;dr: personally I'd like that text to be pulled and corrected, as right now we spread wrong information about a product we and many others still use. I can gladly get in touch with whoever is in charge of that, but I don't know who is. Kind regards, Christian Am Mittwoch, 20. Februar 2019, 14:06:26 CET schrieb Paul Brown: > Dear all, > > What the subject says. Please address your concerns to the people who made > the decision and passed down the bullet points of the text. > > I will not be responding to any messages in this thread, since it is not my > place. > > Cheers > > Paul
Re: KDE now has its own Matrix infrastructure
Am Mittwoch, 20. Februar 2019, 13:36:37 CET schrieb Paul Brown: > Hi all, Hi Paul, > KDE has been looking for a better way of chatting and live-sharing of > information for several years now. IRC has been a good solution for a long > time, but has centralized servers KDE cannot control, it is also insecure beg your pardon? Neither is true. IRC is decentralized, and whilst KDE has no control over the freenode servers (obviously), it would have been free to have their own. From what I gather the KDE matrix instance is sponsored and not full control either. I'd also like to know how IRC is "insecure", in general and also in contrast to Matrix. Otherwise I kindly ask you to not throw such accusations without further explanation around. > • Unlike IRC, Matrix is an entirely decentralised public network and > anyone can run a server. Again: that is simply wrong. IRC is decentralized, the protocol is entirely open and various ircds and services are open source, and everybody is able to run their own network. > So please head over to https://webchat.kde.org (or matrix.kde.org via any > other Matrix client!), grab an account and join #kde:kde.org. For more > information, check out our Matrix wiki page which includes details on how to > configure desktop clients (https://community.kde.org/Matrix). > Let us know how you get on! Currently testing, I have > 1 minute loading times on searching and joining channels, and communicating with the appservice to change the IRC side nick or directly joining unlisted channels does not work (unfortunately no error message at all, so I can provide nothing to debug. > Cheers > > Paul Kind regards, Christian
Re: Discourse
Hi all, from what I get from the documentation, discourse has a mailing list mode which can, from a end user point of view, be used the same as a mailing list. As in: in a mail client, without additional config that would not be needed with a ML as well. So assuming we have 1) Sysadmins who are willing to install, configure and host this 2) A migration path for 2a) existing conversations 2b) our mailing lists and, more important, whether public or private and who should be subscribed I don't see why not. If it doesn't have the mailing list mode or if it doesn't work as I suspect it to, I'd be between very hesitant and against it, because I most definitely prefer my e-mail client over yet another crappy web app that is placed in a view and sold as client. If we don't have the migration path I'd be hesitant as well, unless we have a decent solution to - have continuity and not a sudden break / change, as there are ongoing conversations (and running both in parallel is very bad) - make sure we have the manpower and plan to migrate lists and their permissions over Kind regards, Christian PS: on the side discussion of docker: I am not against docker, we use it in (soon to be) production, we orchestrate it with OpenShift. But I do have to say that it is something entirely different and thus needs people willing and able to manage it, and this also needs planning on how to integrate it in already existing infrastructure, also security wise. So if we don't have infra people already comfortable with docker, do plan some extra time to build that up. PPS: I am still not terribly fond of the argumentation "we have to move to $some_fancy_new_shit_software or otherwise people will leave us". If people are contributing to / be with KDE just because of our choice of infra software, we are most definitely doing something wrong. But I already went on about that during the anti-IRC discussion.
Re: pseudonymous contributions to KDE
Am Mittwoch, 19. September 2018, 12:34:00 CEST schrieb Luigi Toscano: > That's very bad. But: > > so I understand every person who prefers to work under a pseudonym and I > > think we should not make this impossible. > > Does it make impossible any future changes related to the software license > (from a simple relicensing to handling legal actions)? If the answer is no, > then it's sad but we can't fix the laws just by coding and sometimes even > shouting (see the EU reform). Not any more than the fact that you can't change the license without agreement of people you can't, for other reasons, get in touch with. I don't think a real name does any more than pseudonyms there: if you have no means of contact (e.g. person is MIA, person no longer has this e-mail address, ...) you have a problem, unrelated to whether the person used a pseudonym or not. If you want to use the real name as a proof of identity to validate a yay or nay to license change: that doesn't work either. So personally I don't think it does much or even any difference there. Kind regards, Christian
Re: pseudonymous contributions to KDE
Am Mittwoch, 19. September 2018, 12:02:22 CEST schrieb Luigi Toscano: > > Same as above on the whole. At least in Scotland there's no > > restrictions on what name you chose to use for any purpose as long as > > it's not for fraud. Obviously the harder it is to prove a name > > matches to a real person the harder it would be to test in a > > worst-case-scenario court case but I think limiting it would just > > limit our contributions for no good reason. > > The possibility of a court case (and all the complications related to > copyright laws) is a good enough reason. I have seen at least 4 FOSS projects with the opposite problem: a specific person using that info to harass people, including: - calling them at their home - slandering their name, including false accusations most horrible crimes - calling their employers and families, trying to get them in trouble so I understand every person who prefers to work under a pseudonym and I think we should not make this impossible. Kind regards, Christian
Re: freenode #live conference in Bristol: speakers, booth?
Hi Adriaan, List, as said, last time it was David Edmundson who came, not sure if he'd like to do it again, but I think he did great work. As for talks: basically everything from online privacy to free software, so I'm sure plenty of things KDE offers would be on-topic. As I read earlier today, technically the CFP is closed, but we are still looking for talks. As I am currently on a bit of holiday: if you could do me a huge favour and poke christel (christel at freenode dot net) directly and get in touch with her as soon as you can, i'd be very grateful. Thanks in advance and kind regards, Christian Am Freitag, 7. September 2018, 21:43:45 CEST schrieb Adriaan de Groot: > On Monday, 27 August 2018 13:10:52 CEST Christian Loosli wrote: > > this year the second freenode #live conference will take place in Bristol > > 3rd and 4rd of November, 2018. For details: https://freenode.live/ > > There's not been a lot of community uptake on this; I think it would be > cool, though. So, c'mon, who is in the UK and up for a couple of days of > Bristol, giving a talk maybe, rubbing shoulders with Debian and other > friends. > > I'm willing to coordinate a booth, handle getting stuff and swag there, I > could give a talk or two, but I can't do it alone. > > Christian, how are talks (lightning talks, I presume), what kind of topics > are you looking for? The conference schedule is a bit light still. > > [ade]
Re: Improving Bugzilla Status Names
Am Mittwoch, 5. September 2018, 11:36:45 CEST schrieb Martin Steigerwald: > Isn´t there RESOLVED / UNMAINTAINED, when product is no longer > supported? It has, leaves us with the other cases. Christian
Re: Improving Bugzilla Status Names
Am Mittwoch, 5. September 2018, 04:28:05 CEST schrieb Andrew Crouthamel: > Hello, Hi, thanks for your work and looking at this, I agree with them except > WONTFIX -> ASDESIGNED > INVALID -> NOTABUG which make it, in my opinion, less clear. WONTFIX is not only used when something is "as per design", but also in cases such as product no longer supported, a third party thing used (e.g. an interface) doesn't allow it etc. So "ASDESIGNED" is less clear / sometimes just wrong. I also don't think that the language needs softening up, because the end result will be the same: the user who reported the bug or wish does not get what they wanted, so it should be clear and match what the user will get. NOTABUG fails for similar reasons. Bugzilla is also used for feature requests / wish lists. These aren't bugs by definition, but they can be valid. Also bugs can be bugs but still the report can be invalid for other reasons. In both cases I think the important thing is that whoever sets this status should write in the comment why something won't be fixed or why something is invalid. The status is meant to be short and clear, in the proposals I think that clarety is removed a bit. Rest sounds good to me. > Thanks! > Andrew Crouthamel Kind regards, Christian
Re: freenode #live conference in Bristol: speakers, booth?
Hi Adriaan, thank you very much for the offer, > Have we got people on the ground nearby? That's always easier than shuffling > people around the continent. > > [ade] (who hasn't got anything scheduled in November, yet :) ) we have got David Edmundson, he was there last year, not sure if he would like to come again, even if there is another round of decent dinner, funny guests and juggling possibilities ;) But yes, d_ed is close-ish, I think. Kind regards, Christian Am Donnerstag, 30. August 2018, 15:16:36 CEST schrieb Adriaan de Groot: > On Monday, 27 August 2018 13:10:52 CEST Christian Loosli wrote: > > this year the second freenode #live conference will take place in Bristol > > 3rd and 4rd of November, 2018. For details: https://freenode.live/ > > Huh, if I catch the train right now I could be in Bristol before midnight > (my measure of "not *that* far away"). > > > We (freenode) are still looking for speakers and we also have room for > > exhibitors. Knowing that KDE in the past did exhibit at other conferences > > like FOSDEM and also last year at #live: would it make sense to again have > > a KDE stand there, with some promo / stuff to show? > > I think so -- we were at EduCode this week, also an end-users-meet-upstream > kind of event, which was useful in its own way. > > > I think this is not only a great opportunity to present KDE software end > > projects, but also to maintain the very good relationship between KDE and > > freenode, as we (KDE) not only use freenode infrastructure, but also got a > > sponsor and recent donations from the surroundings of freenodians. As I > > will be busy wearing my freenode hat at #live, I'm afraid I can't do the > > KDE part. >
Re: Babe project - Legal feedback
Hey Camilo, not an expert but I recommend you to ask a lawyer. Just think of Youtube: There are different viewing restrictions depending on the country you are living in. Maybe streaming audio is equal... You could also ask the streaming service providers how to proceed... Cheers, Christian Am 03.02.2018 17:07 schrieb "Camilo Higuita Rodriguez" < chigui...@unal.edu.co>: > Hi,everyone > > I'd like to discuss something with the community, and maybe get some legal > input: > > As some of you might already know I'm working on a open online platform to > share music information between users, such as public playlists, comments > on tracks and on the playback progress like soundcloud, share popular music > suggestions, metadata, and discovery of new music from another users with > integration with YouTube and Spotify etc... the platform will be integrated > into Babe music player and could be use in any other music player > > The legal matter comes here: > 1- I would like to either have the option to *stream live* the music an > user is currently listening to to a group of friends. here the music file > isn't being storaged in the audience computer... > How ilegal is it? How illegal is to stream live, but privately, > copyrighted music? and how illegal is it to stream owns music content to a > selected group of friends? > > 2- If the stream part wouldn't be enought problem, I'd also like to sync a > user playlist marked as public to some other friends, that would mean to > share music files between users, and technically downloading another users > music files. How illegal is this part? how illegal is to share a music file > for example, in a conversation in telegram or whatsapp, or even how illegal > is it to send a mp3 to a friend over an email or even over google drive? > > I'd like to get feedback about this issues. > > As the project is going to be hosted by the KDE community this streaming > part won't be implemented to avoid legal issues, but however I would like > to have this discussion to get as many feedback as possible. > > Thank you. > > Camilo > > >
Re: Status of Wayland implementation on nVidia graphics cards
Hi Roman,
thank you for the information! I have decided to go for a bug report (a
few days ago). You can find all the details (incl. logs, pictures and
videos (links to youtube) right here:
https://bugs.kde.org/show_bug.cgi?id=385007. Would appreciate your analysis!
Cheers,
Christian
On 9/29/17 8:44 PM, Roman Gilg wrote:
Hi Christian,
you find a log in "~/.local/share/sddm/wayland-session.log".
After your session doesn't react anymore reboot and log into X
session, where you can read the log out then (in X session it will log
to "~/.local/share/sddm/xorg-session.log").
Before asking again for help you may find a solution already by
looking at the log yourself. I suspect an update of kernel or mesa
might already help you. Also make sure you're using the HWE stack of
Ubuntu 16.04 with updated X.Org.
When this helps, please let us know. When this doesn't help feel free
to ask again in a reply (with the log attached).
Cheers,
Roman
On Thu, Sep 21, 2017 at 11:45 PM, Christian Ohrfandl
<christian.ohrfa...@gmail.com <mailto:christian.ohrfa...@gmail.com>>
wrote:
Hello Martin,
thank you for the link and the quick reply!
I definitely use Nouveau:
lspci -k | grep -EA3 'VGA|3D|Display'
01:00.0 VGA compatible controller: NVIDIA Corporation GK104
[GeForce GTX 760] (rev a1)
Subsystem: Micro-Star International Co., Ltd. [MSI] GK104 [GeForce
GTX 760]
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
When choosing the wayland session and logging in, only black
background (on the other monitor the chosen wallpaper and some
desktop icons) and a bigger cursor loads (c.f. attached picture);
no interaction with system possible (tried this several times;
sometimes the background one the other monitor does not even
load). I have made a video I could share with you, if you want to...
Are there any logs I may view in order to resolve the issue after
turning the PC off and on again? Shall I file a bug report?
Cheers,
Christian
On 9/21/17 5:20 PM, Martin Flöser wrote:
Am 2017-09-20 20:22, schrieb Christian Ohrfandl:
Dear KDE community,
I just installed KDE Neon Git unstable from September 19th
2017 on may
main computer. I want to use Wayland (because of testing and
submitting potential bug reports), but I can't (after user
login,
screen is black with a big cursor, but I can not interact
with the
session; most probably because of my nVidia Geforce 760
graphics
card).
Therfore, I want to ask how mature Wayland/nVidia
implementation is?
Does it work in general? If so, which driver (nouveau or
proprietary)?
Is there a (bug)tracker?
NVIDIA has an own implementation (EGLStreams) which we do not
support and do not plan to support (more information in my
blog at [1]).
Nouveau should work, though I haven't tested it yet.
Cheers,
Martin
[1]
https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/
<https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/>
Status of Wayland implementation on nVidia graphics cards
Dear KDE community, I just installed KDE Neon Git unstable from September 19th 2017 on may main computer. I want to use Wayland (because of testing and submitting potential bug reports), but I can't (after user login, screen is black with a big cursor, but I can not interact with the session; most probably because of my nVidia Geforce 760 graphics card). Therfore, I want to ask how mature Wayland/nVidia implementation is? Does it work in general? If so, which driver (nouveau or proprietary)? Is there a (bug)tracker? Thank you in advance! best regards, Christian
Re: Survey for prioritization of requirements for an IM/chat solution for KDE
Hi Thomas, all, First of all: thanks for putting the survey up. I think the idea of matching these to protocols in a wiki is also good, and I can gladly help with the IRC part. As a wiki is more a binary (or trinary, in this case) thing I shall give a bit of a longer read on the points here: With my KDE hat on: The survey is quite what I expected, even though the Telegram like GUI, Avatars and Stickers got even less love than I expected . >From a protocol side of view, to me it is rather clear that the combination of IRC and Matrix will cover the biggest amount of points, so protocol-wise I recommend a status quo, using IRC (freenode?) with a decent Matrix bridge. Because: Both protocols, especially together, fulfil most if not all of the must have requirements, from FOSS to free clients, protocol development and type. Impact on KDE infra should be minimal, as freenode can gladly continued to be used, and whether we want to host our own Matrix server or not is not mandatory and to be defined. The wide availability of various clients covers most cases, e.g. people who want easier file sharing, cross device history (without having to use an existing or set up an own bouncer) or a slightly more modern protocol can gladly use Matrix. Those who want a more IRC like client for big / very active channels, those who want or need a CLI client, those who prefer anonymity (using Tor, being able to use chat without having to provide any personal details or registering at all) can use IRC. The availability of web clients should also cover availability in most countries, universities and the likes, whilst Tor (little caveat, see below, freenode) takes care of the others. With this combination I think we can cover the biggest amount of must have, inclusion and attractors, and also some of the "nice to have" ones. Now of course there is room for improvement. Right now you have to go for some compromises if you choose one solution over the other (important: you have, not the other users. So nobody "suffers" because you use either IRC or Matrix) If we had an official Matrix client, we would have these features available for people whilst not sacrificing integration into the desktop and resource usage. If our IRC client would support file sharing (which is technically possible, even with drag and drop) and stuff like opt-in image previews, IRC people would not miss out on these features either. So if someone had the time, it would be great if we had some improvements in the IRC client (file sharing, image previews, maybe other) and a native Qt/KDE Matrix client (desktop integration, resource usage, ...) Now with a freenode hat on: Still the survey is more or less what I expected. And from a freenode PoV, the IRC with matrix bridge solution also sounds good. Whilst Matrix currently is not the solution we at freenode are focusing on, we are working closely with Matrix devs to improve the current bridge and iron out some of the known caveats. So it's unlikely that the bridge will go away or get worse, it's more likely that it will improve (e.g. stability, being able to deal with invexes, removes etc.) There are some open points we (freenode) have to work on, and these are known. There is e.g. the chicken egg problem of not being able to use Tor without registering an account first, as otherwise we'd see even more abuse from Tor. Registering an account can't be done via Tor yet. There are also, as per above, known issues in the Matrix <> IRC bridge (which we do not maintain, but we have an interest of it improving). We are working on these though. *hats off* tl;dr: the status quo of protocols, IRC with Matrix bridge, covers a great amount of these points, especially the must have and including ones. Client-side there is room for improvement, but that's way easier and better than switching around protocols. Kind regards, Christian
Re: Splitting Craft, move the recipes to GitHub
On Wed, Aug 23, 2017, at 03:33 PM, Hannah von Reth wrote: > Hi everyone, > Hey, > We have been thinking about splitting the Craft recipes into a separate > repository for some time now. > To have a Craft core and the recipes separated would enable us to > provide more stable user experience. It would allow us to use the latest > recipes with the stable core. > I think that is an excellent idea =) It would allow people like me to maintain a stable set of buildscripts while being able to use the latest of the buildtool itself. > At the same time Craft tries to get rid of the image as the KDE Windows > build tool. > > Craft offers recipes for many libraries and non KDE applications. > Additionally Craft offers support for Mac, Linux and FreeBSD. Neat! > In order to reach more people we intend to move the recipes to GitHub to > enable non KDE contributors to add their recipes. > Craft would continue to be a KDE Project on the KDE infrastructure, only > the recipes would move. Enough has probably been said about that. Maintaining the KDE buildscript on KDE infrastructure makes a ton of sense to me. Having a separate repository on github for more github focused projects also makes a lot of sense to me (the alternative being to have a read/write mirror). I think having to deal with multiple repositories will introduce some additional complexity as you might need to allow dependencies between them, but I also think it would be a very valuable feature. Anyways, I'd just put the KDE buildscripts on the KDE infra, create a github mirror for now, and then in the long run work on repository dependencies so it's not necessary to duplicate buildscripts in all repositories. Cheers, Christian
Re: KDE exhibiting at freenode live in Bristol, maybe?
Hi Boudewijn, thank you very much, of course that would be great. Reusing assets sounds good, I assume that #live will be way smaller than the Qt World Summit, thus even if there are only "leftovers" of promo material that should probably be sufficient. Do let me know if there is anything I can do from our (freenode) side or if you need further information. Of course specific KDE projects, like e.g. Krita or Digikam or ... are also free to present, and if someone would like to give a talk: the submission period is over, but I think we have a few slots left, so I'm sure we could organize something. Would be great to see KDE there :) Kind regards, Christian (Fuchs on freenode) Am Montag, 21. August 2017, 20:25:38 CEST schrieb Boudewijn Rempt: > That sounds like a lot of fun! I've already entered for the qt world summit, > though, and this is awfully close. I wonder whether we can figure out > whether we can reuse the assets we're creating for the qt world summit for > this... > > I'm also wondering whether I and Irina can manage to do go there... I can do > booth duty, and we could possibly tack on a week of vacation time in > England, in another place than London. Would be a first for me. > > Anyway, I'd like KDE to show up there. > > Boud > > On Mon, 21 Aug 2017, Christian Loosli wrote: > > Dear list, > > > > I hope this is not considered spam, as it is me somewhat wearing multiple > > hats (freenode and KDE): > > > > freenode has a live conference, called freenode #live, taking place at At- > > Bristol Science Centre in Bristol, UK, October 28-29th 2017 - https:// > > freenode.net/news/freenode-live-exhibit and https://freenode.live/ has > > further details. > > > > Among speakers we also have room for exhibitors. Knowing that KDE in the > > past did exhibit at other conferences like FOSDEM: would it make sense > > to have a KDE stand there, with some promo / stuff to show? > > > > It's the first time #live takes place, so obviously it is a lot smaller > > than e.g. FOSDEM, but I think we already have an interesting list of > > speakers and thus hope to attract people from various FOSS projects, > > developers, users, translators and just people interested, to drop by. So > > of course it would be fancy if KDE also had some presence there. > > > > If you are interested or need more details, feel free to poke me either > > via E- Mail or of course on IRC. I'll also gladly lend a helping hand, > > but I assume I'll be mostly busy doing exactly that on a larger scale, so > > I e.g. can't do the stand myself. > > > > Thanks in advance, kind regards, > > > > Christian (Fuchs on freenode)
KDE exhibiting at freenode live in Bristol, maybe?
Dear list, I hope this is not considered spam, as it is me somewhat wearing multiple hats (freenode and KDE): freenode has a live conference, called freenode #live, taking place at At- Bristol Science Centre in Bristol, UK, October 28-29th 2017 - https:// freenode.net/news/freenode-live-exhibit and https://freenode.live/ has further details. Among speakers we also have room for exhibitors. Knowing that KDE in the past did exhibit at other conferences like FOSDEM: would it make sense to have a KDE stand there, with some promo / stuff to show? It's the first time #live takes place, so obviously it is a lot smaller than e.g. FOSDEM, but I think we already have an interesting list of speakers and thus hope to attract people from various FOSS projects, developers, users, translators and just people interested, to drop by. So of course it would be fancy if KDE also had some presence there. If you are interested or need more details, feel free to poke me either via E- Mail or of course on IRC. I'll also gladly lend a helping hand, but I assume I'll be mostly busy doing exactly that on a larger scale, so I e.g. can't do the stand myself. Thanks in advance, kind regards, Christian (Fuchs on freenode)
Re: Telemetry Policy
Am Mittwoch, 16. August 2017, 11:46:12 CEST schrieb Volker Krause: > Valid point, I've added a statement to the policy asking distributors of our > products to respect the rules too. Thank you very much :) > I don't think we can make this a hard requirement (as in: you lose the right > to distribute our software), in my understanding that would be conflicting > with the freedom guaranteed by the GPL. You indeed can't. And whilst I personally think that the GPL is a not so great license, better ones don't accept that either. And GPL is set, so that's hypothetical anyway. That's perfectly fine though, fortunately there are distributions to choose out of, so if one decides it would like to override privacy setting recommendations from upstream, I think users concerned with that kind of thing can and simply will switch distributions. > Regards, > Volker Thanks for your work, kind regards, Christian
Re: Telemetry Policy
Am Mittwoch, 16. August 2017, 00:33:02 CEST schrieb Valorie Zimmerman: > I think the entire page might be enlightening to this discussion. I > believe our analysis of needs should be more fine-grained, and that > some parts of what we need can be "default on" especially for > pre-release testing. For releases, we can provide an opt-out. I'm afraid that at the very moment KDE starts transmitting my data, no matter what data, as opt-out, I'll opt out of supporting and using KDE products, and I assume a lot of people will do the same. This is, in my opinion, the exact opposites of our very principles and manifesto, and I would not jeapardize our reputation just to gather some data, to be honest. It would create reputational damage that is hard to fix (people still remember the Unity amazon thing) I do admit that I have very strong views when it comes to privacy and data usage though. > Other more sensitive data will need to be opt-in. I think it's a > mistake to treat all the data we might want all in the same way. > > Valorie Kind regards, Christian > On Sun, Aug 13, 2017 at 3:18 AM, Christian Loosli > > <christian.loo...@fuchsnet.ch> wrote: > > Hi, > > > > thank you very much for this work, sounds great! > > > > Only point I have: maybe make sure that the opt-in / default settings are > > not only mandatory for application developers, but also for packagers / > > distributions. > > > > Some distributions have rather questionable views on privacy and by > > default > > sent information to third parties, so I would feel much more safe if they > > weren't allowed (in theory) to flick the switch in their package by > > default to "on" either. > > > > Kind regards, > > > > Christian
Re: Conservative proposal: let's work with Kiwi IRC
Hi, thanks for posting to the list! I mostly agree, even though I am unsure of how certain things could be implemented, e.g. > * Editing messages which IRC simply does not support. So my best guess would be that this only works for people using the Kiwi solution, or the IRC people will see both the old and the edited message. Stickers and uploads and whatnot could be handled like the Matrix bridge does, i.e. IRC users will see a link they can click on to get it. Not ideal, but still my preferred solution next to the bridges, as: - based on existing infrastructure - covers some of the bigger pain points - has, from what I can see, an okay UI for the "IRC like" point, a more Telegram like one would have to be coded - We (freenode) already work with Kwi more or less (more more than less) closely, so from freenode side this should all be fine Kind regards, Christian
Re: Telemetry Policy
Hi, thank you very much for this work, sounds great! Only point I have: maybe make sure that the opt-in / default settings are not only mandatory for application developers, but also for packagers / distributions. Some distributions have rather questionable views on privacy and by default sent information to third parties, so I would feel much more safe if they weren't allowed (in theory) to flick the switch in their package by default to "on" either. Kind regards, Christian
Re: radical proposal: move IRC to Rocket.Chat
Am Donnerstag, 10. August 2017, 21:22:04 CEST schrieb Thomas Pfeiffer: > On Donnerstag, 10. August 2017 20:38:11 CEST Christian Loosli wrote: > > Am Donnerstag, 10. August 2017, 20:31:22 CEST schrieb Thomas Pfeiffer: > > > On Donnerstag, 10. August 2017 18:40:34 CEST Christian Loosli wrote: > > > > Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > > > > > LibreOffice are having a similar discussion > > > > > > > > > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > > > > > > > > > They want to continue using IRC though which means fragmentation > > > > > would > > > > > continue. > > > > > > > > Maybe someone should inform them that there are bridges available to > > > > avoid > > > > that. > > > > > > > > But maybe they'd simply ignore that, multiple times, and go on, as > > > > some > > > > people seem to do in this thread as well *shrug* > > > > > > Who ignored the possibility of bridges? > > > > Why are we still discussing, then? As I pointed out twice: bridges not > > only > > exist, but they are already in place. So unless people want to get rid of > > IRC (or one of the other protocols, for that), it is pointless to discuss > > which client/protocol to take, since it already either is bridged or not > > bridgeable yet, but soon to be. > > And then the answer is clearly "IRC plus bridge", and both this whole > > thread and the etherpad can be abandoned. > > Erm... no. IRC is a "legacy option" for people who don't want to use other > protocols for whatever reason. That is perfectly fine for them, that's why > we're keeping it. > > However, if the people who _do_ want to use something more modern end up > using 10 different things, then the benefits are practically non-existent. > Most of the nice features of modern protocols work only among those who use > the same one. > > Therefore, to get any benefit, we, the people who want something modern, > have to agree on one thing. You, the old-school IRC lovers, can feel free > to completely ignore us while we search for something that checks all our > requirements, we bridge it to IRC, everybody is happy. Friendly reminder that - the protocols that are bridgeable are bridged and already usable - the people who want to switch to these already can - the people who don't want to already can. This is the status quo, thus saying that unless you plan to get rid of things or move things, the discussion is pointless, as it represents the status quo. > > > Where does Martin Steigerwald's impression come from that people want to > > > make this an "either/or decision"? > > > > > > The only person who seems to want to get rid of IRC is Jonathan, > > > > Okay, this is a qft moment. How can you possibly write "where does > > $person > > impression come from that people want to make this an either/or decision" > > when you write, at the very next line, that for someone, the thread > > starter > > to be precise, it is? > > Jonathan Riddell. Singular. One guy. Not "people". Not only that people is entirely allowed and correct in English, but also see above: unless you want to move / change, the debate is pointless, I assume that is why various people, not only me, got that impression. > > > I never said that. Martin Klapetek never said that. > > > Yes, we both think that IRC is not suitable as the _only_ chat tool for > > > a > > > community in 2017. > > > > I never pointed fingers at you. I said that some people seem to see it as > > an either/or, which you agree with, and that people seem to ignore that > > bridges already exist and are in place (at KDE, not in general, mind), > > so the logical conclusion is that, unless it becomes an either/or, this > > whole thing is completely pointless. > > Again. Jonathan. One. See above. > I, for one, did not chime into this discussion because I wanted to get rid > of IRC. I chimed in because I got the impression from some of the replies > that there would be no need to use anything other than IRC, because it has > everything we need. > I still strongly disagree with that. Nope, see above. People pointed out, various times by now, that IRC is the lowest common denominator and that the rest not only can be bridged, but is bridged. So people who want to move to any of these protocols already can, and there is no point to discuss benefits and disadvantages of the various
Re: radical proposal: move IRC to Rocket.Chat
Am Donnerstag, 10. August 2017, 17:25:14 CEST schrieb Jonathan Riddell: > LibreOffice are having a similar discussion > > https://listarchives.libreoffice.org/global/projects/msg02257.html > > They want to continue using IRC though which means fragmentation would > continue. Maybe someone should inform them that there are bridges available to avoid that. But maybe they'd simply ignore that, multiple times, and go on, as some people seem to do in this thread as well *shrug* Christian
Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)
> What I’ve argued strongly against is the standpoint that we should stick > with the status quo. The status quo _is_ things with the advantages of Telegram or Matrix available, since these two are already bridged. Hence my earlier > Last but not least: if IRC really is so much of an issue, which I doubt: there are solutions readily available (Tg and Matrix bridge) or available in the future (Rocket bridge) which do resolve the problem whilst still maintaining compatibility for people who prefer what worked for 20 years and still works. So the reasons to continue with a replacement I can see are either "We want to get rid of the other one completely and enforce this one" or "we want it NOW", both of which I heavily have to disagree with [...] If you want Rocket, for whatever reason, see my other post which was so far mostly ignored.
Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)
Am Mittwoch, 9. August 2017, 16:12:51 CEST schrieb Martin Klapetek: > On Wed, Aug 9, 2017 at 2:51 PM, Christian Loosli <k...@fuchsnet.ch> wrote: > > Okay, this is more and more drifting away from being remotely productive > > or > > helpful, but as I provided a working solution on top level, I feel free to > > tacke a few points that are, in my opinion, odd at best. > > > > First let's tackle that mysterious group of < 20 year olds: > > > > Is there any such organization at all? > > > > > > Sure there is! Look at the tech startup scene, or the games industry. > > > But okay, let’s say “predominantly younger than 30” to make it an easier > > > task. > > > > But KDE is not a tech startup. As people correctly wrote, KDE has a very > > long > > history and contributors of all age. I'd rather be that than one of the > > many > > tech startups with a bunch of little to no experience but fancy new chat > > systems, to be honest. Do we really want and need to cater these mystical > > tweens so much? > > Yes. Old contributors will slowly fade away for various > reasons, be it life, be it lack of energy, be it other commitments. Yes. Young talents will fade away for various reasons, be it life, having kids and a family or starting a career. > Who's going to pick all those projects up after them? I'd like > to think that young enthusiasts with lots of energy and potential, > exactly what those heroes starting the original KDE were. Who is going to be there for these new talents that lack experience? You need both, thus catering for one group specifically is, in my opinion, stupid. > > Are they the holy grail that saves KDE and worth alienating > > the people who are not this particular group? > > It's not mutually exclusive. This thread has a couple of very good examples of people feeling alienated due to it, so I'd dare to say it is a problem. > > Even if that is the case, to answer your question: Yes, there are such > > companies, plenty even. Basically a lot of companies which are exactly not > > in > > the small bubble that is "tech start up", but other industries. Also > > companies that actually have to do business with other companies, where > > mail > > simply still is the standard. > > > > > > Then, on the subject of emojis, stickers or even the protocol used being > > so > > important: > > > > Let's see what others do. Let's take our main, most famous friendly > > competitor > > GNOME. They even run their very own IRC network still, and actively code > > new > > IRC applications. > > Mozilla? Own IRC network. > > Reddit, quite the place for young techies and startup? Created their own > > IRC > > network. Hardly turning off or away people, it seems. If we fail to > > attract > > fresh blood, then maybe the problem is not actually "we use IRC". > > > > But even if it would: to be honest, if someone decides what project they > > want > > to contribute due based on what chat protocol they use internally, I'm > > personally not sure if that is a well suited candidate due to rather odd > > priorities. > > I think your view is a different angle - it's not that they would > choose a project to contribute to based on what chat they use, but > they would choose a project they feel most comfortable in. And yes > day to day communication does make a big part of that comfort. Dear god no. Most of that is actually the content, and not the protocol of that communication. The bickering we have on mailing lists, including people threatening to leave the project and year old feudes cooking up occasionally is way more a reason to stay away from a project than the protocols they may use. > No matter how you look at it, IRC /is/ behind any other IM apps/protocols > today. Young engineers communicate and prefer to communicate > differently than you or me. I lead a team of young (19 - 26) engineers, and I'm afraid I have to disagree with such blanket statements. Not to mention that freenode, _the_ very IRC thing, has a big amount of staffers that are between 20 and 25 and also people below 20. > I think it's absolutely crucial to understand > them and their views/ways/whatever. Neglecting them would be a mistake. Alienating long term contributors, switching around protocols fragmenting the community and not gaining new people regardless, because it was other things that kept them away, would be a mistake. > Cheers > -- > Martin Klapetek Kind regards, Christian
Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)
Okay, this is more and more drifting away from being remotely productive or helpful, but as I provided a working solution on top level, I feel free to tacke a few points that are, in my opinion, odd at best. First let's tackle that mysterious group of < 20 year olds: > > Is there any such organization at all? > > Sure there is! Look at the tech startup scene, or the games industry. > But okay, let’s say “predominantly younger than 30” to make it an easier > task. But KDE is not a tech startup. As people correctly wrote, KDE has a very long history and contributors of all age. I'd rather be that than one of the many tech startups with a bunch of little to no experience but fancy new chat systems, to be honest. Do we really want and need to cater these mystical tweens so much? Are they the holy grail that saves KDE and worth alienating the people who are not this particular group? Even if that is the case, to answer your question: Yes, there are such companies, plenty even. Basically a lot of companies which are exactly not in the small bubble that is "tech start up", but other industries. Also companies that actually have to do business with other companies, where mail simply still is the standard. Then, on the subject of emojis, stickers or even the protocol used being so important: Let's see what others do. Let's take our main, most famous friendly competitor GNOME. They even run their very own IRC network still, and actively code new IRC applications. Mozilla? Own IRC network. Reddit, quite the place for young techies and startup? Created their own IRC network. Hardly turning off or away people, it seems. If we fail to attract fresh blood, then maybe the problem is not actually "we use IRC". But even if it would: to be honest, if someone decides what project they want to contribute due based on what chat protocol they use internally, I'm personally not sure if that is a well suited candidate due to rather odd priorities. Last but not least: if IRC really is so much of an issue, which I doubt: there are solutions readily available (Tg and Matrix bridge) or available in the future (Rocket bridge) which do resolve the problem whilst still maintaining compatibility for people who prefer what worked for 20 years and still works. So the reasons to continue with a replacement I can see are either "We want to get rid of the other one completely and enforce this one" or "we want it NOW", both of which I heavily have to disagree with for various reasons already mentioned. TL;DR: no. Kind regards, Christian
Re: radical proposal: move IRC to Rocket.Chat
Hi, Yup, I am aware, I already did spread that freenode internally a couple of weeks ago (when I saw the first post on planet KDE), thanks. Our current issue is more the mix of authentication systems and to use something like SAML or the likes to integrate them, which, as far as I am aware, is not a point resolved in brooklyn (minor sidenote: that name is already taken by the apache foundation). I'm sure we'd get in touch with them once we are in a stage where we tackle the problems brooklyn tackles, unfortunately as an already existing network we have a couple of additional things to tackle first. Thanks for the info, kind regards, Christian Am Mittwoch, 9. August 2017, 09:49:27 CEST schrieb Cristian Baldi: > We have a GSoC student working on a RocketChat<~>Telegram<~>Irc bridge > which as of now has support for files, images, video messages and so on. > Take a look here > http://rivadavide.blogspot.com/2017/08/brooklyn-02-released-ready-for.html > . We are using it at WikiToLearn and it is working fine. > > On Wed, Aug 9, 2017, 11:28 Christian Loosli <k...@fuchsnet.ch> wrote: > > Post Scriptum, as I discussed this and learned that what I hinted at in > > the - > > cafe channel yesterday is public information: > > > > We (freenode) are looking into support (not moving to, mind) for rocket. > > Some details can be found here: https://www.facebook.com/eximious/posts/ > > > > 10155436766365761?comment_id=10155438680590761_tracking=%7B%22tn%2 > > 2%3A %22R3%22%7D > > <https://www.facebook.com/eximious/posts/10155436766365761?comment_id=1015 > > 5438680590761_tracking=%7B%22tn%22%3A%22R3%22%7D> > > > > (sorry for facebook link, quote for those who rather not: > > "We (freenode) have had quite a few conversations with projects that > > struggle > > with Slack -- they use it but are finding it difficult, partly because it > > is > > proprietary and doesn't align too well with their values and partly > > because it > > is resulting in a great deal of community fragmentation. We're currently > > looking at implementing rocket.chat support to allow projects such as > > those to > > map their own rocket.chat instances to their channel namespace on freenode > > in > > a bid to reduce the community fragmentation they experience. Totally > > hoping > > that it will solve those issues for them!") > > > > which might be a solution that pleases both people who want to use Rocket > > and > > people who want to not abandon other more or less well used protocols. > > > > Bonus points: due to the Matrix and Telegram bridge we already have, if we > > manage to properly integrate Rocket, one can probably use either of the > > four > > and be happy. Obviously with some loss of features, as e.g. protocol a > > might > > not support something of protocol b. How well this will be implemented > > depends > > on the bridge, e.g. files or stickers could be integrated via links iff > > someone > > codes that. > > > > Unfortunately IRC would still not get support for animated stickers and > > custom > > pile of poop emojis, sorry to crush hopes there. > > > > Sorry for not mentioning this earlier, I wasn't sure at this very early > > stage > > whether it is public or not. > > > > Regards, > > > > Christian
Re: radical proposal: move IRC to Rocket.Chat
Post Scriptum, as I discussed this and learned that what I hinted at in the - cafe channel yesterday is public information: We (freenode) are looking into support (not moving to, mind) for rocket. Some details can be found here: https://www.facebook.com/eximious/posts/ 10155436766365761?comment_id=10155438680590761_tracking=%7B%22tn%22%3A %22R3%22%7D (sorry for facebook link, quote for those who rather not: "We (freenode) have had quite a few conversations with projects that struggle with Slack -- they use it but are finding it difficult, partly because it is proprietary and doesn't align too well with their values and partly because it is resulting in a great deal of community fragmentation. We're currently looking at implementing rocket.chat support to allow projects such as those to map their own rocket.chat instances to their channel namespace on freenode in a bid to reduce the community fragmentation they experience. Totally hoping that it will solve those issues for them!") which might be a solution that pleases both people who want to use Rocket and people who want to not abandon other more or less well used protocols. Bonus points: due to the Matrix and Telegram bridge we already have, if we manage to properly integrate Rocket, one can probably use either of the four and be happy. Obviously with some loss of features, as e.g. protocol a might not support something of protocol b. How well this will be implemented depends on the bridge, e.g. files or stickers could be integrated via links iff someone codes that. Unfortunately IRC would still not get support for animated stickers and custom pile of poop emojis, sorry to crush hopes there. Sorry for not mentioning this earlier, I wasn't sure at this very early stage whether it is public or not. Regards, Christian
Re: radical proposal: move IRC to Rocket.Chat
Am Dienstag, 8. August 2017, 20:05:16 CEST schrieb Jonathan Frederickson: > Matrix has all of these, with the exception of perhaps "Multi-identity" > and "Anonymous." (But it's HTTP, so you can tunnel it over Tor, there's > no real name requirement as it's an open federated protocol, and you can > create multiple accounts and use them for different purposes if you want.) Matrix gets these via the IRC bridge if needed, since we (freenode) do support Tor more or less natively, and obviously IRC also supports multi-identity. > (By the way, I'm not affiliated with the Matrix project at all - I'm an > enthusiastic user, and I've contributed Matrix support to a chatbot, but > that's it!) I'm fine with Matrix, we (freenode) are currently collaborating with them in order to fix the various broken things in their bridge, once that is done, I'd say it's a decent thing. Personally I wouldn't use it, but the good thing is: I don't have to, it is bridged already. Kind regards, Christian
Re: radical proposal: move IRC to Rocket.Chat
Am Dienstag, 8. August 2017, 21:52:12 CEST schrieb Jonathan Riddell: > On 8 August 2017 at 19:51, Christian Loosli <k...@fuchsnet.ch> wrote: > > Out of interest: what exactly does IRC lack? There are 4 things coming to > > mind > > for me, all of them with my personal opinion: > Option for full names, IRC has the GECOS field, in most clients even called real name, _exactly_ for that reason. Some people (e.g. me) use it for that: their real name. This is part of the protocol and has been for ages. > photos of people, Some clients, like kvirc, have support for that as well. See below. > timezone, can be added as metadata if wanted, we (freenode) do support it. (we support arbitrary string metadata, we just no longer display it by default because people thought it would be hilarious to do antivirus signatures or ASCII porn, not kidding) > e-mail addresses. mandatory field on freenode, just hidden by default for privacy reasons, but can be configured to be shown for those who want to (I wouldn't recommend it, to be honest). So out of these: one that isn't supported out of the box on all clients, being a picture or avatar. Whether that makes sense in channels like #kde with ~500 users is imo a bit debatable, and definitely a bandwith and ressource hog. > Looking at #kde-devel just now it says: > <-- swati_27 (uid130066@gateway/web/irccloud.com/x-abaollxcgicrxgwg) > has quit (Quit: Connection closed for inactivity) > <-- nowrep (~david@kde/developer/drosca) has quit (Quit: Konversation > terminated!) > <-- stikonas (~gentoo@wesnoth/translator/stikonas) has quit (Quit: > Konversation terminated!) > <-- soee_ (~s...@bmi112.neoplus.adsl.tpnet.pl) has quit (Quit: > Konversation terminated!) > --> soee (~s...@bmi112.neoplus.adsl.tpnet.pl) has joined #kde-devel > > Show that to most people and they'll just not want to know what it means Good thing every single client coming to mind has a feature to hide these, including the official KDE client Konversation. http://wiki.xkcd.com/irc/hide_join_part_messages I'm rather sure that most other protocols, at least Telegram most certainly does, do also show when someone joined or parted a group, mind. The part they might hide is the nick!ident@host part. This is client dependent, some do and quite a lot of them can hide it. So I wouldn't really recommend switching to a completely different protocol due to "shows additional info when someone joins or leaves the group". > Jonathan Christian
Re: radical proposal: move IRC to Rocket.Chat
Hi list, first of all a disclaimer: As someone heavily involved with IRC (I am freenode staff) I am of course slightly biased. However: various communities I am in, including freenode, frequently has a look as alternative protocols. They come and, compared to IRC, they also go. (https://xkcd.com/1782/) There are various good reasons in my opinion to not move: First of all: FOSS is not only KDE. Quite a lot of us are in various communities, and a lot of them still reside on IRC. So adding another protocol and another client just increases the amount of things you need to have open and to have an eye on. Yes, there are bridges, recently even a KDE project (brooklyn), but all of them I have seen so far get various things wrong and are not as stable as IRC is. And there we come to the technical side: IRC is super lightweight. Other protocols and their clients eat tons of memory, basically "I am in 6 slack channels. 1.5GB RAM consumed by the desktop app. In 100+ IRC channels. 25MB consumed by irssi. The future is rubbish." from https://twitter.com/popey/ status/793399003463516160 I can also have IRC run on my server and connect from anywhere to it just via SSH. I can even run it on a raspberry pi or a free amazon AWS instance. So despite all these fancy features the new protocols and clients like slack, rocket, Telegram and whatnot offer: they do come at a price. With IRC we have a lightweight, well established protcol that works everywhere and we have well established communities. Switching would not help preventing the community from fragmenting. The opposite would happen, it would fragment the community even more, with questionable benefits and high prices on a resource end. I highly recommend not to. Kind regards, Christian (Fuchs on freenode) PS: if proprietary is an issue, which indeed it should be: with Mattermost there is a free, slack compatible thing, and Telegram is not terribly proprietary, neither the client(s) nor the protocol. I obviously still prefer IRC, just pointing out. Am Dienstag, 8. August 2017, 16:52:00 CEST schrieb Jonathan Riddell: > Like all sensible open source communities we use IRC lots for real > time communication essential to making low bandwidth decisions in a > reasonable timeframe as well as socialising. > > 20 years ago IRC was cool but these days real-time communication in > the non-geek world long since moved other places such as WhatsApp, > Facebook Messenger which are infinately more user friendly than IRC. > In the geek-world it has moved to Slack and Telegram. So KDE finds > itself spread between three real time communication methods with IRC > still the strongest but many new people reluctant to use it as scary > and unfamiliar while Slack and Telegram smell of being proprietary and > lacking some of the free-form nature of IRC. > > So my radical proposal for today is to consider moving all our > real-time communications wholesale to Rocket.Chat. Like Slack it takes > much of it's basic setup from IRC with #channels that anyone can set > up. Unlike Slack it's all free software and we can run our own > servers. Like Telegram it works on phones fine. Unlike IRC it > supports media files and friendly user names. > > It has a native desktop client and we have a KDE one in progress with > Ruqola. https://rocket.chat/ > > I setup up a temporary server, do come along and say hi to evaluate it. > http://ec2-34-203-38-236.compute-1.amazonaws.com:3000/ > > I'm aware this will probably end up as a case of XCKD standards > https://xkcd.com/927/ but I thought it worth a shot. We have > difficulty attracting new contributors and our community is > fragmenting because of the dominance of IRC so worth considering > alternatives. > > Jonathan
Re: Applications Lifecycle Policy
On Wed, Jul 5, 2017, at 10:18 PM, Luigi Toscano wrote: > Martin Flöser ha scritto: > > Am 2017-07-04 13:20, schrieb Jonathan Riddell: > >> The applications lifecycle policy needs an update > >> > >> Is this a good current state of it or are there more stages? > >> > > > > Hi all, > > > > I'm now going to propose a rather radical change to the process: > > > > 1. Remove extragear > > 2. Remove playground > > 3. Remove the 2 week Review process > > > > Let me explain the reasoning. > > > > [...] > Interesting, an annotation on this point: > > > > > Today I think there are way better things to measure the quality than a two > > week process on kde review: > > > > * how many unit tests does a project have? > > * how large is the test coverage? > > * how often do tests fail on build.kde.org? > > * how often does the build fail on build.kde.org? > > * is it translated? > > * does it have appstream data? > > * is the code getting reviewed? > > * is the project a one person show? > > * ... > > > > So instead of a one time review I would propose a continuous review of the > > projects and make it available in an easy accessible way so that users can > > also see the objective quality of the application. And yes that would mean > > that many long standing applications would have a way lower quality than the > > new kids on the block. > > > > For KDE Applications, Plasma and Frameworks I expect to have additional > > rules > > for integration. Frameworks already has them, Plasma kind of has them, but I > > think they are not codified and KDE Applications could e.g. start with the > > current review process. > > > > So to sum it up: I don't think there is a need for extragear and playground > > any more. When a project starts it should have the same rights and > > obligations > > as any other current extragear app. In addition we should come up with > > measurable quality facts and make them available to the community. > > This is different from what Christian said (the "dumping ground is fine > even if some details are not relevant"). This process would make clear that > not all repositories are the same, and that's fine. It's to some extend different, it improves the situation by not only having a quality badge of being part of a release that requires to match certain review criterias, but also improves it with an individual quality assessment, which is a good thing (but will require some work). It also states that all projects still have the same obligations as extragear, which is a change from what I proposed and I don't see how that would really be applicable if you don't have a playground to start. Anyways, in general it is completely in my spirit; little upfront requirements and then judge the quality of what falls out of it. Cheers, Christian
Re: Applications Lifecycle Policy
On Wed, Jul 5, 2017, at 09:37 PM, Martin Flöser wrote: > Am 2017-07-04 13:20, schrieb Jonathan Riddell: > > The applications lifecycle policy needs an update > > > > Is this a good current state of it or are there more stages? > > > > Hi all, > > I'm now going to propose a rather radical change to the process: > > 1. Remove extragear > 2. Remove playground > 3. Remove the 2 week Review process I just wanted to say that this very much aligns with my thinking and just explains it much better than I did. Thanks!
Re: Applications Lifecycle Policy
On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote: > Christian Mollekopf ha scritto: > > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > >> The applications lifecycle policy needs an update > >> > >> Is this a good current state of it or are there more stages? > >> > >> https://community.kde.org/Policies/Application_Lifecycle/Draft > >> > > > > Looks good to me for what it currently is. > > > > In general I think: > > * it should be ok to release from playground for years, or even > > potentially forever. > > Even stable releases? I disagree. > Yes. I realize that this would be a change from the current situation, but I don't think it would hurt. It would essentially allow applications to either get the extra quality badge or not as they see fit. > > * going to extragear/applications should be an extra quality badge where > > you sign up for certain requirements (which is why I think it should be > > possible to release from extragear forever. Perhaps some project is just > > not interested in translations for instance...) > > I totally disagree. If an application is not interested in the > translations (or other "details" which should be level 0) and the > maintainership does > not even agree to outsource the work for the maintainance of the > translations, I would question whether the application is fit for the KDE > community at > all. Ok, but I wouldn't. I think it could be perfectly viable for some application to say that i.e. because we only target the scientific community (I'm making some random example up), we just assume they speak english and don't care about the rest. My point is not specifically about translations, it's about requirements in general and whether it makes sense to find a "one size fits all" barrier that all applications have to pass. > > > * Abolishing the extragear/applications differentiation at this level > > would make more sense to me (extragear does have a second class feel to > > it), instead applications should just declare that they are part of the > > applications release. This would indeed also ease transitioning between > > releases and dealing with the versioning should be up to the maintainers > > (of course versions that go down are not at all something that should be > > accepted ever anywhere). > > > So basically change > > kdereview > -> KDE Applications > -> KDE Extragear > -> KDE Frameworks > -> KDE Plasma > (as mentioned by Jonathan, we are missing the last two in the graph) > > with something like > > kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", > independent release schedule). > > That sound fine, with one caveat: without having the 4 entities in > separate nodes of the graph we can't describe the transition between modules. > You > wrote that this would "ease transitioning", but I think that we may want to > capture for example the transition from "any" to Frameworks, which has > specific > rules. > And so on. 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. Cheers, Christian PS: If I don't reply anymore that is because I'm about to board a plane.
Re: Applications Lifecycle Policy
On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote: > The applications lifecycle policy needs an update > > Is this a good current state of it or are there more stages? > > https://community.kde.org/Policies/Application_Lifecycle/Draft > Looks good to me for what it currently is. In general I think: * it should be ok to release from playground for years, or even potentially forever. * going to extragear/applications should be an extra quality badge where you sign up for certain requirements (which is why I think it should be possible to release from extragear forever. Perhaps some project is just not interested in translations for instance...) * Abolishing the extragear/applications differentiation at this level would make more sense to me (extragear does have a second class feel to it), instead applications should just declare that they are part of the applications release. This would indeed also ease transitioning between releases and dealing with the versioning should be up to the maintainers (of course versions that go down are not at all something that should be accepted ever anywhere). Cheers, Christian
Re: latest draft for mission (and strategy)
On Thursday, June 22, 2017 10:23:55 AM CEST you wrote:> Hi Christian, > > On donderdag 22 juni 2017 00:02:00 CEST Christian Mollekopf wrote: ... > > You are exactly right, these documents are fairly loose and they're not meant > to be The Law, but give us all a bit more direction. That said, with a > community as large and diverse as KDE, it can't be overly specific. For that > reason, we encourage sub-projects in KDE to create a more concrete vision, > mission and strategy as well. The Krita team has done that some time ago and > it has brought them a lot more focus and as a result of that focus (and hard > work!), Krita has become the best in class in their newly found niche (which > is not meant belittling at all!). Yeah, I really like the focus and drive the Krita project seems to have, and in that regard I think they are an excellent example of how a KDE project could work. > In Plasma, we've started on the same > process, we're working on the Plasma vision right now (see the plasma-devel > mailing list) and we're planning to drill down to more specifics in that > process. Perhaps, this can be used as a template for other software as well, > I > can imagine that especially in the early stages of development (Hi Kube! :)) > it can deliver great value. Indeed. We have tried a while ago to distill something: * https://kube.kde.org/features.html * http://kube.readthedocs.io/en/latest/project/#vision-statement While I think there is a lot of room for improvement, it's an ok start for us for the time being. Cheers, Christian
Re: latest draft for mission (and strategy)
Hi, I'm new on the list so sorry for not replying to the thread. I was asked to contribute my feedback on the Vision/Mission, so here it goes. I like Vision and Mission-Statement and they generally reflect my values as well. They are very inclusive and fairly loose, which I think is the only reasonable thing for such a high-level statement, yet they still establish some values, which is good. Personally, the strategy points are not too relevant for me, so I'm not going comment on the individual points (which I too find generally agreeable, nothing in there goes against what I want to achieve), but I'm going to comment on why they are not too important to me instead. To me, KDE is not one project. We're a diverse bunch of people working on a variety of projects with different goals and ideas. As such, as much as I can agree with individual strategy points, those are ultimately up to the individual projects and their people. Those strategic decisions are always tradeoffs, and as such must be made on a case by case basis. I think it's entirely fine for an application to decide to not be translatable, or to only run on a certain platform, these are decisions for the individual projects and people to make, and sometime heavily depend on individual goals projects set for themselves. The strategy points are fine examples how the vision *could* be pursued, but that's all they are to me, so I think there is little point in trying to fine tune them too much and I think they must not be treated as rules of any sort. Personally I'd like to see more great software produced by the KDE community and not necessarily "KDE-software" (though that's also ok if that's what you're interested in doing of course), so I like that openness in the vision and the mission. I realize though that I have a developer perspective and there is perhaps a need for being more specific for the sake of creating more of an identity, and to that end the strategy points perhaps explain the mission better. Cheers, Christian
Re: [kde-community] possible foss alternative to telegram/slack
Am Mittwoch, 20. Juli 2016, 18:37:24 CEST schrieb Thomas Pfeiffer: > On 20.07.2016 17:57, Christian wrote: Hi Thomas, > > tl;dr recommendation: if some people really can't deal with IRC and need > > alternatives: go with mattermost, but provide an official instance. > > Have you managed to get mobile push notifications working without > needing a subscription with Mattermost? > This is an issue we have not managed to solve during our evaluation, > but it is an absolute must for it to be viable for us. I'm afraid I have not looked into that yet as for us it is unimportant, I shall see if I find the time to give it a go later this week, though. I can only test with Android, mind, as I don't have any apple devices at hand. Kind regards, Christian ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] possible foss alternative to telegram/slack
Marco Martin <notmart@...> writes: > Hi all, Hi all, sorry, I'm a bit late to the party, but I just got pointed at this thread due to bringing it up on IRC, due to the recent blog post about the Telegram / IRC tunnel: > Right now many groups are using Telegram as their primary communication medium > due to some limitations in IRC (mainly due to the ease of pasting images > inline the channel and the lack of fancy mobile clients for IRC), there may be > other valid reasons i'm not aware of > today i randomly stumbled upon > http://www.mattermost.org/ > > it seems to tick all the boxes: > * open source > * we can self host an instance > * fancy mobile and desktop apps > * inline multimedia attachments into messages > * and most important for us old farts: bridge to IRC :p > > didn't try it, just stumbled upon it but may be something to be considered? I maintain a personal mattermost setup because we are currently evaluating it at work. Maybe I have to say first that due to my background (I am a former freenode staff member) I am heavily biased towards IRC. But: if you plan to have an alternative to IRC, mattermost would be my recommendation. Mostly due to, compared to telegram, you having actual control over the server as well and the server being FOSS, not a proprietary thing running through a third party company. It also is very much aimed at development due to features like code blocks with syntax highlighting. It also is a bit less of a mess because it provides Teams (similar to what IRC Networks are) and rooms (similar to what IRC channels are) and can be well structured. It can also integrate rather well with various ticketing and monitoring solutions, plus, similar to telegram, can tunnel to / from IRC. So if some people, for whatever reasons, want to use anything else than IRC: my recommendation is that KDE infra provides something. Else there will be an uncontrollable mess of various protocols used by various groups, so people end up with n clients just to stay in touch with various parts. I assume if there was an official tool provided people would be less likely to use whatever alternatives they know from personal use. Also at least it could be centralized still, some protocols do not work terribly well with IRC tunnels. tl;dr recommendation: if some people really can't deal with IRC and need alternatives: go with mattermost, but provide an official instance. Kind regards, Christian ___ 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
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)? Greetings Chris ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
