Re: Proposal unify back our release schedules
Am Freitag, 19. April 2024, 11:04:33 CEST schrieb Carl Schwan: > Currently this is just a proposal, not a vote proposal or anything like > that. I'll be happy to receive positive or negative feedback on this idea. Reading through the proposal and the discussion, I think we need to think a little bit outside of the box. I have the feeling that most devs still see Linux distributions as the primary way to distribute our software. I do not think that this is universal true anymore and if we move away from it, this would open up way new possibilities. Let's assume for apps we see Flathub/Snaps/Windows Store/whatever store as our primary distribution channel, this would give us quite some advantages: * less duplicated work for distributions * no problems with "this framework release is not packaged yet" * no overwhelmed work for distributions due to too many packages need to be updated * no need to push an update if nothing changed * no random "this pulls in KDE" due to incorrect packaging * always up to date software for our users * no bad experience due to missing (optional) dependencies * easy release for the maintainers without needing a release team (what about a Gitlab create release pipeline the maintainer can press) So this would totally open up a new way to release and distribute "Gear". And with Gear being easily available for everyone this would also give the possibility to move things into Plasma which belong into Plasma, but haven't been for "this is an app and also usable on other desktop". What comes in my mind is everything that are essential apps for a decent desktop experience: * dolphin * spectacle * an image viewer (gwenview/koko, etc.) * okular * ... Those could still be apps, but be released together with Plasma, thus also tightly integrate with Plasma while at the same time be distributed through other channels. Such a model should also help with the development experience. I read a few comments about it being a problem on depending on frameworks master - I agree that is a problem. But not so much if there is always an up to date development container available to pull and hack on. If apps are containerized, their build environment can also be containerized. So my suggestion: think about more than just the release cycle and the alignment of the releases if you are going to touch this (hot) topic. Cheers Martin
Re: The status of freenode (the IRC network used by KDE)
Am Mittwoch, 19. Mai 2021, 10:34:26 CEST schrieb Christian: > 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. Thanks for informing us. This sounds horrible and must have been a very stressful time for all of you staffers. > 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. Given that this is driven by shells.com I think the KDE community should step up and remove all references to shells.com. Their behavior in this case goes clearly against our values. Best regards Martin Flöser
Re: All About the Apps Goal
Am Freitag, 23. April 2021, 11:58:07 CEST schrieb Jonathan Riddell: > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_20593 > 5 > > I've little interest in putting lots of apps into app stores without this > change of culture where app developers take some responsibility for the end > result. It would likely end up with unmaintained apps. After reading through the merge request I have a feeling that you approach this in a not optimal way. Change management is difficult. Like Nate already wrote it is not clear how that merge request is aiming the goal and after being asked to explain you give a non explaining answer which certainly did not help. Sorry to say. I tried to think about what I would care about if I were maintainer of an app and also reflected a little bit on how I thought about packaging while maintaining KWin. My summary would be: I would not care for snaps. To me snap, flatpak, appimage is just the todays rpm, dep, ebuild, pkgbuild, etc. The vast amount of different standards makes it impossible to support them all which results in not caring for any. As an app maintainer I could imagine supporting appimage and/or flatpak. But not snap! With the unfree server component and the lack of proper alternatives it would go against my FLOSS nature given that there are truly free alternatives to distribute apps on linux. Similar my motivation to package for Windows or Mac as non-free platforms would be extremely low. Especially as it would mean investing lots of time to set it up and test it. Maintaining that would be lots of work, especially given that I mostly failed at keeping cmake dependencies correct. And don't remind me of how often Ben was angry with me for requiring new CI requirements without checking before (sorry!). Now it should be cmake, flatpak, appimage, snap, ms store, apple store, epic store, steam store, etc. etc. That's too much for most teams! Given that I think your approach of changing culture is too strong, which is why I mentioned change management in the beginning. My personal suggestion would be to pick a few applications and try to work with them to get the tooling up. E.g. Krita, Kate, KWrite and Okular. And try to automate. Don't have the application developers maintain all those variants. It's too much! Maybe it's possible to get craft to a point that it can build for all of those platforms? Maybe it's possible to generate the required files directly with cmake? Give the devs one place to add their dependencies. Give them easy tools they know. If they have to invest looking into how to package for snap they will ask "what do I get over apt?" Now going back to my armchair, Cheers Martin
Re: Help with KDE PIM and Google Privacy Policies needed
Am 2020-03-06 08:20, schrieb Nicolás Alvarez: Apple can give its million appstore apps access to Google calendar data, and Mozilla can let addons access email data, but we can't? What do they do differently? The only thing they do differently is that they have a permission system in place. Doesn't apply for Thunderbird of course which means we should look at their privacy policy. Though we should never ask Google "Why is Thunderbird allowed?" as we don't want that Thunderbird gets access revoked. Also, Linux desktop systems are usually not sandboxed. If we didn't have Akonadi, and KOrganizer/KMail/etc used their own databases to store data without intending to share them with other apps, other apps could *still* access the data via the filesystem. Mozilla Thunderbird is approved by Google, and KWin theoretically *could* access my email because it can read ~/.mozilla. Sure, in practice it doesn't; but in practice it also doesn't access Akonadi. Maybe we are just too open about what Akonadi can do in the privacy policy. Which I think is a good thing. On the other hand I'm sure that Mozilla doesn't state that any app could read the storage. Perhaps we need to sell Akonadi differently. Cheers Martin
Re: Help with KDE PIM and Google Privacy Policies needed
Am 2020-03-05 21:19, schrieb Daniel Vrátil: Hi all, I would appreciate any hints and pointers at where exactly the KDE PIM Privacy Policy might be in violation of the requirements from Google. I may have been looking into those documents for so long I can no longer see anything :/ Reading [0] I see "Your use of data obtained via the Restricted Scopes must comply with these requirements:" ... "Only transfer the data to others if necessary to provide or improve user-facing features that are prominent in the requesting application's user interface" And reading the screenshot I think that's the problem. We state in our privacy policy about 3rd party plugins and Akonadi. Especially Akonadi is a "transfer of data to others" and that allows all applications to access the data. If KWin accesses the data it would be in violation of the additional requirements of the requested scope. Cheers Martin [0] https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes
Re: Issues with the issue tracking system
Am 2019-11-04 02:11, schrieb Philippe Cloutier: Dear community, I am facing 2 issues with the ITS which I cannot solve myself currently. Over the last months, I requested the "severity" (importance) of several tickets to be adjusted: https://bugs.kde.org/show_bug.cgi?id=149902#c4 https://bugs.kde.org/show_bug.cgi?id=317656#c17 https://bugs.kde.org/show_bug.cgi?id=410284#c7 https://bugs.kde.org/show_bug.cgi?id=206170#c4 https://bugs.kde.org/show_bug.cgi?id=408981#c4 https://bugs.kde.org/show_bug.cgi?id=407059#c1 No adjustment was done yet. Please either: 1. Solve https://bugs.kde.org/show_bug.cgi?id=272388 2. Allow more developers to modify the field 3. Or perform the requested changes I just looked through some of the bug reports and I think there is a general misunderstanding about bugs. Let me first introduce myself: I used to be KWin maintainer and managed all incoming bug reports for KWin. KWin is one of the products in bugs.kde.org getting most new reports - about 600 reports just last year. While it would be awesome to fix all issues, that is just impossible. We are a community of mostly volunteer developers and don't have the time to fix all issues, especially not in a timely manner. Some bug reports while seeming a minor issue on first glance are a big issue and require years of planning and work. In my development it happened quite regularly that after years the code base had moved in a way to resolve 10+ year open bug reports. What I did not like at all when managing the bugs, was: * adding comments "still not fixed in 5.12.3" as that adds useless noise. If it's fixed we mark it as fixed, otherwise it's not fixed. That's the state of the bug. * users changing severity. The severity is a field important to developers. We decide how important an issue is. Of course the issue is important to the affected users, otherwise they would not have reported the issue. We are quite aware that an issue is important, is affecting users and is problematic to workflows. Changing the severity doesn't indicate this. Every user thinks his issue is critical. If users are allowed to change the severity it would end in every bug report being critical. It becomes a nagging feature which is working against the community. In KWin I used the severity field to decide what gets fixed. E.g. critical in KWin has the meaning "system freeze". A critical bug has highest importance. It's the issue which has to be resolved before any other work. It's the issue which once fixed results in an emergency release. I hope you understand that if a user reported a bug as critical I immediately changed back the severity to "normal" - which is what it is in most cases. Overall my suggestion is to not nag in bug reports. At least in my involvement nagging and demanding in bug reports always had the opposite effect. If I have n bugs to fix and time to fix m bugs and n is significantly larger than m, I chose the subset m which gives me in volunteer working most pleasure. As bad as it sounds: the best way to get bugs fixed is to get involved. Sorry. Best Regards Martin Flöser
Re: Invent/gitlab, issues and bugzilla
Hi all, I just read through the complete thread and thought I want to add a little bit, because I think we miss the big picture. Boud pretty much describes the problem large projects (krita, kwin, plasma) have with bugzilla. We don't use bugzilla to handle bug reports, but to somehow manage all the reports we get, to survive. I blogged about these issues years ago, I did statistics for KWin showing that > 90 % of the incoming bug reports are not bug reports, but rather duplicates, user support, etc. The situation hasn't changed much over the years. Reading Boud's comments it looks like the situation became much worse for krita lately and I do not want to swap with him. Obviously for any large project the idea of swapping to an inferior system (which gitlab seems to be, haven't used it yet) is a horrible idea. But that's not the problem. The problem is that users interact with developers directly. The user goes to bugzilla or gitlab issues and reports a support request. Instead of friendly user support he gets a grumpy third level support answer that this is not an issue. No help, frustrated user and frustrated dev who just wasted another minute on bugzilla to handle user support. No company would allow to have Boud handle user support. That's insane. He's product owner, chief technologies, call him whatever you want, but he is not first level user supporter. That's the problem we have to face. Whether we use bugzilla or gitlab issues for internal issues is irrelevant. What is important is that we get users to use an adequate user support forum and not bugzilla or gitlab issues. Once we get the shit reports out of our bug tracker, everything looks different. Right now from KWin perspective I would say "hell no!" to the idea of using gitlab issues. But a better tool for development which gitlab issue seems to be is something I would like to have. Because for development planing I never really liked bugzilla. Although it might be that it was just too useless due to all the invalid bug reports. My suggestion is to address the user support and then look into whether we want to keep bugzilla or switch to gitlab issues. Cheers Martin Am 2019-07-04 19:26, schrieb Boudewijn Rempt: On donderdag 4 juli 2019 19:19:17 CEST Nate Graham wrote: On 7/4/19 11:06 AM, Christoph Cullmann wrote: > Actually, do we really want that every user bug reporter opens an > account on invent.kde.org? > > I actually think the split of accounts between phabricator/gitlab vs. > bugzilla is no bad but a good feature. It would definitely solve that problem, but there are a few practical problems with this: - People would continue to need two accounts (BKO and identity/invent), Like I said in my other mail, it's not hugely important for the kind of reporter who is not already a developer, and who knows, maybe that can be fixed as well. It's not like Identity is universally beloved. and the systems wouldn't be integrated as well as thy could be, which negates some of the purported advantages of moving to GitLab in the first place But that's the _point_. There needs to be a kind of division between user issue reporting and developer/development activity. - GitLab Issues are lacking some of the features of Phabricator Tasks such as parent & sub-task tracking Yes, gitlab issues is an all-round aenemic feature, but I could live with it for a tasks replacement, but not for a issue reporter replacement. - Using GitLab Issues exclusively to replace Phab Tasks will confuse users who are accustomed to using Issues for bug reporting in other projects (though I suppose this could be remedied by renaming "Issues" to "Tasks" in the UI, and implementing a template that explicitly says "Don't use this to report bugs") And users get would sent to bugs.kde.org anyway; no normal user is going to something called "invent.kde.org" to report a bug, unless there's very specific guidancce to send them there.
Re: Discourse
Am 2018-11-26 22:04, schrieb Ingo Klöcker: On Montag, 26. November 2018 18:03:55 CET Martin Flöser wrote: Am 2018-11-26 09:23, schrieb Ilmari Lauhakangas: > The main problem in any case will be getting enough engagement. I > don't think I have ever received a reply from a KDE developer in the > current forums. And that's good! Do you want that developers spend time answering simple support questions any other user could answer or do you want developers to code? No company would put their expensive developers on the front line for support. No company would publish their precious IP (aka source code) as Free Software. Luckily, KDE is not a company but a community of people where everybody, even the most precious developers, can be at the front line for support if they want to be there. Of course that is not what I meant. Currently we have the problem that user support is completely handled by over qualified developers. Just check bugs.kde.org in the product KWin. It's me, David and Vlad doing the user support. That is such a waste of resources. If we wouldn't do it, nobody would do it. I don't want to tell developers to not do user support. If they want to do that, it's fine. But currently our infrastructure forces it on us. And that's a problem and won't scale in the long run. Cheers Martin
Re: help desk vs bug tracker
Am 2018-10-29 19:22, schrieb David Edmundson: I'm also wondering whether other KDE projects have the seem need as we have for Krita, With my Plasma hat on: Surprisingly, we don't get too many end user questions on bugzilla. I think it tends to get loaded onto the distros instead. We do get quite a few where the user thinks they have a bug but it's an issue on their end but I don't think a helpdesk would solve them. What I see in KWin quite often is: "foo doesn't work" or "KWin should do bar". And then you tell them how to enable the feature or that KWin already supports it. This is so common that I consider this as one of the huge pain point in bugzilla. For me that falls under "user support" and I think a helpdesk system could improve the situation (Obviously it requires users going there and if a user knows something like "KWin" exists and can report a bug against it it's a lost case - a user shouldn't know KWin exists). Cheers Martin
Re: Upcoming change to mail infrastructure
Am 2018-07-03 12:29, schrieb Ben Cooksley: Hi all, For those users of the authenticated mail service: please change your mail client to use the server "letterbox.kde.org" instead of the current server "postbox.kde.org". Additionally, if you are currently using port 588 to send mail, this should now be changed to the standard submission port, 587. When should we do the configuration change on our side? Right now or should we wait for a switch date? Cheers Martin
Re: Akademy Registration Open and Talk Schedule Announced
Am 2018-05-03 11:04, schrieb Kenny Duffus: Hi You can now Register for Akademy 2018, free as usual. https://events.kde.org/ The Talks Schedule is also now available with some highlights: https://dot.kde.org/2018/05/03/akademy-2018-program-now-available For more details about the event please see https://akademy.kde.org/2018 In particular we recommend booking accommodation as soon as possible I think there's a mistake in the schedule. I doubt that Bhushan is able to give two talks in two different rooms at the same time. He's awesome, but that's too much of awesome ;-) https://conf.kde.org/en/Akademy2018/public/events/30 and https://conf.kde.org/en/Akademy2018/public/events/28 Cheers Martin
Re: Let's get rid of UNCONFIRMED/CONFIRMED
Am 2018-02-27 20:22, schrieb Boudewijn Rempt: On Tuesday, 27 February 2018 20:19:24 CET Martin Flöser wrote: Am 2018-02-27 13:43, schrieb Boudewijn Rempt: > On Tuesday, 27 February 2018 13:30:12 CET Paul Brown wrote: >> Is it true that users get confused by the bugtracking system? If so, >> this is >> an issue, right? > > Well, users can get confused by _everything_. Though I probably have > more > absolutely non-technical users reporting bugs than most other KDE > projects. I > haven't seen many signs of users being confused by UNCONFIRMED vs > CONFIRMED, > though. In KWin we get quite often the "bug open for X months and still unconfirmed" Which I have to answer with "unconfirmed has no meaning in the development of KWin". If we can get rid of this conflict area I would be very happy. That's why I want to have a visible distiction between "reported, nobody looked at it yet" and "reported, someone looked at it, couldn't reproduce yet" that _does not mark the bug as resolved_. For KWin at least I would not need the destinction. Every bug is looked at in less than 24 hours. On the other hand no bug is reproduced till I try to fix it. And that can take time, sometimes years, sometimes never.
Re: Let's get rid of UNCONFIRMED/CONFIRMED
Am 2018-02-27 20:21, schrieb Boudewijn Rempt: On Tuesday, 27 February 2018 20:15:40 CET Martin Flöser wrote: As KWin has the same problem as Krita I can also answer. In the case of KWin about 90 % of the incoming bug reports is not a bug, but either duplicate, driver crash, useless crash reports from Arch users or user support questions. I as the maintainer handle this. Just imagine in a corporate world having the product owner or developer with largest domain knowledge handle the first level user support. No company would do that because it's a waste of time and money. We as a free software community still practice this. So where should users report bugs? Not anywhere where the developers look for bugs. Which is why I'm handling bugzilla, mostly, with Dmitry only looking at bugzilla when I ask him too, and for the rest, just phabricator. I'm trying to shield my most productive developer from the interaction with useless reports. Even so, he often comes to me with "some man on vk reported a bug...". We need an efficient support portal which can handle the 90 % of requests which create the noise. If the users truly report a bug, then it could be forwarded to the developers. With a corporate style workflow going from first level support (taking the issue), to second level support (figuring out whether it's a bug) and then to third level support (developers). The big problem is finding someone who can make the judgement calls. Bug reports are often worded so weirdly that you do need the ten years of experience to be able to guess what the reporter means, and in which category of frequently reported misconception the report falls. Yeah, that's what second level support is for. And it's totally fine for second level support asking the devs "hey I have hear an issue where I have a weird feeling, can you have a look?". Cheers Martin
Re: Let's get rid of UNCONFIRMED/CONFIRMED
Am 2018-02-27 14:45, schrieb Paul Brown: On Tuesday, 27 February 2018 13:43:17 CET Boudewijn Rempt wrote: On Tuesday, 27 February 2018 13:30:12 CET Paul Brown wrote: > Is it true that users get confused by the bugtracking system? If so, this > is an issue, right? Well, users can get confused by _everything_. If a service is confusing for the target it is designed for, then should it not be the job of the implementers to change it so it isn't? The target audience for bugzilla is developers, not users. It's a very technical system which requires well close to be being able to write SQL yourself (ever tried the custom search of the advanced search?) Cheers Martin
Re: Let's get rid of UNCONFIRMED/CONFIRMED
Am 2018-02-27 13:43, schrieb Boudewijn Rempt: On Tuesday, 27 February 2018 13:30:12 CET Paul Brown wrote: Is it true that users get confused by the bugtracking system? If so, this is an issue, right? Well, users can get confused by _everything_. Though I probably have more absolutely non-technical users reporting bugs than most other KDE projects. I haven't seen many signs of users being confused by UNCONFIRMED vs CONFIRMED, though. In KWin we get quite often the "bug open for X months and still unconfirmed" Which I have to answer with "unconfirmed has no meaning in the development of KWin". If we can get rid of this conflict area I would be very happy. Cheers Martin
Re: Let's get rid of UNCONFIRMED/CONFIRMED
Am 2018-02-27 12:22, schrieb Paul Brown: On Tuesday, 27 February 2018 11:51:42 CET Boudewijn Rempt wrote: On Tuesday, 27 February 2018 11:47:22 CET Paul Brown wrote: > On Tuesday, 27 February 2018 11:41:04 CET Boudewijn Rempt wrote: > > Given that bugzilla is a tool for developers, I don't care that users > > might > > get confused. > > > > > We don't have this problem with phabricator tasks because they can be > > > either Open or closed (for whatever reason). > > > > I don't let users report issues in phabricator anyway, because > > phabricator > > is where we plan our work. Bugzilla is the big pile of shit that comes > > from > > the outer world. So, phabricator's lack of fine-grained task statuses is > > irrelevant. > > So... where are users supposed to report bugs? Users report bugs in bugs.kde.org. But that doesn't change that bugs.kde.org is a tool for the developer, not the user. Once the bug is in bugzilla, it's my property, as a developer, and I need to have a workflow that allows me to efficiently handle over a thousand bug reports a year. Users do treat bugs.kde.org as a helpline, but that's invalid, and I close such help requests as invalid, though I also give the users the help they need, of course. I'll ask the question again with a slight modification: So... where are users supposed to report bugs according to you? As KWin has the same problem as Krita I can also answer. In the case of KWin about 90 % of the incoming bug reports is not a bug, but either duplicate, driver crash, useless crash reports from Arch users or user support questions. I as the maintainer handle this. Just imagine in a corporate world having the product owner or developer with largest domain knowledge handle the first level user support. No company would do that because it's a waste of time and money. We as a free software community still practice this. So where should users report bugs? Not anywhere where the developers look for bugs. We need an efficient support portal which can handle the 90 % of requests which create the noise. If the users truly report a bug, then it could be forwarded to the developers. With a corporate style workflow going from first level support (taking the issue), to second level support (figuring out whether it's a bug) and then to third level support (developers). Due to the high level of noise there is also a lot of conflict potential. I operate on the assumption that any incoming bug report is not valid. This is experience based. If > 90 % of the reports are not valid you start to get a feeling that the next bug won't be valid either. So bugs get closed, closed with short sentence. Feature requests dismissed, etc. Sometimes answered on a tablet or smartphone with too short answers. Things escalate, we need to bring in the CWG. That's all quite common to the very frustrating and demotivating bug wrangling process. I'm sure the situation would be better if the developers would not interact directly with the users, but if a first or second level support team acts as an intermediate for it. Cheers Martin
Re: Babe project - Legal feedback
Am 2018-02-03 18:07, schrieb Camilo Higuita Rodriguez: 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 Like Christian, I recommend to consult a lawyer specialized on Copyright law. What's extremely important is that there won't be an answer which is globally unique. I'll give you an example for my area of legislation (Germany). We have the concept of a private copy (Privatkopie) [1] which allows to share media with friends and family. There is a ruling of the highest German court (BGH) which can be interpreted as the number of friends and family is 7 [2]. Given that the answer to your questions from a German perspective is IMHO (though IANAL) that it is clearly illegal if a user would use this feature. Cheers Martin [1] § 53 URHG https://www.gesetze-im-internet.de/urhg/__53.html [2] BGH, GRUR 1978, 474
Re: [Update] Big Hairy Audacious Goal: Privacy Software
Am 2017-09-22 14:48, schrieb Sebastian Kügler: Hi all, What I need now: * Review: Please look over the proposal, make trivial fixes right there, propose more comprehensible or possibly goal-altering changes in the comments of that page or in this email thread * If you believe this goal is worthwhile for KDE and you support it, please add your name under it * If you intend to actively support this goal in whatever way, please also indicate this on the phab page Hi Sebas, back in 2013 I wrote two blog posts with thoughts about FLOSS in a world after Snowden: * https://blog.martin-graesslin.com/blog/2013/08/floss-after-prism-privacy-by-default/ * http://blog.martin-graesslin.com/blog/2013/08/floss-after-prism-anonymity-by-default/ It might have some good points which might align very well with this proposal. Cheers Martin
Re: Status of Wayland implementation on nVidia graphics cards
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/
Re: Big Hairy Audacious Goal: Privacy Software
Am 2017-08-18 18:14, schrieb Sebastian Kügler: So, I could use some help with this, in the form of how this can be structured, in what form it will be useful, more ambitious, and very importantly measurable: I want us to be able to sit down in two years and check: Are we on track? Do we need to change our approach? Do we need to work harder? And of course: Did we achieve our goal? Your thoughts and input? I like this idea. Personally I would suggest to combine it with a strive for security. IMHO we cannot be privacy aware if we have huge security issues which allow to get to the users passwords. This would include for example switching to Wayland by default (security and X are just two things which don't go well together). On the measuring part I agree that it's difficult. I would suggest to come up with a list of tasks which we need to implement and then check how many of these are implemented in a time frame. Cheers Martin
Re: Telemetry Policy
Am 2017-08-14 14:17, schrieb Volker Krause: On Sunday, 13 August 2017 12:56:27 CEST Martin Flöser wrote: Am 2017-08-13 11:47, schrieb Volker Krause: > Hi, > > during the KUserFeedback BoF at Akademy there was quite some interest > in > collecting telemetry data in KDE applications. But before actually > implementing that we agreed to define the rules under which we would > want to > do that. I've tried to put the input we collected during Akademy into > proper > wording below. What do you think? Did I miss anything? To me it looks good! I have some additional requests: * the collected data must be made available to the public (mostly thinking of research institutes here) This has come up before, not in the context of 3rd parties like research organisations, but for transparency towards our users. There is a practical limitation of making raw data available live, as that would create a publicly readable and writable system, with similar abuse potential as e.g. pastebin. But I don't think that is the requirement you have in mind here, it's more about sharing the raw data after review/eventually, right? Yes. I certainly don't want to give public edit functionality. In the currently envisioned setup anyone with a KDE contributor account would have access, so the remaining questions would be about the practicalities and processes to review and release the data to the general public I think. * data must be made available under a CC license (CC0?) Interesting point, I hadn't thought about that yet :) Can we even license the data, as we didn't create it? Do we need to ask our users to license their telemetry contributions? Yes we can license the data. We are building up a database, so the copyright as for databases applies. As you are German I reference the German Wikipedia article: https://de.wikipedia.org/wiki/Datenbankwerk * maybe allow the user to delete the dataset again (difficult as that conflicts with making the data public and would require authentication which is the opposite to anonymity). As discussed on kde-core-devel a while ago, I think this would be doable technically, without compromising anonymity. The server would generate a unique unpredictable token for each submitted sample and return that to the client. The client collects those and can use them as part of a deletion request. However, this does only work as long as we have full control over the data, we can't recall data that has already been extracted from our systems. So I think this conflicts with the first two requirements you mentioned. How do we want to resolve that? Yes I am aware that these are contradicting requirements. Of course it's not possible to delete after it's published, but maybe we have situations like a user submitted data and than things about it half an hour later and decided "no, I don't want to share". So if it's technically possible it would be nice to have. Cheers Martin Regards, Volker > # Telemetry Policy Draft > > Application telemetry data can be a valuable tool for tailoring our > products > to the needs of our users. The following rules define how KDE collects > and > uses such application telemetry data. As privacy is of utmost > importance to > us, the general rule of thumb is to err on the side of caution here. > Privacy > always trumps any need for telemetry data, no matter how legitimate. > > These rules apply to all products released by KDE. > > ## Transparency > > We provide detailed information about the data that is going to be > shared, in > a way that: > - is easy to understand > - is precise and complete > - is available locally without network connectivity > > Any changes or additions to the telemetry functionality of an > application will > be highlighted in the corresponding release announcement. > > ## Control > > We give the user full control over what data they want to share with > KDE. In > particular: > - application telemetry is always opt-in, that is off by default > - application telemetry settings can be changed at any time, and are > provided > as prominent in the application interface as other application settings > - applications honor system-wide telemetry settings where they exist > (global > "kill switch") > - we provide detailed documentation about how to control the > application > telemetry system > > In order to ensure control over the data after it has been shared with > KDE, > applications will only transmit this data to KDE servers, that is > servers > under the full control of the KDE sysadmin team. > > We will provide a designated contact point for users who have concerns > about > the data they have shared with KDE. While we are willing to delete data > a user > no longer wants to have shar
Re: Telemetry Policy
Am 2017-08-13 11:47, schrieb Volker Krause: Hi, during the KUserFeedback BoF at Akademy there was quite some interest in collecting telemetry data in KDE applications. But before actually implementing that we agreed to define the rules under which we would want to do that. I've tried to put the input we collected during Akademy into proper wording below. What do you think? Did I miss anything? To me it looks good! I have some additional requests: * the collected data must be made available to the public (mostly thinking of research institutes here) * data must be made available under a CC license (CC0?) * maybe allow the user to delete the dataset again (difficult as that conflicts with making the data public and would require authentication which is the opposite to anonymity). Cheers Martin Regards, Volker # Telemetry Policy Draft Application telemetry data can be a valuable tool for tailoring our products to the needs of our users. The following rules define how KDE collects and uses such application telemetry data. As privacy is of utmost importance to us, the general rule of thumb is to err on the side of caution here. Privacy always trumps any need for telemetry data, no matter how legitimate. These rules apply to all products released by KDE. ## Transparency We provide detailed information about the data that is going to be shared, in a way that: - is easy to understand - is precise and complete - is available locally without network connectivity Any changes or additions to the telemetry functionality of an application will be highlighted in the corresponding release announcement. ## Control We give the user full control over what data they want to share with KDE. In particular: - application telemetry is always opt-in, that is off by default - application telemetry settings can be changed at any time, and are provided as prominent in the application interface as other application settings - applications honor system-wide telemetry settings where they exist (global "kill switch") - we provide detailed documentation about how to control the application telemetry system In order to ensure control over the data after it has been shared with KDE, applications will only transmit this data to KDE servers, that is servers under the full control of the KDE sysadmin team. We will provide a designated contact point for users who have concerns about the data they have shared with KDE. While we are willing to delete data a user no longer wants to have shared, it should be understood that the below rules are designed to make identification of data of a specific user impossible, and thus a deletion request impractical. ## Anonymity We do not transmit data that could be used to identify a specific user. In particular: - we will not use any unique device, installation or user id - data is stripped of any unnecessary detail and downsampled appropriately before sharing to avoid fingerprinting - network addresses (which are exposed inevitably as part of the data transmission) are not stored together with the telemetry data, and must only be stored or used to the extend necessary for abuse counter-measures ## Minimalism We only track the bare minimum of data necessary to answer specific questions, we do not collect data preemptively or for exploratory research. In particular, this means: - collected data must have a clear purpose - data is downsampled to the maximum extend possible at the source - relevant correlations between individual bits of data should be computed at the source whenever possible - data collection is stopped once corresponding question has been answered ## Privacy We will never transmit anything containing user content, or even just hints at possible user content such as e.g. file names, URLs, etc. We will only ever track: - system information that are specific to the installation/environment, but independent of how the application/machine/installation is actually used - statistical usage data of an installation/application ## Compliance KDE only releases products capable of acquiring telemetry data if compliance with these rules has been established by a public review on [kde-core-devel| kde-community]@kde.org from at least two reviewers. The review has to be repeated for every release if changes have been made to how/what data is collected. Received data is regularly reviewed for violations of these rules, in particular for data that is prone to fingerprinting. Should such violations be found, the affected data will be deleted, and data recording will be suspended until compliance with these rules has been established again. In order to enable reviewing of the data, every KDE contributor with a developer account will have access to all telemetry data gathered by any KDE product.
Re: Applications Lifecycle Policy
Am 2017-07-12 00:20, schrieb Albert Astals Cid: El dimecres, 5 de juliol de 2017, a les 21:37:09 CEST, Martin Flöser va escriure: 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: 3. Remove the 2 week Review process If we don't have review, at which point do i say: * Your i18n handling is broken * Your library installed headers will be a pain to maintain ABI * etc Never? The review process for me is a way to make you realize that things you didn't think were important now suddenly are since you want to be a grownup. Please see my other replies to this thread which also discuss how I imagine this to work for the translation team. Of course you can break it again later but I would like to hope that once told how to do those things properly it may be easier to keep them doing right Right, like KWin where I am the fourth maintainer after review. That's my whole point: replace the review with automated checks always running. Cheers Martin
Re: Applications Lifecycle Policy
Am 2017-07-05 23:29, schrieb David Edmundson: 2. Remove playground Lots of projects get started and die. I think it's important to have some flag (however you want to call it) that says; CI admins, translators and even packagers should not bother looking at this project yet. Otherwise we waste a lot of people's time. The review process in it's current reality is mostly an extension of that, with the people checking those things off. There is little actual code review, it's mostly CMake and i18n. You bring up good points! One is: we don't detect when applications die. We need to improve there. My answer to the other points is similar to what I already answered to Luca: we need to establish clear rules. Our translation team needs to come up with requirements they need fulfilled so that translations get enabled, you don't just get it. On the other hand I would say that to release you need translation setups. And of course I want that CI covered! E.g. we could run scripty in CI stage and verify that messages get extracted. My point basically is the same as the base one: we do the review once. I'm not saying the steps of the review are not needed, they are super important. But we don't ensure it afterwards and that's why I think the current review process is broken. Cheers Martin
Re: Applications Lifecycle Policy
Am 2017-07-05 22:27, schrieb Luca Beltrame: Il giorno Wed, 05 Jul 2017 21:37:09 +0200 Martin Flöser <mgraess...@kde.org> ha scritto: To me the review process always felt weird and also like a relict from other times. I contributed to overall KDE something like 100 k While projects with strong stewardship like KWin, Plasma or Krita (*not* implying there aren't others: I'm mentioning the ones that come to mind) ensure a continued review and code quality, how would you ensure that, without review periods (or anything that can subsitute them, if anything better) distributions and integrators don't get code dumps of dubious quality? I see this as a concrete risk. I understand your point: you don't want that the quality assurance ends up on the shoulders of the distros. And I agree. My proposal addresses this by wanting our CI to do the work for us. And I would say we introduce rules on when an application is allowed to release. This could be requirements like: * translation setup is working * code compiles on CI * code installs correctly * ... In fact I think currently we do a bad job on ensuring that the code can be used by distributions. That's something we don't have in our review process but which is needed. And those are things we can check automatically, like does it have a COPYING file. To you this change would mean: if there is a tarball the requirements for release from our side are fulfilled, which you currently don't have. So also here I see a potential for we can become better by changing the workflow. Cheers Martin
Re: Applications Lifecycle Policy
Am 2017-07-05 22:18, schrieb Luigi Toscano: 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. But please, if we end up going this way, make sure that we have the measurement report/dashboards in place for all projects *before* changing the workflow. Of course we should only change when we have a new workflow in place. Cheers Martin
Re: Applications Lifecycle Policy
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. Extragear: to me extragear is a relict from the time of the big one KDE svn trunk repository. There was "KDE" and everything else, aka. extragear. When I started to compile KDE software it looked to me like something created from the needs of SVN. A technical thing. Now we have git and we have split up all those parts which used to be KDE, except for extragear. Where is the difference between Krita (to my knowledge not part of extragear), Amarok (to my knowledge part of extragear) and Dolphin (to my knowledge part of KDE Applications)? Honestly I don't see it. Let's just remove it and separate into applications released as part of a larger bundle for release simplification and applications having their own release cycle. With extragear gone I don't really see the need of playground any more. Playground applications are just like all the other things, except that they did not go through KDE Review. Which brings me to the next point: remove the review. To me the review process always felt weird and also like a relict from other times. I contributed to overall KDE something like 100 k lines of new code - none of them went through review. Would KWin pass review today? Just for the fun I opened up Krazy and see 444 open issues. Objectively speaking KWin is known as one of the products with highest quality in the KDE area and one of the window managers with highest quality and the Wayland compositor with largest test coverage. On the other hand it would fail our rules for review (granted Krazy reports so many false positives in the case of KWin, that I didn't check for years). KWayland entered frameworks without review. How come? Well it moved from Plasma to frameworks, so no review needed. How did it enter Plasma? Well it was split out of KWin. Back then it was a few files providing a very minimal library for Wayland clients. If we had started in Playground we would have had to go through review - today it's a code base of 50 k (according to cloc). Similar if we would have started a new Wayland compositor from scratch it would have had to go through review, but by extending KWin that was never needed. I see that the review process is there to ensure a "baselevel quality". But what is afterwards? When did KWin go through review? When Matthias forked it from KWM, or was it covered by KWM? That makes something like 15 years of nobody looking at this baselevel quality. Would we have needed it sometimes? Hell yes! Think of the compositor introduction, the xcb port, the Wayland port. To large parts like new products, but we passed review once (if at all) so it was no longer needed. Similar we see now for Kube. If it would have started as a "KMail 3" no review would be needed, but as Kube it needs to go through review. That's arbitrary. If I would start a new project I would think that this process is a joke. The quality just doesn't get measured any more after review. 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. Cheers Martin
Re: latest draft for mission (and strategy)
Am 2017-06-15 19:28, schrieb Marco Martin: On Monday 29 May 2017 21:17:29 Lydia Pintscher wrote: I'd like to invite you all to take a look at the current draft and provide your constructive feedback so we can use this as the basis for our work for the next years. https://community.kde.org/KDE/Mission Good job, i like this text! one thing i would add tough, is at "interoperates well with proprietary software, formats and services" I would really like adding something about being committed to interoperation with free software services, so while we try to interoperate with proprietary ones, if a free one is available (like owncloud vs dropbox) making sure the priority is making the interoperation with the open service a truly first class citizen +1 on that. I understand the reasoning for why it's put into the mission like that but it also reads a little bit like we care more about dropbox than own/nextcloud. Which certainly is not that case and nothing we want to strive for. Cheers Martin
Re: latest draft for mission (and strategy)
Am 2017-06-13 15:29, schrieb Sebastian Kügler: On dinsdag 13 juni 2017 14:16:25 CEST Kenny Coyle wrote: Thanks for putting this together, I can only see it being positive going forward. The text itself is very clear and concise. On the last section about promoting development, I'm wondering if it's worthwhile having a statement about the infrastructure that KDE maintains and develops? How about the following: To promote the development of Free and Open-Source Software, KDE … maintains reliable technical infrastructure to support the community, evolving with the community I think that fits well into the strategy part. I wonder if we should explicitely mention that we want this infrastructure to be based on Free software and open standards as much as possible, since that's come up over and over again in the past when we discussed important infrastructural changes. (Own git vs. github, phabricator vs. other tools, etc.) What do others think about this? +1 on that. I just wanted to write a mail that I would like to have a point for that like: KDE is a living example for usage of free software and uses wherever possible free products over proprietary in its own infrastructure Cheers Martin
