Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)
On Fri, 16 Nov 2018 at 10:37, Luigi Toscano wrote: > Andrew Crouthamel ha scritto: > > I've been spending a lot of time browsing, searching, and filtering our > bugs > > in Bugzilla. One of the areas I've found that could use improvement, are > the > > NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting > > additional information or backtraces, never to be updated again. We have > > NEEDSINFO bugs dating back to 2009. > > Hi, > the (semi)automated process which pings and then closes NEEDINFO bugs was > implemented, but I've noticed another policy which was never discussed (as > far > as I know) here: bugs opened for a while > Hi As a heavy user of NEEDINFO I am also not enthusiastic and asked by email for exclusion but no reaction so far. Bug reports that I work with can easily be 6 years old and this means nothing in the development speed that I face. In a commercial environment maybe it's different - so old reports are really invalid, but here now I only get more work - I need to resort to notification emails one by one, it will take months. Also e.g. if a bug has 10% of missing "NEEDSINFO" and dozen of comments with valid discussion and input, how can it be abandoned automatically based on time since the original report? I am not sure if we can assume it is of any help that valid bugs are set as resolved by non-project persons (who have never had a contact with a maintainer), without proper project knowledge. At least the bugs are not CLOSED so it's possible to query them. But how useful is to spend time on it? Please at least do not close them. We have to deal with the consequences with our users. Possibly facing decline of bug reports because they see they are resolved without proper action. I also think something else was not considered, what applies at least to projects I maintain: people do use old software and do not upgrade especially on Linux e.g. due to the misunderstood thing called LTS. Hence they face with problems that are discussed in these old bug reports. The fact that old software is unmaintained does not mean that the report, convert into new reports or tasks for newer software versions, for the docs, and so on. If we automatically set bugs as resolved I seen that as a disservice for the project. > I disagree with this policy, and I'm not alone (at least another > maintainer > asked for his product to be excluded): > - not all projects distinguished between CONFIRMED and UNCONFIRMED (now > REPORTED), so it's possible that a perfectly valid bug or request > (especially > requests) seems stale. You may say that it's easy to flip the status > again. > I'd say that it's a unneeded step. > - at most the script could add a new comment asking for updates, but not > immediately change the status out of the blue. > - as mentioned, it was not discussed. > > Please disable it for now, or just enable it for projects who explicitly > wants > it for now. > > -- > Luigi > > > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - kde.org KEXI: : A visual database apps builder - kexi-project.org calligra.org/kexi twitter.com/kexi_project facebook.com/kexi.project t.me/kexi_project Qt Certified Specialist: : linkedin.com/in/jstaniek <http://www.linkedin.com/in/jstaniek>
Re: Bugzilla template problems
On Thu, 4 Oct 2018 at 21:06, Boudewijn Rempt wrote: > On donderdag 4 oktober 2018 21:01:37 CEST Jaroslaw Staniek wrote: > > So I would imagine that quite general approach would be to allow "None" > > value for Plasma version and even KF5 version (this covers non-KF5 apps). > > "None" in contrast to "Unknown". > > That's not relevant. It isn't a matter of what's allowed or not; this is a > plain text thing people are supposed to understand and maybe fill in. > There > are no canned answers, no comboboxes, no help for the user. > > > PS: What's the link to the template please? > > Just go to bugzilla, try to enter a new bug and look at what's pre-filled > in > the report field. > Ah textual template! Thanks Boud. I propose approach like below; one size fits all since the product can be even non-Qt one (or built as non-Qt or non-KF5 or be entirely non-C++). Saying "SYSTEM SOFTWARE VERSIONS" helps to avoid cases when user repeats the app's version. -- BEFORE: SOFTWARE VERSIONS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: --8x--- -- AFTER: SYSTEM SOFTWARE VERSIONS 1. Operating system version: 2. Click "Help menu->About app->Libraries" and provide: * KDE Frameworks Version (KF5): * Qt Version: Skip if unused. Alternatively type "kf5-config --version" or "qmake-qt5 --version" from the command line. * KDE Plasma Version: Skip if unused. Alternatively type "plasmashell --version" from the command line. --8x--- Also: Why Android has versions in the OS field? Moreover I see room for improvement for KF5-based apps in the command line. The --version option does not show Qt nor KF5 version. In contrast Creator shows Qt version. IIRC "KDE4" apps used to show Qt and KDE platform 4 versions (just checked with KDevelop). Maybe this is reported already, nevertheless can be a good junior/season job. When this gets fixed the "kf5-config --version" / "qmake-qt5 --version" / "plasmashell --version" usually won't be needed, just "appname --version", at least for KF5 apps. Related: In project where I contribute I am quite picky about showing as much as possible of version info, also found plugins and their versions. This so often helps to figure out potential issues. Also this way users do not need to discover OS-dependent way of discovering plugins/dependency versions (can be funny on Windows). -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Bugzilla template problems
So I would imagine that quite general approach would be to allow "None" value for Plasma version and even KF5 version (this covers non-KF5 apps). "None" in contrast to "Unknown". PS: What's the link to the template please? On Thu, 4 Oct 2018 at 19:27, Ben Cooksley wrote: > On Fri, Oct 5, 2018 at 5:14 AM Nate Graham wrote: > > > > Can the template be overridden on a per-project basis? > > It cannot be overridden on a per-project basis from my understanding. > > Regards, > Ben > > > > > Nate > > > > > > On 10/04/2018 07:48 AM, Boudewijn Rempt wrote: > > > Hi, > > > > > > This section: > > > > > > SOFTWARE VERSIONS > > > (available in About System) > > > KDE Plasma Version: > > > KDE Frameworks Version: > > > Qt Version: > > > > > > In the template I've never seen filled out. One problem, of course, is > that > > > it's really plasma centric. Most of my users don't use plasma, and > don't have > > > an "About System" app that shows this information. Is there are a way > to > > > reformulate this so we won't confuse our users? > > > > > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Call for contributors for Fixture [ Qt5 based raster graphics editor ]
On Fri, 21 Sep 2018 at 16:40, Jaroslaw Staniek wrote: > > On Fri, 21 Sep 2018 at 16:23, Scott Petrovic > wrote: > >> One thing that helps Krita is it has focus on who they are helping >> (people that can draw and paint). Photoshop caters to a lot of different >> industries - which is why it has 1,000 features built into it (which is >> both good and bad). When you get feedback from people, they oftentimes >> don't tell you important information about who they are. Are they graphic >> designers, web designers, photographers, 3d texture artists, animators, or >> maybe beginners just trying to get into basic image editing like cropping. >> You need to find out who you are trying to help. Graphic designers don't >> normally do painting and illustrations, and web designers don't usually do >> animation. This is why pretty much everyone only uses 2-3% of all the >> features in Photoshop. The rest of the features are just useless to them >> and are UI clutter. >> >> Trying to do a 1:1 copy of Photoshop isn't a good direction. That program >> has had 30 years to add a giant amount of features that have turned it into >> the powerful/bloated software that it has become. As a UI/UX person, I >> would focus on finding the people you want to help, learn about them, and >> give them a product that they are excited about. >> > > Practical thing is, I'd like to gently hear from the Krita community if > they accept properly done "Photoshop" mode for Krita, perhaps at the build > time and if possible go there. Krita has dozens of structures and GUI items > you need but you do not want to re-implement them in coming years... This > can be done right but has costs too for Krita so cost-benefit math needs to > be done first. > Similar: Phase 5 and 6 from https://github.com/eyeon/Fixture/blob/master/ROADMAP.md looks like a business of Calligra from years 201x and it took many years to reach beta. Whatever we implement, per rule of thumb it's 20%, then you have 80% of work in tests. Like Boud said, many features such as the lasso tool, you plan in earlier phases would have to be reimplemented if you do not use variable color spaces from day one, and then reimplemented again if you do not use tiles instead of linear memory model from day one. And this is top of the iceberg... Simple editing and viewing tools you list are a property of advanced image viewers these days, very often even online and mobile ones. So there's a lot to do to match good image viewer, not raster editor. > >> >> >> On Fri, Sep 21, 2018 at 7:10 AM Kuntal Majumder wrote: >> >>> Hey, >>> >>> On Fri, 21 Sep 2018 16:28:41 +0530 Boudewijn Rempt < >>> b...@valdyas.org> wrote >>> > Using QGraphicsItems for layers is not an approach that's going to >>> work out. >>> > It will not perform, it will not allow you to go beyond 8 bits sRGB >>> and it >>> > will take too much memory. >>> > >>> > If you insist on starting from scratch, and I understand the >>> temptation, you >>> > should: >>> > >>> > * consider color management: you cannot do anything useful unless >>> you >>> > understand color management. Check out littlecms and >>> https://poynton.ca/ >>> > ColorFAQ.html. >>> > >>> > * develop a structure for storing (including swapping), modifying >>> and >>> > retrieving raster data. QGraphicsView actually is a tile engine, but >>> you're >>> > not using it that way. Its level of maintenance in Qt is also low. >>> > >>> > * develop a system for undo/redo -- Krita uses Qt's system for that, >>> but if >>> > you want to clone photoshop, you should consider using their system. >>> There's a >>> > presentation from an Adobe engineer at a C++ conference in Moscow >>> that should >>> > help you form an idea. But basically, every modification results in a >>> shallow >>> > clone of the document. You will need this to clone photoshop's >>> history brush. >>> > Google for it, I cannot find the presentation right now. >>> > >>> > Then you can start on implementing a real canvas and a tool system. >>> >>> Thanks for the pointers, at least I won't be clueless like before. >>> >>> > I only remember you from https://phabricator.kde.org/T8198#132594 -- >>> did you >>> > post a patch for review and did I miss th
Re: Call for contributors for Fixture [ Qt5 based raster graphics editor ]
On Fri, 21 Sep 2018 at 16:23, Scott Petrovic wrote: > One thing that helps Krita is it has focus on who they are helping (people > that can draw and paint). Photoshop caters to a lot of different industries > - which is why it has 1,000 features built into it (which is both good and > bad). When you get feedback from people, they oftentimes don't tell you > important information about who they are. Are they graphic designers, web > designers, photographers, 3d texture artists, animators, or maybe beginners > just trying to get into basic image editing like cropping. You need to find > out who you are trying to help. Graphic designers don't normally do > painting and illustrations, and web designers don't usually do animation. > This is why pretty much everyone only uses 2-3% of all the features in > Photoshop. The rest of the features are just useless to them and are UI > clutter. > > Trying to do a 1:1 copy of Photoshop isn't a good direction. That program > has had 30 years to add a giant amount of features that have turned it into > the powerful/bloated software that it has become. As a UI/UX person, I > would focus on finding the people you want to help, learn about them, and > give them a product that they are excited about. > This. And Kuntal, from controversial angle, how would Fixture help re-sellers? They would ignore with you from the day one I bet, then they will fight. I see this all the time with, say, Blender. The time you Fixture team releases 1.0 all specialized apps will be available via service only (compare Fusion 360). As long as this is not a playground, starting new project is not much different in FOSS than in closed source. You do not want to target the strongest players and most crowded markets. Target audience, raster professionals do not seek for a change for price reasons since Photoshop is really cheap for them, nor they seek anything else to get freedom. Just like good dentists do not seek for replacement materials you can easily make with talc and cyanoacrylic and be happy ;) I do not say there are no exceptions, I am thinking about top digital graphics individuals. You need community of these users this yearm, not in 10 years or else your project will evolve to /dev/null. And last: where are you going to be and what to do in 10 years because it's how long it takes for specialized software to evolve to usable stage. Practical thing is, I'd like to gently hear from the Krita community if they accept properly done "Photoshop" mode for Krita, perhaps at the build time and if possible go there. Krita has dozens of structures and GUI items you need but you do not want to re-implement them in coming years... This can be done right but has costs too for Krita so cost-benefit math needs to be done first. > > > On Fri, Sep 21, 2018 at 7:10 AM Kuntal Majumder wrote: > >> Hey, >> >> On Fri, 21 Sep 2018 16:28:41 +0530 Boudewijn Rempt < >> b...@valdyas.org> wrote >> > Using QGraphicsItems for layers is not an approach that's going to >> work out. >> > It will not perform, it will not allow you to go beyond 8 bits sRGB >> and it >> > will take too much memory. >> > >> > If you insist on starting from scratch, and I understand the >> temptation, you >> > should: >> > >> > * consider color management: you cannot do anything useful unless you >> > understand color management. Check out littlecms and >> https://poynton.ca/ >> > ColorFAQ.html. >> > >> > * develop a structure for storing (including swapping), modifying and >> > retrieving raster data. QGraphicsView actually is a tile engine, but >> you're >> > not using it that way. Its level of maintenance in Qt is also low. >> > >> > * develop a system for undo/redo -- Krita uses Qt's system for that, >> but if >> > you want to clone photoshop, you should consider using their system. >> There's a >> > presentation from an Adobe engineer at a C++ conference in Moscow that >> should >> > help you form an idea. But basically, every modification results in a >> shallow >> > clone of the document. You will need this to clone photoshop's history >> brush. >> > Google for it, I cannot find the presentation right now. >> > >> > Then you can start on implementing a real canvas and a tool system. >> >> Thanks for the pointers, at least I won't be clueless like before. >> >> > I only remember you from https://phabricator.kde.org/T8198#132594 -- >> did you >> > post a patch for review and did I miss that? >> >> This is the one you reviewed https://phabricator.kde.org/D10202 >> >> Thanks >> Kuntal M >> >> >> -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Call for contributors for Fixture [ Qt5 based raster graphics editor ]
Thanks for contacting the KDE community, Kuntal! Everyone can to the NIH route but since you reach the KDE community, this would be my first technical advice: look at ways of using KF5 instead of implementing its functionality like any non-trivial Qt app would have to do anyway. And since Linux is a cancer... consider joining KDE - use the KDE infrastructure instead of MS infra :) On Thu, 20 Sep 2018 at 20:58, Kuntal Majumder wrote: > Hi > I am Kuntal, as a Linux evangelist, when I try to convince someone to use > Linux, most of the time I face questions like "Does Linux support > Photoshop?", at the end of the day the discussion mostly concludes with > "You can use Gimp or Krita". Both though pretty powerful have a very > different workflow compared to Photoshop for which most people are > reluctant to switch to Linux even though they require a pretty small set of > features from what Photoshop offers. So a couple us are trying to build a > raster graphics editor which looks and behaves similar to Photoshop with > the help of Qt5. But thanks to our inexperience, every now and then we are > facing roadblocks for which we rewrote the stuff a couple of times. We > would love some help from you guys, better if you can correct us where we > are going wrong. > You can find the source code here[1]. > > Thanks > Kuntal M > > [1] https://github.com/eyeon/Fixture > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Improving our integration with KDE application teams, and supporting companies
On Sun, 26 Aug 2018 at 21:36, Alexander Neundorf wrote: > Hi, > > ... > > We were close to being global > > I don't really understand what you mean with "global". Can you please > explain > ? > Being a go-to solution for office productivity work. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Improving our integration with KDE application teams, and supporting companies
Thanks for starting this topic Valorie. Hoping I do not repeat similar observations, wanted to share one thing. Background As soon as KDE application(s) are not publicly tied to "KDE" desktop on several levels, fair rules of competition become possible. I have learned this through the history of KEXI since 2002: in years where we had strong Windows support were extraordinary regarding user feedback. The same about caring for non-Plasma desktops compatibility. "Plasma users" tend to be a minority target at least for specialized apps by definition, well that group is a minority on the Desktop itself, so how it can be otherwise? And numbers further decreased after the decline of some desktops towards touch based UIs. Boud can correct me here but Krita loks like a very good example too. As soon as an app project is known as a normal standalone app, things start to be normal. For some reasons not caused by us, KDE folks, this is not *default* state for apps. "For KDE only" has been long the default. For Qt-only app projects it is a bit easier. It's good when we attract these projects under the KDE umbrella. To compare with above examples, Calligra as a whole has not managed so far to escape the "Office suite for KDE" or older "Integrated KDE office suite" unfortunate stamps.[1][2] Well, I bet such sentences still sit in package descriptions across some distributions. Here, again even in KDE circles the #1 FOSS competing office suite is perceived as global instead of Calligra. I've not seen too much of spontaneous use of Calligra during Akademy presentations. We were close to being global in the gold Nokia and KO GmbH times (2009+) even if there was some more interest in mobile targets. And now: One challenge for the integration I would see it that "part of the KDE community" needs to be in conflict with the "go global". Application contributors need not to worry that their attempt to "go global" is not the preferred choice within the KDE family. [1] I do not see this much different from Microsofts' behavior of promoting apps "running best on its operating system". [2] Just unfortunate messaging since at technology level we have no such problems. We stay on top of extremely portable Qt, CMake and KF5 technologies, paired with great multi-OS KDE CI infra. As it's worth mentioning the KF5 prject realizes its road to "global" just very well IMO. On Sat, 11 Aug 2018 at 12:35, Valorie Zimmerman wrote: > Hello folks, I've recently spent a week with Boud and Irina Rempt at > their invitation. I hope that this sort of generous hospitality > becomes the norm in our our KDE family. While there, we had many > conversations about the past, present and future of KDE. I was > surprised to learn that during the life of KO, Boud's previous company > with Inga Wallin and now with his small company which supports Krita, > he encountered quite a bit of opposition *in the KDE community*! > > I've long been puzzled why KDE applications seem to be relegated to > the "second circle" of KDE, and companies supporting KDE software even > further out. > > Not just puzzled, but somewhat discouraged, to be honest. When I > consider the future of a healthy KDE, I see many small companies > popping up, offering commercial support and specialized applications > to users. Far too often I see our great young programmers work within > KDE for a few years, but when they find a job "outside" then pair up > and perhaps have children, they are only involved tangentially. In a > healthy ecosystem, there would numerous KDE affiliated companies > competing to hire them, and they would stay involved as long as they > wanted, while supporting themselves. > > Am I the only one who thinks of our future in this way? I think it's > great that we are improving ties with "outside" companies and groups, > and fully support that. But *inside* KDE we should be starting > companies and foundations who can collect donations to support KDE > programmers. I would like to know the thoughts of others and how we > can best encourage this. > > Please let's talk about this during Akademy. > > Valorie > > -- > http://about.me/valoriez > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 30 April 2018 at 22:54, Lydia Pintscher wrote: > On Mon, Apr 30, 2018 at 10:41 PM Jaroslaw Staniek wrote: > > Hello > > Now we can assume that solution to non-unique identification Volker > explained in acceptable equivalent of random identifiers so KEXI does not > need exception. > > Thanks for patience! > > > I understand KEXI has time until the next release to switch to > KUserFeedback. In other words, next non-patch release (3.2) would be > compliant and would store data within KDE infra. For 3.1.x we can stop > saving unique random identifiers. > > Perfect. Thank you! > Update: as a first step, I disabled collecting *any* data on kexi-project.org so it's not related to the GDPR matters at all. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 30 April 2018 at 22:08, Lydia Pintscher wrote: > Hey folks, > > Jaroslaw: > * Given that > > GDPR is coming into effect on May 25th I'd like to urge you to > look into if what you're currently tracking is acceptable under that > regulation. I don't know how where the data you're collecting currently > ends up but I don't want the e.V. to be liable for personally identifiable > information ending up on non-e.V. servers etc. > * Please make a choice if you're willing to change Kexi to comply with the > policy or if you prefer it to be marked as a historic exception. (My > preference is not to have any exceptions to the policy and make a clear > statement to our users.) > Hello Now we can assume that solution to non-unique identification Volker explained in acceptable equivalent of random identifiers so KEXI does not need exception. Thanks for patience! I understand KEXI has time until the next release to switch to KUserFeedback. In other words, next non-patch release (3.2) would be compliant and would store data within KDE infra. For 3.1.x we can stop saving unique random identifiers. > Everyone: Unless there are big objections within the next week let's > consider the current draft at > https://community.kde.org/Policies/Telemetry_Policy accepted. > > > Cheers > Lydia > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 4 April 2018 at 12:37, Ben Cooksley wrote: > On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek wrote: > > > > > > On 3 April 2018 at 10:17, Ben Cooksley wrote: > >> > >> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek > wrote: > >> > > >> > > >> > On 2 April 2018 at 22:56, Lydia Pintscher wrote: > >> >> > >> >> Hey Jaroslaw :) > >> >> > >> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek > >> >> wrote: > >> >> > Thanks for reminding me Lydia > >> >> > > >> >> > I've not forgotten this. While there's progress I do still see this > >> >> > as a > >> >> > pilot stage and do not think we're in a hurry given telemetry is > >> >> > something > >> >> > "extra" for a project development, not a core feature of any > product. > >> >> > >> >> We are in a hurry now. We're waiting for projects to be able to start > >> >> using it and get us valuable insights about how our software is used. > >> >> We've been on it since last Akademy. Let's get it finished :) > >> >> > >> >> > Below I am referring to this version: > >> >> > > >> >> > > >> >> > https://community.kde.org/index.php?title=Policies/ > Telemetry_Policy&oldid=78057 > >> >> > > >> >> > tl;dr: Why discussing: Any deep change and limitation to projects' > >> >> > freedom > >> >> > needs to bring substantial benefits over drawbacks. Level of > >> >> > complexity > >> >> > of > >> >> > the contract for a project or individual developer needs to be > >> >> > balanced > >> >> > by > >> >> > real (not hypothetical) benefits. > >> >> > >> >> The benefits here for KDE are: > >> >> * we have a > >> >> better understanding of our userbase leading hopefully to > >> >> better software > >> >> * we have a better understanding of our userbase leading hopefully to > >> >> better marketing > >> >> * we have a clear policy we can point our users to that explains how > >> >> we are handling their data and that is in line with our vision/what > we > >> >> stand for. > >> >> > >> >> > I've studied the wiki page more in depth and I have these points > >> >> > where > >> >> > I'd > >> >> > like to see improvement. This is based on my experience, not a list > >> >> > of > >> >> > quick > >> >> > ideas. > >> >> > > >> >> > > >> >> https://community.kde.org/Talk:Policies/Telemetry_Policy# > >> >> > >> >> Thank you! Volker is probably best equipped to answer these. > >> >> > >> >> > That said: I will nod to the concept of "Minimalism", it is all > >> >> > classic > >> >> > property of telemetry. I think I've seen them in other projects > too. > >> >> > I'd just say, let's not make all this more limited than anyone > wants > >> >> > it > >> >> > to > >> >> > be. > >> >> > >> >> Where is it too limited? Please keep in mind that we've set > >> >> privacy as > >> >> a core part of our vision and the current goals. > >> > > >> > > >> > Lydia, > >> > >> Hi Jaroslaw, > >> > >> > It's a core part but still a part and can't contradict, say, with the > >> > Freedom part. > >> > > >> > Please see the list of limitations: > >> > https://community.kde.org/Talk:Policies/Telemetry_Policy# > >> > (in my opinion that's not a "nice to haves" but requirements needed so > >> > we > >> > can even call the whole thing "telemetry") > >> > > >> > I am asking for an alternative approaches, Volker once mentioned there > >> > are > >> > some. > >> > We need them to we move forward. > >> > > >> > In the meantime my stack runs just well, people that use IDs are
Re: Telemetry Policy - Remaining Questions
On 3 April 2018 at 10:42, Volker Krause wrote: > Thanks Lydia for getting this moving again! > > On Monday, 2 April 2018 22:56:31 CEST Lydia Pintscher wrote: > > Hey Jaroslaw :) > > > > On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek > wrote: > > > Thanks for reminding me Lydia > > > > > > I've not forgotten this. While there's progress I do still see this as > a > > > pilot stage and do not think we're in a hurry given telemetry is > something > > > "extra" for a project development, not a core feature of any product. > > > > We are in a hurry now. We're waiting for projects to be able to start > > using it and get us valuable insights about how our software is used. > > We've been on it since last Akademy. Let's get it finished :) > > > > > Below I am referring to this version: > > > https://community.kde.org/index.php?title=Policies/Telemetry > _Policy&oldid= > > > 78057 > > > > > > tl;dr: Why discussing: Any deep change and limitation to projects' > freedom > > > needs to bring substantial benefits over drawbacks. Level of > complexity of > > > the contract for a project or individual developer needs to be > balanced by > > > real (not hypothetical) benefits. > > > > The benefits here for KDE are: > > * we have a better understanding of our userbase leading hopefully to > > better software > > * we have a better understanding of our userbase leading hopefully to > > better marketing > > * we have a clear policy we can point our users to that explains how > > we are handling their data and that is in line with our vision/what we > > stand for. > > > > > I've studied the wiki page more in depth and I have these points where > I'd > > > like to see improvement. This is based on my experience, not a list of > > > quick ideas. > > > > > > https://community.kde.org/Talk:Policies/Telemetry_Policy# > > > > Thank you! Volker is probably best equipped to answer these. > > I've commented on all points on the talk page now I think. > Thanks Volker, I must have missed the info that the concepts of intervals have been documented two weeks ago. Apologies. The concept has potential to change the game and convince people to "invest" in telemetry. However maybe a pilot phase with an app or two would be more in place to see the results. Policies would then follow reality even more. It would be good to consider picking larger projects, e.g. part of KDE Applications release or Plasma itself, and with maintainers able to discuss during the Akademy. KEXI is just not in this group. Also, based on my knowledge, statistical KEXI users would not even have access to the KDE "kill switch" since Plasma is rarely used by them. In particular there is a chance that if pilot apps get released with the KUserFeedback telemetry, the challenge of handling access to the raw anonymized data would get addressed, since we would know why there is the interest in data and what is the purpose of collecting it. In the post-Akademy thread Ingo Klöcker has once provided interesting general observation, even it it refers to German law. Once the data "leaks" outside of the telemetry team (say telemetry team within a single app project), to people not even affiliated with the project, it is no longer possible to expect it (the data) is used in a way compliant with the Policy, and only for the needs of "legal" telemetry. KDE would still be responsible for all the uses of the data. Coming year stronger law comes to Poland too. So making it harder to download the data and increasing level of its aggregation would make sense then to me. Long-term idea would also be giving access to an analysis tool and the results instead of to the data on which the tool operates. And then in the meantime folks like the Promo team have potential to work on proper messaging to improve the number users understanding and accepting telemetry. My example follows here. On more "human" level: KEXI offering a telemetry "for KDE" that is still seen as a "desktop" (regardless of a reason) than "for KEXI Team" would be potentially a disadvantage for the app's project itself. KDE contributors and fans understand the idea of an organization. I've learned from my group that for everyone else "Help improve Visual Studio" type of message tends convince more than more questionable "Help Microsoft" ;) -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 3 April 2018 at 10:17, Ben Cooksley wrote: > On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek wrote: > > > > > > On 2 April 2018 at 22:56, Lydia Pintscher wrote: > >> > >> Hey Jaroslaw :) > >> > >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek > wrote: > >> > Thanks for reminding me Lydia > >> > > >> > I've not forgotten this. While there's progress I do still see this > as a > >> > pilot stage and do not think we're in a hurry given telemetry is > >> > something > >> > "extra" for a project development, not a core feature of any product. > >> > >> We are in a hurry now. We're waiting for projects to be able to start > >> using it and get us valuable insights about how our software is used. > >> We've been on it since last Akademy. Let's get it finished :) > >> > >> > Below I am referring to this version: > >> > > >> > https://community.kde.org/index.php?title=Policies/ > Telemetry_Policy&oldid=78057 > >> > > >> > tl;dr: Why discussing: Any deep change and limitation to projects' > >> > freedom > >> > needs to bring substantial benefits over drawbacks. Level of > complexity > >> > of > >> > the contract for a project or individual developer needs to be > balanced > >> > by > >> > real (not hypothetical) benefits. > >> > >> The benefits here for KDE are: > >> * we have a > >> better understanding of our userbase leading hopefully to > >> better software > >> * we have a better understanding of our userbase leading hopefully to > >> better marketing > >> * we have a clear policy we can point our users to that explains how > >> we are handling their data and that is in line with our vision/what we > >> stand for. > >> > >> > I've studied the wiki page more in depth and I have these points where > >> > I'd > >> > like to see improvement. This is based on my experience, not a list of > >> > quick > >> > ideas. > >> > > >> > > >> https://community.kde.org/Talk:Policies/Telemetry_Policy# > >> > >> Thank you! Volker is probably best equipped to answer these. > >> > >> > That said: I will nod to the concept of "Minimalism", it is all > classic > >> > property of telemetry. I think I've seen them in other projects too. > >> > I'd just say, let's not make all this more limited than anyone wants > it > >> > to > >> > be. > >> > >> Where is it too limited? Please keep in mind that we've set > >> privacy as > >> a core part of our vision and the current goals. > > > > > > Lydia, > > Hi Jaroslaw, > > > It's a core part but still a part and can't contradict, say, with the > > Freedom part. > > > > Please see the list of limitations: > > https://community.kde.org/Talk:Policies/Telemetry_Policy# > > (in my opinion that's not a "nice to haves" but requirements needed so we > > can even call the whole thing "telemetry") > > > > I am asking for an alternative approaches, Volker once mentioned there > are > > some. > > We need them to we move forward. > > > > In the meantime my stack runs just well, people that use IDs are even > given > > right to remove their data, something that's *not* going to be possible > with > > the proposed vision. Someone would convince me otherwise. > > Please don't drag our websites ability to have people login to them > into your argument here. > Cookies as used by websites are quite different to Telemetry on many > points. > Dear Ben, based on your experience I'd like to hear your voice how web apps of any kind are different or are special cases, compared to apps that happen to do the same but do not use the "web" stamp so discussed data collection features are delegate to 3rd-party clients called web browsers. How an OPT-IN ID like 2a7c819f-636c-403e-afa1-c9e37031c1de based on random generator[1] is more serious privacy concern than required (login+email+password) non-anonymized tuple for web accounts of web apps of any kind. Please do not take this as pointing to any core infrastructure, I am pointing to specific established technology and practices. Then do we agree that the purpose of random ID collection is secondary as long as both sides know it and
Re: Telemetry Policy - Remaining Questions
On 2 April 2018 at 22:56, Lydia Pintscher wrote: > Hey Jaroslaw :) > > On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek wrote: > > Thanks for reminding me Lydia > > > > I've not forgotten this. While there's progress I do still see this as a > > pilot stage and do not think we're in a hurry given telemetry is > something > > "extra" for a project development, not a core feature of any product. > > We are in a hurry now. We're waiting for projects to be able to start > using it and get us valuable insights about how our software is used. > We've been on it since last Akademy. Let's get it finished :) > > > Below I am referring to this version: > > https://community.kde.org/index.php?title=Policies/Telemetry > _Policy&oldid=78057 > > > > tl;dr: Why discussing: Any deep change and limitation to projects' > freedom > > needs to bring substantial benefits over drawbacks. Level of complexity > of > > the contract for a project or individual developer needs to be balanced > by > > real (not hypothetical) benefits. > > The benefits here for KDE are: > * we have a > > better understanding of our userbase leading hopefully to > better software > * we have a better understanding of our userbase leading hopefully to > better marketing > * we have a clear policy we can point our users to that explains how > we are handling their data and that is in line with our vision/what we > stand for. > > > I've studied the wiki page more in depth and I have these points where > I'd > > like to see improvement. This is based on my experience, not a list of > quick > > ideas. > > > > > > https://community.kde.org/Talk:Policies/Telemetry_Policy# > > Thank you! Volker is probably best equipped to answer these. > > > That said: I will nod to the concept of "Minimalism", it is all classic > > property of telemetry. I think I've seen them in other projects too. > > I'd just say, let's not make all this more limited than anyone wants it > to > > be. > > Where is it too limited? Please keep in mind that we've set > > privacy as > a core part of our vision and the current goals. > Lydia, It's a core part but still a part and can't contradict, say, with the Freedom part. Please see the list of limitations: https://community.kde.org/Talk:Policies/Telemetry_Policy# (in my opinion that's not a "nice to haves" but requirements needed so we can even call the whole thing "telemetry") I am asking for an alternative approaches, Volker once mentioned there are some. We need them to we move forward. In the meantime my stack runs just well, people that use IDs are even given right to remove their data, something that's *not* going to be possible with the proposed vision. Someone would convince me otherwise. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 1 April 2018 at 15:41, Lydia Pintscher wrote: > Hey folks :) > > We really need to wrap this up now. > > We need the data and we need the > policy in place. It's holding us back from learning more about our > users and making our software better. That's not good. > > On Sat, Nov 11, 2017 at 12:47 PM, Volker Krause wrote: > > So, I see the following possible ways forward: > > (1) We accept the policy in its current spirit, and Kexi complies with > it (if > > necessary after some transition period). > > This would be the ideal way forward and the right thing to do. > > > (2) We accept the policy in its current spirit, and Kexi is exempt from > it. > > As sebas said this is bad communication-wise. But if Kexi can't or > doesn't want to comply that's the next best option. > > > (3) We make the policy opt-in, ie. using it merely as an extra quality > > criteria for the applications wanting to follow it. > > I don't believe this is an option that's in line with our vision. > > > (4) We give up on the idea of regulating telemetry, rolling back on the > > decision from Akademy. > > I don't think that's an acceptable option either because we need to > get a better understanding of how our software is used in order to > make it better. > > Jaroslav: I think you need to make a choice now for Kexi. We can't let > it sit and hope it goes away ;-) > Thanks for reminding me Lydia I've not forgotten this. While there's progress I do still see this as a pilot stage and do not think we're in a hurry given telemetry is something "extra" for a project development, not a core feature of any product. Below I am referring to this version: https://community. kde.org/index.php?title=Policies/Telemetry_Policy&oldid=78057 tl;dr: Why discussing: Any deep change and limitation to projects' freedom needs to bring substantial benefits over drawbacks. Level of complexity of the contract for a project or individual developer needs to be balanced by real (not hypothetical) benefits. I've studied the wiki page more in depth and I have these points where I'd like to see improvement. This is based on my experience, not a list of quick ideas. https://community.kde.org/Talk:Policies/Telemetry_Policy# That said: I will nod to the concept of "Minimalism", it is all classic property of telemetry. I think I've seen them in other projects too. I'd just say, let's not make all this more limited than anyone wants it to be. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: do you need www.kde.org write access?
On 8 March 2018 at 09:51, Clemens Toennies wrote: > On 08.03.2018 08:44, Boudewijn Rempt wrote: > >> On Thursday, 8 March 2018 07:57:27 CET Ben Cooksley wrote: >> >>> On Thu, Mar 8, 2018 at 12:42 AM, Boudewijn Rempt >>> wrote: >>> >>>> On Wednesday, 7 March 2018 12:31:21 CET Sebastian Kügler wrote: >>>> >>>>> Hi all, >>>>> >>>>> We have been working on a modernized website and backend for >>>>> www.kde.org. >>>>> The new site will do away with the old PHP custom CMS and will run >>>>> wordpress instead. >>>>> >>>> Does that mean we'll lose our history, just like koffice.org history >>>> from >>>> the php times is only in subversion anymore and the wordpress (or >>>> whatever it was) content is completely gone? >>>> >>> The current content of www.kde.org will still remain in Subversion at >>> the very least. >>> From my understanding the plan Sebas has mentioned envisages a >>> temporary www-legacy.kde.org hostname being kept around until a full >>> migration is completed. >>> >> So we _will_ lose proper access to KDE's release history. That's not good. >> Pages like https://www.kde.org/announcements/ and everything it links to >> should be kept up in eternity. >> > > As far as i can see they will be all available, as they will be imported: > https://www-backstage.kde.org/announcements/ > That's very good the content is there. Question I would have to the www community, are we going to keep exact the same URLs? This it kind of important key since we link heavily, typically between blog entry and announcement for example. I've found our blog content, including blogs.kde.org or forums having dead links to kde.org. Technically, maybe URL rewriting would help for URLs that were in standardized form. Example of koffice.org as topic harder to handle but possible: currently it 100% redirects to calligra.org but it could redirect from koffice.org/X to calligra.org/X maybe or calligra.org/koffice/X. Or rewrite the URL so koffice.org/X would not redirect at all (it depends how we want to have it presented). Example link: to http://www.koffice.org/news/koffice-2-1-released/ from the DOT: https://dot.kde.org/2009/11/24/koffice-21-released. Missing. So relevant announcements for the history of computing, where we have a place: software for Nokia n900... it's missing so also Wikipedia references would be dead. The Wiki must to dig in archive.org now (see "KOffice 1.6 Released" at https://en.wikipedia.org/wiki/KOffice). Sibling topic is: dead URLs to relatively new software such as https://download.kde.org/stable/koffice-2.3.3 (link from https://marc.info/?l=koffice-devel&m=129901230231557). If we have no resources to share the old files (and mirrors refuse that), maybe we could at least have a landing page that lists possible options how to find the archived tarballs? Even more trouble is missing old image resources but this is lesson to learn, we still have no ultimate solution IMHO, hash filesbased URLs get created in share.kde.org and this seems to be fragile approach. I'd think about at the topic as a matter of Freedom in content area. If we're not solid here, what can we tell to next generation of contributors that say "Facebook and YouTube just work". Then we lost image content on blogs, even image tags seem to be somethow lost: example https://blogs.kde.org/2004/02/24/one-little-feature, archived at https://web.archive.org/web/20040531171636/http://www.kdedevelopers.org:80/node/view/359 No images, no context... :( I see the task is not light but preserving KDE history is worth investment maybe even financial. Blogs are to me part of KDE's identity. Good part of it is done nicely in the form of preserving the KDE 1.0 / 2.0 desktops. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: do you need www.kde.org write access?
On 7 March 2018 at 12:42, Boudewijn Rempt wrote: > On Wednesday, 7 March 2018 12:31:21 CET Sebastian Kügler wrote: > > Hi all, > > > > We have been working on a modernized website and backend for www.kde.org > . > > The new site will do away with the old PHP custom CMS and will run > > wordpress instead. > > Does that mean we'll lose our history, just like koffice.org history from > the > php times is only in subversion anymore and the > > wordpress (or whatever it was) > content is completely gone? > But kde.org goes for wordpress , right? Sebastian, calligra.org uses wordpress so it stays unaffected, right? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Proposal for a poll to users about bug triaging
On 28 February 2018 at 16:04, Ilmari Lauhakangas < ilmari.lauhakan...@libreoffice.org> wrote: > On 28.02.2018 16:21, Jaroslaw Staniek wrote: > >> My story is, more rules, more scared users ignore the BKO. A single thing >> worth having is not too many rules but editing feature for *wrong* or >> outdated bug comments that make understanding the report so hard. Many >> years have passed since the first request and this feature still requires >> physical SQL access to the database or so, not regular user skills :) >> Consequence is that I avoid BKO for own reports and go for fully editable >> Phabricator tasks. >> > > Comment tags are a great way to keep the comment track clean: > https://wiki.mozilla.org/BMO/comment_tagging > Bugzilla admins can define tags that make the comment automatically > hidden. Here are the tags that we use in LibreOffice: > https://wiki.documentfoundation.org/QA/BugTriage#Comment_tags > > They can also act as useful pointers like "repro-steps" to highlight a > useful comment. > > The next release of BZ will have comment editing: > https://bugzilla.mozilla.org/show_bug.cgi?id=540#c207 > > Note also the UX roadmaps: > https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-6-Roadmap > https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-7-Roadmap > > Ilmari, these are wonderful news to me :) -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Proposal for a poll to users about bug triaging
On 28 February 2018 at 12:35, Ilmari Lauhakangas < ilmari.lauhakan...@libreoffice.org> wrote: > I am personally convinced that users do not know bug triaging is a thing > and certainly not how much they could help developers by doing it. It would > be very useful to test this by running a poll on https://blogs.kde.org/ > or somewhere. > > Questions could be something along the lines of > "Did you know you can help KDE by analysing bug reports?" > "Did you know you can > > analyse most bug reports with > > regular user skills?" > > Ilmari > My story is, more rules, more scared users ignore the BKO. A single thing worth having is not too many rules but editing feature for *wrong* or outdated bug comments that make understanding the report so hard. Many years have passed since the first request and this feature still requires physical SQL access to the database or so, not regular user skills :) Consequence is that I avoid BKO for own reports and go for fully editable Phabricator tasks. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE receives 200,000 USD-donation from the Pineapple Fund
On 19 February 2018 at 10:36, Paul Brown wrote: > Hello, > > As you probably know by now, KDE received an incredibly generous donation > of > 200K USD from the Pineapple Fund. We have made this public today. > > You can find the dot article here: > > https://dot.kde.org/2018/02/19/kde-receives-20-usd- > donation-pineapple-fund > > Social Media links are here: > > https://www.facebook.com/kde/posts/10155596759068918 > > https://twitter.com/kdecommunity/status/965514290705952768 > > https://mastodon.technology/@kde/99551258536879685 > > https://plus.google.com/b/105126786256705328374/+KdeOrg/posts/Qc3AbPegNCE > > https://www.linkedin.com/feed/update/urn:li:activity:6371281068858966016 This look like a private post a bit, right? I've reposted here: https://www.linkedin.com/feed/update/urn:li:activity:6372395148956966912 PS: Congratz! > > > https://www.reddit.com/r/linux/comments/7ylhg0/ > kde_received_20_from_the_pineapple_fund/ > > https://www.reddit.com/r/kde/comments/7ylhd3/ > kde_received_20_from_the_pineapple_fund/ > > Please share, upvote, re-t[weet|oot], spread to other communities as you > see > fit. > > Thank you > > Paul > > P.S.: If any journalists would like to ask us about this, how this came > about > and what we intend to do with the money, Lydia is the person you should > direct > them to. > -- > Promotion & Communication > > www: http://kde.org > Mastodon: https://mastodon.technology/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 31 October 2017 at 11:56, Sebastian Kügler wrote: > On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote: >> On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote: >> > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause >> > va >> > > Let's try to finally get this finished >> > > >> > > The only remaining blocker is the unique identification used by >> > > Kexi. There >> > > was some discussion about this around QtWS, and it seemed like >> > > there was consensus on having a strong policy on this topic would >> > > be a good thing for >> > > KDE, as opposed to e.g. turning this into just recommendations, or >> > > opening >> > > it up to unique identification. The suggested solution for Kexi >> > > was to add >> > > a special exception for it to the "These rules apply to all >> > > products released by KDE." statement of the policy. >> >> > I'm confused, is that a workaround so that it doesn't apply to Kexi >> > by implying Kexi isn't released by KDE? >> >> That sounds a bit convoluted to me, I was more thinking about making >> it a direct exception to the policy, e.g. like this: >> >> "These rules apply to all products released by KDE (with the >> exception of Kexi, which uses a telemetry system predating this >> policy)." > > This will make the communication downright awful, as people will > concentrate on the exception, not the rule. > I am sure energy would be concentrated on exception and nonconstructive activities (from 3rd parties?) because... please read below: > I'm thinking along the lines of require code released by KDE to adopt > the policy and even add it to the manifesto as requirement to make it > easier to enforce. Kexi can always make it opt-in, and could be given > some time to do so before we officially adopt and require this > telemetry policy. > Jaroslaw, would that work for you? because... one thing is apparently missed even in this internal thread: IIRC Kexi apps have never offered opt-out policy even for anonymous telemetry. I blogged about that as soon as the feature landed [1]. Users pick level of involvement, zero by default, and telemetry is presented as a way for involvement in the project not as a threat. [1] https://blogs.kde.org/2013/12/09/usage-stats -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On 30 October 2017 at 09:56, Volker Krause wrote: > Let's try to finally get this finished :) > > The only remaining blocker is the unique identification used by Kexi. There > was > some discussion about this around QtWS, and it seemed like there was consensus > on having a strong policy on this topic would be a good thing for KDE, as > opposed to e.g. turning this into just recommendations, or opening it up to > unique identification. The suggested solution for Kexi was to add a special > exception for it to the "These rules apply to all products released by KDE." > statement of the policy. > > That would still leave us with a strong policy on this subject, while solving > the conflict with Kexi's current way of collecting telemetry. Would that work > for everyone? Hello Thanks for pushing this forward Volker. In the meantime I got an inspired idea to behave no different than KDE web browsers do with unique cookies e.g. wrt the KDE Identity accounts. Namely there would be zero logic for IDs in Kexi itself but a cookie feature with its standard behavior. As it's the case, it's opt-in. For now I hope this is technically feasible and the result equivalent of the previous solution if not even more flexible. I would appreciate pointing flaws in my assumption. Timeline for that can be connected to development of sign-in features. Unless there is desire to discuss exceptions for a range of KDE software that implements client side for web technologies maybe there is no need for adding specific exception for Kexi or having it communicated by Kexi itself. I'd like to also mention apparent lack of clarity for the outside user wrt what "products released by KDE" mean. What are the defaults in deployed software is a decision of those who deploy the software; legal modifications are allright. KDE "only" releases the source code. So I would not place such a stamp "These rules apply to all products released by KDE" e.g. in About boxes because this has low info value for the actual user or can truly confuse. I am mentioning this here to emphasize that I see telemetry more as a part of the software deployment and support, not a part of the actual "source code product". Decoupling any logic from the source code is part of that. > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: >> Hi, >> >> as not everyone follows long threads, let's start again for the remaining >> issues. >> >> https://community.kde.org/Policies/Telemetry_Policy >> >> The following questions were left unanswered in the previous thread (see >> there for the full arguments if needed): >> >> (1) Should we allow opt-in tracking of unique identifiers? >> >> This was requested by Jaroslaw, as Kexi has this right now and the policy as >> written right now would thus conflict with it. >> >> (2) Should we require/allow/forbid publication of the raw data? >> >> Publication was suggested by Martin F. Practically, this would have to allow >> for a certain delay, we can't have public access to live data. Suitable >> licensing options of the data would probably be CC0 or CC-BY-SA. >> >> (3) Should we require a revocation feature? >> >> That is, allow the user to "delete" the data they submitted from the server. >> This was also suggested by Martin F, and is technically possible without >> compromising anonymity. >> >> (4) Should we define limits on how long we store the raw data? >> >> Brought up by Bhushan. >> >> (5) Should we require an "audit log" feature? >> >> Thas is, allow the user to see a detailed record of what has been submitted >> so far? Martin S suggested this (and it has been meanwhile implemented in >> KUserFeedback). >> >> Not from the previous thread, but from a discussion in Randa: >> (6) What is the "lower bound" of where we consider this policy to apply? >> >> That is, does checking for application updates/news (and possibly tracking >> that on the server) already count as "telemetry" in this context? See e.g. >> the current practice in Akregator or KDevelop. >> >> >> Allowing (1) might conflict with (2) allowing publication, unique >> identification brings us in personal data territory. Publication might also >> conflict with (3) and (4). >> >> So, what's your view on those issues? :) >> >> Thanks! >> Volker > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Added a resources page on community.ko
On 10 October 2017 at 23:25, Olivier Churlaud wrote: > Hi > > Sorry I misused the word namespace. I meant subpage. > > I felt like the issue was not the number of subpage but the name of the > page. > > Would community.kde.org/Talks_and_papers work? I would go with /Talks, and whatever sections are needed in it, Papers, Resources, etc. Useful in situation when Talks itself is empty. I would expect we have templates section too... Sorry and hope this is more clear. > If not, I'm not sure to understand what you would prefer, as > community.ko/Talks/Resources doesn't bring much (talks would be empty and > everything would be in Resources) > > I'm not trying to do "my way" (I don't have one) but to keep with the work > we did during the sprint at Cern, in the same spirit and structure. > > Cheers > Olivier > > Le 10 octobre 2017 22:25:01 GMT+02:00, Jaroslaw Staniek a > écrit : >> >> On 10 October 2017 at 21:48, Olivier Churlaud >> wrote: >>> >>> Hi >>> >>> Le lundi 9 octobre 2017, 21:56:42 CEST Jaroslaw Staniek a écrit : >>>> >>>> On 9 October 2017 at 21:49, Olivier Churlaud >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I don't know if it changes much, but it adds another layer in the page >>>>> tree.> >>>>> I can imagine that someone could write an essay and link it there as >>>>> >>>>> well... >>>> >>>> >>>> In wiki terms it adds a subpage. Navigating will be clean as soon as >>>> https://community.kde.org/Talks exists too (a home page for the >>>> topic). This is usually just the right order of adding hierarchy pages. >>>> Old-school wikis (also KDE's old wiki) used an all-global approach >>>> with bad consequences for browsing experience. >>> >>> >>> >>> You are right in theory. The issue with that is maintainance. Imagine >>> that one >>> day you want to reorganize : if you have too many layers it will be very >>> difficult, that's why we chose to use one or two namespace (be it >>> resources or >>> Talk) and put eveything below, at the same level. The logic will be >>> given by >>> the path people will follow through their clicks. >>> >>> If Talks is better, then let's change that this way. To be more precise, >>> I >>> would do "Talks and Papers". >>> >>> Is it ok this way? if so, I'll change it next week on tuesday. >> >> >> I am not asking for too many layers but more than zero and I am far >> from theory. :) >> Please excuse me sharing some practice that can be maybe of general value. >> >> Picking right and short title / URL is the way to avoid later >> modification. Moving and removing pages can be performed by admins. >> A good start for a new simple page is to have it named in a generic >> way and have with everything inside. You have Talks Resources but >> shall notice we have no Talks page so this is the point to start. You >> can add Resources section there and reorganize later if the page is >> huge. This is also how wikimedia's projects work, then extract to >> content to separate pages if it's already too big. Except they can >> afford (staff) to use graphs (via Mediawiki Category) exclusively, not >> just subpage trees. >> >> The mediawiki's search engine favors page titles so if you use >> Resources we will all be getting them in results also while looking >> for Qt Resources (QRC), KDE PIM resources and so on. [1] >> >> I am not sure you used the namespace anywhere in this context: >> https://www.mediawiki.org/wiki/Help:Namespaces or it is just >> accidental. We've covered subpages, pages, sections and categories, >> not namespaces which we IMHO should avoid. >> >> Cheers. >> >> [1] >> https://community.kde.org/index.php?search=Resources&title=Special%3ASearch&fulltext=1 >> >>> Cheers, >>> Olivier >>>>> >>>>> Le 8 oct. 2017 à 21:29, Jaroslaw Staniek a écrit : >>>>> >>>>> On Sunday, 8 October 2017, Olivier Churlaud >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I wanted to share with you that I added a page for KDE talks and >>>>>> resources >>>>>> on >>>>>> h
Re: Added a resources page on community.ko
On 10 October 2017 at 21:48, Olivier Churlaud wrote: > Hi > > Le lundi 9 octobre 2017, 21:56:42 CEST Jaroslaw Staniek a écrit : >> On 9 October 2017 at 21:49, Olivier Churlaud wrote: >> > Hi, >> > >> > I don't know if it changes much, but it adds another layer in the page >> > tree.> >> > I can imagine that someone could write an essay and link it there as >> > >> > well... >> >> In wiki terms it adds a subpage. Navigating will be clean as soon as >> https://community.kde.org/Talks exists too (a home page for the >> topic). This is usually just the right order of adding hierarchy pages. >> Old-school wikis (also KDE's old wiki) used an all-global approach >> with bad consequences for browsing experience. >> > > You are right in theory. The issue with that is maintainance. Imagine that one > day you want to reorganize : if you have too many layers it will be very > difficult, that's why we chose to use one or two namespace (be it resources or > Talk) and put eveything below, at the same level. The logic will be given by > the path people will follow through their clicks. > > If Talks is better, then let's change that this way. To be more precise, I > would do "Talks and Papers". > > Is it ok this way? if so, I'll change it next week on tuesday. I am not asking for too many layers but more than zero and I am far from theory. :) Please excuse me sharing some practice that can be maybe of general value. Picking right and short title / URL is the way to avoid later modification. Moving and removing pages can be performed by admins. A good start for a new simple page is to have it named in a generic way and have with everything inside. You have Talks Resources but shall notice we have no Talks page so this is the point to start. You can add Resources section there and reorganize later if the page is huge. This is also how wikimedia's projects work, then extract to content to separate pages if it's already too big. Except they can afford (staff) to use graphs (via Mediawiki Category) exclusively, not just subpage trees. The mediawiki's search engine favors page titles so if you use Resources we will all be getting them in results also while looking for Qt Resources (QRC), KDE PIM resources and so on. [1] I am not sure you used the namespace anywhere in this context: https://www.mediawiki.org/wiki/Help:Namespaces or it is just accidental. We've covered subpages, pages, sections and categories, not namespaces which we IMHO should avoid. Cheers. [1] https://community.kde.org/index.php?search=Resources&title=Special%3ASearch&fulltext=1 > Cheers, > Olivier >> > Le 8 oct. 2017 à 21:29, Jaroslaw Staniek a écrit : >> > >> > On Sunday, 8 October 2017, Olivier Churlaud wrote: >> >> Hi, >> >> >> >> I wanted to share with you that I added a page for KDE talks and >> >> resources >> >> on >> >> https://community.kde.org/Resources >> > >> > Thanks, to improve navigation how about Talks/Resources? >> > >> >> It is linked from the main page. It can be a good way to have here >> >> resources >> >> produced by the community. It's currently a unique page with bullet >> >> points, we >> >> can think about having more structure in the future if this feels needed. >> >> >> >> I attached there my impress template, based on the one Volker sent the >> >> other >> >> day. Attach yours as well if you want to share it. >> >> >> >> Cheers, >> >> Olivier >> > >> > -- >> > regards, Jaroslaw Staniek >> > >> > KDE: >> > : A world-wide network of software engineers, artists, writers, >> > : translators >> > : and facilitators committed to Free Software development - http://kde.org >> > >> > Calligra Suite: >> > : A graphic art and office suite - http://calligra.org >> > >> > Kexi: >> > : A visual database apps builder - http://calligra.org/kexi >> > >> > Qt Certified Specialist: >> > : http://www.linkedin.com/in/jstaniek > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Added a resources page on community.ko
On 9 October 2017 at 21:49, Olivier Churlaud wrote: > Hi, > > I don't know if it changes much, but it adds another layer in the page tree. > I can imagine that someone could write an essay and link it there as > well... In wiki terms it adds a subpage. Navigating will be clean as soon as https://community.kde.org/Talks exists too (a home page for the topic). This is usually just the right order of adding hierarchy pages. Old-school wikis (also KDE's old wiki) used an all-global approach with bad consequences for browsing experience. > > Le 8 oct. 2017 à 21:29, Jaroslaw Staniek a écrit : > > > > On Sunday, 8 October 2017, Olivier Churlaud wrote: >> Hi, >> >> I wanted to share with you that I added a page for KDE talks and resources >> on >> https://community.kde.org/Resources >> > > Thanks, to improve navigation how about Talks/Resources? > > >> It is linked from the main page. It can be a good way to have here >> resources >> produced by the community. It's currently a unique page with bullet >> points, we >> can think about having more structure in the future if this feels needed. >> >> I attached there my impress template, based on the one Volker sent the >> other >> day. Attach yours as well if you want to share it. >> >> Cheers, >> Olivier >> > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Added a resources page on community.ko
On Sunday, 8 October 2017, Olivier Churlaud wrote: > Hi, > > I wanted to share with you that I added a page for KDE talks and resources on > https://community.kde.org/Resources > Thanks, to improve navigation how about Talks/Resources? > It is linked from the main page. It can be a good way to have here resources > produced by the community. It's currently a unique page with bullet points, we > can think about having more structure in the future if this feels needed. > > I attached there my impress template, based on the one Volker sent the other > day. Attach yours as well if you want to share it. > > Cheers, > Olivier > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy
On 24 August 2017 at 16:54, Nicolás Alvarez wrote: > >> El 24 ago 2017, a las 07:41, Jaroslaw Staniek escribió: >> >>> On 24 August 2017 at 11:10, Adriaan de Groot wrote: >>> >>> Curiously, there's a lot of "telemetry policy" news items popping up this >>> week, for instance: >>> >>>Mozilla ponders making telemetry opt-out, 'cos hardly anyone opted in >>> >>> (that's on the Register) and there were others. So it looks like >>> communication >>> -- what's the data for, why is it collected, and what can happen to it -- is >>> key here. >>> >>> [ade] >> >> Speaking of that please let me play devil's advocate. In Europe, >> especially Poland all web sites/web apps that collect cookies must >> obtain permission to do that from the user. Interestingly there are >> usually OK buttons only so the message is only an information. >> Sometimes there is "Don't agree" button which is equal to close the >> site. So telemetry-like behavior even lacks opt-out. >> >> [...] >> >> I can imagine we would make our pages work without cookies and add >> opt-in buttons to each main site. >> >> Now KDE context since there's visible call to make privacy our pillar topic: >> 1. Does www.kde.org for example use cookies? > > Yes, and we show the comply-with-Europe-law banner letting the user know > about those cookies. We also follow the browser Do Not Track setting and we > don't collect statistics if that is set. > To meet obligations of the European law it's enough. Obvious but for the record: if we're discussing how much we would care about privacy -- this is delegating the responsibility to 3rdparty software. Which may or may not have this implemented or (most often) *has tracking set as opt-out*. Mozilla, Apple, Google for example have. MS tried to be the good boy [1]. We and GNOME are. [1] https://en.wikipedia.org/wiki/Do_Not_Track#Internet_Explorer_10_default_setting_controversy > -- > Nicolás > KDE Sysadmin Team -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy
On 24 August 2017 at 11:10, Adriaan de Groot wrote: > On Saturday 19 August 2017 12:02:03 Volker Krause wrote: >> Good point, I clarified the intended meaning of "opt-in" in the wiki, that >> is: off by default and only activated by explicit action of the user >> (inaction is not good enough). > > Curiously, there's a lot of "telemetry policy" news items popping up this > week, for instance: > > Mozilla ponders making telemetry opt-out, 'cos hardly anyone opted in > > (that's on the Register) and there were others. So it looks like communication > -- what's the data for, why is it collected, and what can happen to it -- is > key here. > > [ade] Speaking of that please let me play devil's advocate. In Europe, especially Poland all web sites/web apps that collect cookies must obtain permission to do that from the user. Interestingly there are usually OK buttons only so the message is only an information. Sometimes there is "Don't agree" button which is equal to close the site. So telemetry-like behavior even lacks opt-out. I mention this because it's not obvious for me why one technology of making computer utilities has to be preferred over other technologies wrt behaviors around telemetry. (I do call an ordinary web page as computer utility too in this discussion because boundaries are blurred since the day first javascript-enabled page arrived). I can imagine we would make our pages work without cookies and add opt-in buttons to each main site. Now KDE context since there's visible call to make privacy our pillar topic: 1. Does www.kde.org for example use cookies? 2. Is there Privacy, Cookies, and Legal page linked from the main site (the mentioned mozilla.org has them as well as many other sites). OK: Legal is delegated to the e.V. page (I bet the e.V. link from kde.org is much less informative than "Legal" link on Mozilla). Privacy is buried on a (googleable) page https://identity.kde.org/index.php?r=site/page&view=privacypolicy. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy
On 19 August 2017 at 11:39, Volker Krause wrote: > On Friday, 18 August 2017 11:23:49 CEST Jaroslaw Staniek wrote: > > On 17 August 2017 at 16:19, Volker Krause wrote: > > > On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote: > > > > On 16 August 2017 at 18:56, Volker Krause wrote: > > > > > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > > > > > On 16 August 2017 at 14:13, Volker Krause > wrote: > [...] > > > > > - Kexi seems to (optionally?) contain a unique identifier > > > > > > > > This is mostly related to cases when any kind of cloud storage is > used. > > > > These cases involve unique accounts already so users can be > identified > > > > very well even without having telemetry functionality. > > > > > > > > KEXI installations limited to open-core, used away from a cloud, do > not > > > > need identifiers. > > > > However I understand that identifiers, independent of network or > host ID > > > > (basically a random-generated QUuids) are useful for even basic > > > > telemetry needs. Without them it's easy to abuse the system using any > > > > kind of bots to trick us that e.g. 99% of sessions happen on KDE 1.0 > or > > > > that given Linux distro has 90% of the global market :) > > > > > > Vandalism is a potential problem indeed (did you actually have issues > with > > > that on Kexi btw? if so, what counter-measures did you apply?). > However I > > > don't see how a UUID is helping here, the bot could just as well > generate > > > UUIDs for each submission? > > > > UIDs indeed can't help with too clever bots but e.g. semi-evil use cases > > such as executing apps in batch mode can be catch. I've mostly > encountered > > logs coming from test machines including myself so I probably should not > > have used the term 'bots' but (as unrealistic as it sounds) real bots can > > be created. > > Ok, so that's more an accident scenario then vandalism/abuse. Wouldn't the > more targeted counter-measure be to just disable telemetry for the > development > team? > In KEXI, in an anti-corporate fashion, we don't distinguish development team from non-development team. All users are in the team by definition after agreeing to support telemetry. That's one of the motivators. > > > > > Similarly app projects may need the IDs to answer question about most > > > > and least used features. Most used as in "most users found it, > > > > understood it and use it", not "most usage reports has been delivered > > > > for it (maybe coming from a single user -- maybe even my very own co- > > > > developer). There are many other examples probably already discussed. > > > > > > Sure this gets easier with unique ids, but it's not impossible without > > > them. > > > After all the goal here isn't to make our lives easier, but to agree on > > > something that is acceptable for our users. And yes, that might imply > more > > > work and/or less accurate data. > > > > My assumption when started with telemetry was having adequate level of > > precision. Assuming no logs are fabricated as fake interesting questions > > are for example: how many users actually run supported software and how > > many run outdated one? Not how many executions per given period of time > > because it may be that old software is executed by a few users very > > frequently for some reason. e.g. because 3 years old sofware crashes on > old > > OS every minute and restart was needed :) > > > > How to know that without unique (anonymous) identification? > > Using extra fields such as OS+Desktop type/version would be indeed a form > > of cheap UID. > > But I would say disclosing OS+Desktop type/version for that discloses > more > > than the anonymous random UID represents. > > In bugzilla and mailing list we're asking for all this information too > > anyway and (at least I) do not like supporting anonymous users since I am > > not anonymous. > > The implementation in KUserFeedback addresses this by fixed interval data > submission. If you then aggregate the received data by the same interval, > you > can see e.g. how ratios of application versions develop over time. > > This does have limits of course, you can't distinguish between the same > person > using the application every sampling interval, or two people using it ever
Re: Telemetry Policy
On 17 August 2017 at 16:19, Volker Krause wrote: > On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote: > > On 16 August 2017 at 18:56, Volker Krause wrote: > > > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > > > On 16 August 2017 at 14:13, Volker Krause wrote: > [...] > > > > In addition maybe distributors can sometimes make the decision based > on > > > > opinions from given subprojects. > > > > For example the option would be pre-set to ON in KEXI's installer for > > > > Mac and Windows itself and for Linux AppImages, not in the source > code. > > > > Just saying, KEXI has not yet switched to the new framework :) > > > > > > The policy we are discussing here is (and is supposed to be) > independent > > > of the implementation. And that's not just theoretical, Kexi is one > > > prominent case for an alternative implementation, and the Krita GSoC > also > > > seems to contain some alternative server code for example. So input in > > > particular from those teams matters a lot for me, as this policy in its > > > current form would affect them too. > > > > > > And a policy we only adhere in code and work around in the end by > putting > > > on a distributor hat (which we can in many places, as your examples > show) > > > isn't really helping, I'd much rather have it reflect what we actually > do > > > :) > > > > > > From having read the code of both, I think the only possible points of > > > conflict with the policy draft might be: > > > - opt-in > > > > Source code has 100% of opt-in (grep for > > 'areas(KexiUserFeedbackAgent::NoAreas)'). Anyone is free to change this > > default and create distribution under his name and I understand this will > > not be a "distribution by KDE". > > Great, so I just misread both Krita's and Kexi's requirements here and we > don't have a problem :) > In case of KEXI the idea from the very beginning was to make also some distros happy (avoid the need of patching the source). > > > - hosted on KDE infrastructure > > > > My assumption: As KEXI is an open-core+whatever-license-for-plugins > > architecture, ultimately the telemetry information from KEXI users would > be > > better hosted by KDE. Any extra information retrieved by plugins (if that > > even exists) can be hosted elsewhere but and this is a responsibility of > > plugin developers. > > Yep, I'd say 3rd party addons are encouraged to follow the same policy, > just > like distributors, but we have no way of actually enforcing it. > > > > - Kexi seems to (optionally?) contain a unique identifier > > > > This is mostly related to cases when any kind of cloud storage is used. > > These cases involve unique accounts already so users can be identified > very > > well even without having telemetry functionality. > > > > KEXI installations limited to open-core, used away from a cloud, do not > > need identifiers. > > However I understand that identifiers, independent of network or host ID > > (basically a random-generated QUuids) are useful for even basic telemetry > > needs. Without them it's easy to abuse the system using any kind of bots > to > > trick us that e.g. 99% of sessions happen on KDE 1.0 or that given Linux > > distro has 90% of the global market :) > > Vandalism is a potential problem indeed (did you actually have issues with > that on Kexi btw? if so, what counter-measures did you apply?). However I > don't see how a UUID is helping here, the bot could just as well generate > UUIDs for each submission? > UIDs indeed can't help with too clever bots but e.g. semi-evil use cases such as executing apps in batch mode can be catch. I've mostly encountered logs coming from test machines including myself so I probably should not have used the term 'bots' but (as unrealistic as it sounds) real bots can be created. > > Similarly app projects may need the IDs to answer question about most and > > least used features. Most used as in "most users found it, understood it > > and use it", not "most usage reports has been delivered for it (maybe > > coming from a single user -- maybe even my very own co-developer). There > > are many other examples probably already discussed. > > Sure this gets easier with unique ids, but it's not impossible without > them. > After all the goal here isn't to make our lives easier, but to agree on > something that is accept
Re: Telemetry Policy
On 17 August 2017 at 18:20, Thomas Pfeiffer wrote: > > On 17. Aug 2017, at 17:38, Mirko Boehm - KDE wrote: > > Hi, > > On 17. Aug 2017, at 01:46, Thomas Pfeiffer > wrote: > > Hi Valorie, > Even if opt-out for some data is legally and even morally fine, it does not > > align with the values we communicate to our users: > Unlike Mozilla's Mission, our Vision mentions privacy explicitly, and we're > > striving to make privacy our USP. > > > We seem to assume a contradiction between telemetry and privacy. I believe > this is a knee-jerk reaction. We can implement telemetry in a way that > privacy is not violated. In fact, I would say that it follows from our > vision that we should do this. > > > The problem is: I expect users to have the same knee-jerk reaction. I > don’t see us being able to explain to users that actually their privacy is > perfectly safe before they freak out. > Privacy-minded Free Software users have freaked out in the past over > things which objectively speaking were not a huge deal. > It’s emotion more than rational arguments > > It's hard to argue here or generalize to all app's communities. Krita community for example is different than gcc community in these aspects. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy
On 16 August 2017 at 18:56, Volker Krause wrote: > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > On 16 August 2017 at 14:13, Volker Krause wrote: > > > On Wednesday, 16 August 2017 09:33:02 CEST Valorie Zimmerman wrote: > > > > Hi all, Mozilla has done a lot of work on telemetry, and we might be > > > > able to use some of their findings. On this page: > > > > https://wiki.mozilla.org/Firefox/Data_Collection they break down the > > > > data they might possibly collect into four buckets - technical (such > > > > as crashes), user interaction, web activity, and sensitive (personal > > > > data). > > > > > > without making it that explicit, we basically have the same four > > > categories of > > > data too, and explicitly exclude the use of category 3 and 4, ie user > > > content/ > > > activity and personal data, only technical and interaction data are > > > allowed to > > > be used (category 1 and 2). > > > > > > > This bit might be relevant to our discussion: "Categories 1 & 2 > > > > (Technical & Interaction data) > > > > Pre-Release & Release: Data may default on, provided the data is > > > > exclusively in these categories (it cannot be in any other category). > > > > In Release, an opt-out must be available for most types of Technical > > > > and Interaction data. " > > > > > > > > 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. > > > > > > > > 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. > > > > > > This again brings up opt-out, which so far doesn't seem to have a > chance > > > for > > > consensus. Can we defer this to when we have some more experience with > the > > > opt-in approach and how much participation we get with that? Or are > people > > > feeling this would too strongly limit what they are allowed to do in > their > > > applications? > > > > In addition maybe distributors can > > > > sometimes make the decision based on opinions from given subprojects. > > For example > > the option would be pre-set to ON in KEXI's installer for Mac and > Windows > > itself and for Linux AppImages, not in the source code. > > Just saying, KEXI has not yet switched to the new framework :) > > The policy we are discussing here is (and is supposed to be) independent of > the implementation. And that's not just theoretical, Kexi is one prominent > case for an alternative implementation, and the Krita GSoC also seems to > contain some alternative server code for example. So input in particular > from > those teams matters a lot for me, as this policy in its current form would > affect them too. > > And a policy we only adhere in code and work around in the end by putting > on a > distributor hat (which we can in many places, as your examples show) isn't > really helping, I'd much rather have it reflect what we actually do :) > > From having read the code of both, I think the only possible points of > conflict with the policy draft might be: > - opt-in > Source code has 100% of opt-in (grep for 'areas(KexiUserFeedbackAgent::NoAreas)'). Anyone is free to change this default and create distribution under his name and I understand this will not be a "distribution by KDE". > - hosted on KDE infrastructure > My assumption: As KEXI is an open-core+whatever-license-for-plugins architecture, ultimately the telemetry information from KEXI users would be better hosted by KDE. Any extra information retrieved by plugins (if that even exists) can be hosted elsewhere but and this is a responsibility of plugin developers. > - Kexi seems to (optionally?) contain a unique identifier > This is mostly related to cases when any kind of cloud storage is used. These cases involve unique accounts already so users can be identified very well even without having telemetry functionality. KEXI installations limited to open-core, used away from a cloud, do not need identifiers. However I understand that identifiers, independent of network or host ID (basically a random-generated QUuids) are useful for even basic telemetry needs. Without them it's easy to abuse
Re: Telemetry Policy
On 16 August 2017 at 14:13, Volker Krause wrote: > On Wednesday, 16 August 2017 09:33:02 CEST Valorie Zimmerman wrote: > > Hi all, Mozilla has done a lot of work on telemetry, and we might be > > able to use some of their findings. On this page: > > https://wiki.mozilla.org/Firefox/Data_Collection they break down the > > data they might possibly collect into four buckets - technical (such > > as crashes), user interaction, web activity, and sensitive (personal > > data). > > without making it that explicit, we basically have the same four > categories of > data too, and explicitly exclude the use of category 3 and 4, ie user > content/ > activity and personal data, only technical and interaction data are > allowed to > be used (category 1 and 2). > > > This bit might be relevant to our discussion: "Categories 1 & 2 > > (Technical & Interaction data) > > Pre-Release & Release: Data may default on, provided the data is > > exclusively in these categories (it cannot be in any other category). > > In Release, an opt-out must be available for most types of Technical > > and Interaction data. " > > > > 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. > > > > 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. > > This again brings up opt-out, which so far doesn't seem to have a chance > for > consensus. Can we defer this to when we have some more experience with the > opt-in approach and how much participation we get with that? Or are people > feeling this would too strongly limit what they are allowed to do in their > applications? > In addition maybe distributors can sometimes make the decision based on opinions from given subprojects. For example the option would be pre-set to ON in KEXI's installer for Mac and Windows itself and for Linux AppImages, not in the source code. Just saying, KEXI has not yet switched to the new framework :) > Seeing yesterday's blog from the Krita team (https://akapust1n.github.io/ > 2017-08-15-sixth-blog-gsoc-2017/), I'd particularly be interested in their > view on this. > > Regards, > Volker > > > On Sun, Aug 13, 2017 at 3:18 AM, Christian Loosli > > > > 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 > > > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Applications Lifecycle Policy
On 5 July 2017 at 14:11, Jonathan Riddell wrote: > On 5 July 2017 at 13:04, Jaroslaw Staniek wrote: > > Why not? I can imagine we can make the process more dynamic. > > Whole apps or their parts can go back to being maintained, what seems to > be > > a core property of FOSS. > > > > If so how about back-arrow from Unmaintained? > > Probably not worth making the diagram more complex but I added in this > sentence to unmaintained section > > "Projects can move back to an earlier stage if they are picked up for > maintenance again. " > > Thanks, I'd think not "earlier stage" but explicitly "playground" because in the meantime the unmaintained project might lost its "reviewed" stamp. Technology and other requirements move forward. Example: unmaintained project XYZ got restored from Qt4 times to Qt6, needs major changes for translation and build systems. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Applications Lifecycle Policy
On 4 July 2017 at 13:20, 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 > > Jonathan > Hi Looking good. One thing: is there life after "unmaintained"? Why not? I can imagine we can make the process more dynamic. Whole apps or their parts can go back to being maintained, what seems to be a core property of FOSS. If so how about back-arrow from Unmaintained? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE licence policy update
On 10 February 2017 at 15:54, Jonathan Riddell wrote: > I'd like to get back to my proposed update of the KDE licence policy > > https://community.kde.org/Policies/Licensing_Policy/Draft > > I got some comments from Matija Šuklje which I incorporated and it now > includes a handy changelog. > > [..] -Allow icons to be CC-BY-SA 4 > -Allow media files to be CC-BY-SA 4 and no longer allow CC-BY-SA 3 > -Note CC-BY-SA 4 is LGPL 3 compatible > Hi, I like this improvement. 1. How about calling it all "artwork and content" while still listing examples (icons, media files...) 2. I'd like to propose including "visual styles" into that group. By visual styles I mean implemented using using any styling language, including: CSS, HTML/JS templates, JS theming, ODF templates, QStyle (and derivatives). -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: state of release and release plan
On 27 October 2016 at 13:11, Friedrich W. H. Kossebau wrote: > Hi Dag & all, > > Am Mittwoch, 26. Oktober 2016, 14:03:12 CEST schrieb Dag: > > Hi > > Another month came and went, and not much happened... > > I'm actually a little afraid of releasing because we might attract some > > users. > > Well, to be more precise, that there will be nobody to support those > > users. > > If I speak openly that is also my subjective line of thinking. > > Making a release of software means giving it to others and thus making a > promise to them, so subscribing to moral responsibilities. > > Even while having spent so much time and energy into the porting over the > last > two years, I am not sure I am motivated to spent my bit of needed time into > maintenance where needed by non-contributors currently. At least when it > comes > to the main Calligra editor apps. > > My personal interest is in the middleware and technology, and I joined the > Calligra project because it was closest to what I would like to have, > though > with big plans for redesigning basic parts (and quite some draft branches > are > on my local disk). Which is also why I never officially signed up as > maintainer of any of the maintainer-less apps, only for the plugins for > Okular > and some import filters. > > Still, to get some momentum in this discussion, I have just taken the > liberty > to push a commit which removes Braindump, Karbon app & Stage app from > release > builds, as there is no-one even coming close to be a maintainer. At least > with > Stage I hope that commit will trigger someone to react, but then hope dies > last, they say ;) > And by that commit I also express my hope that you the Plan, Sheets & Words > maintainers will still do a release for your software, so that my porting > contributions are coming to someone else's gain still. > > Besides that though I have to state now (also to myself) that I have no > personal motivation to drive or invest into any release work right now, as > there is no itch to scratch for myself here, especially when looking at the > consequences. > > I will happily assist where possible though anyone with a Calligra 3.0 > release > for small related tasks. > > > Also, not to be forgotten, KChart and KGantt needs to be released. > > Yes, thanks for the push :) Though I have had already started to play > around > with the packaging scripts the other WE. As written in private email, > planning > for release on latest Nov. 7th. > > > Thanks for concrete actions, Friedrich. Adding KDE community to the channel... I have no doubts that middleware tech of the project has the most chances to be actively developed. tl;dr for others: Large parts of Calligra will be frozen, buried in KDE git and not released if there are no maintainers. Very soon, so feel free to share the request with the outside world. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Calligra stable releases not in Debian stable Jessi
On 8 October 2016 at 15:20, Maximiliano Curia wrote: > ¡Hola Jaroslaw! > > El 2016-10-01 a las 00:43 +0200, Jaroslaw Staniek escribió: > >> On 1 October 2016 at 00:18, Nicolás Alvarez >> wrote: >> >>> 2016-09-30 6:31 GMT-03:00 Jaroslaw Staniek : >>> >> Honestly, we know via telemetrics that more than needed users run >> outdated software. >> > > What kind of telemetrics are these? > Overview and stats here: https://blogs.kde.org/2013/12/09/usage-stats -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Calligra stable releases not in Debian stable Jessi
On 8 October 2016 at 15:13, Maximiliano Curia wrote: > ¡Hola Jaroslaw! > > El 2016-09-30 a las 11:31 +0200, Jaroslaw Staniek escribió: > >> I am maintainer of Kexi, one of Calligra apps. I've just noticed that in >> Debian stable Jessi the recent Calligra is 2.8.5 which is 13 releases old. >> There are no updates to 2.8.7, and zero updates to 2.9.*. >> > > 2.8.5 is a July 2014 version. Due to security and stability issues it may >> be even better *not* to have this version released at all than receiving >> reports and users thinking that's the most recent version (this is my own >> opinion). >> > > When users run, say, a Raspberry, they see that old and unsupported (by >> us) version. So here Jessi distributes this unstable software despite many >> updates being available. I don't see the same issue with MySQL for example, >> which was updated just this month. Maybe a man power issue? >> > > I have questions then: >> - what happens? >> > > Debian has a release cycle of around 2 years. It uses three separate > tracks: unstable, testing and stable. > > For the first ~20 months of this cycle the package maintainers make > regular updates to unstable and testing, adding new software to the archive > in order to prepare for the next stable release. Packages first go through > unstable and after a while they enter into testing which is what will be > eventually considered for the stable release. > > The last part of the cycle is a freeze period where no new versions are > introduced and all the efforts go to finish the integration of the system, > closing as many bugs as possible, backporting upstream fixes, etc. > > At the end of this cycle the release is tagged as stable and stops > receiving updates, except for critical bugs, and security related issues. > This updates are evaluated by the stable release team, and/or the security > team, once accepted they are available in the proposed-updates or the > security archives till the next stable point release. > > Almost no software gets new versions in the stable release, very few > exceptions are made for critical security bugs in software that's > infeasible to backport the corresponding fixes (an exception was made for > firefox some years ago, and also for mariadb not so long ago), this is > actually a sign that there is something wrong with the software. > > > Jessie is currently the stable Debian version, the current testing version > is called stretch, and is about to enter in the freeze stage. > > - what can be done to fix the situation? >> > > The version of calligra that you point out is in the stable release and > won't get updated to a new version. The package maintainers could decide to > backport some critical fix. > > Could you point out the issues that you consider critical in 2.8.5? > > Thanks for the explanation Maximilian. If I can summarize (maybe not just for you as you have in-depth understanding but more like for users and people from the outside of our projects). If I understand correctly, the 'stability' term used by Debian is a distribution-oriented one. Do you agree that releasing stability fixes for a software, not just serious security fixes is a part of maintaining software stability? Even if we're staying with Kexi as an example, because of better familiarity, let's look at its basic 24 months+ -old changelog of version (not present in Debian stable): https://www.calligra.org/news/calligra-2-8-6-released/ It was *really* surprising for me that Debian Stable has no 2.8.7 in the offer. Knowing the idea of freezing already, I have not asked for 2.9.x but we have semantic versioning and release cycles for a purpose to serve better and predictably. It's clear that Kexi, even if updated to 2.8.6 is more stable than 2.8.5, right? Obviously there are fixes of "I can't use the software anymore" category. Are these fixes critical? Yes, if actual *using* the software for a practical purpose is the goal, not ability to have any version installable. If you're asking about security threats removed, there are such beasts, please refer to my examples for the 2.8.7 release given in this thread. Regarding "I can't use the software anymore" kind of bugs. As MS discovered long ago with the beloved Office 97, users run something like 20% of the functionality but everyone uses slightly different 20%. So also Kexi and Calligra offers a huge feature set, as any integrated software package; possible applications/combinations are hard to imagine or predict. No doubt there are users for whom versions 2.8.[0-5] contain critical issues in features they depend on so the software in that version as a no-go for them. What'
Re: Calligra stable releases not in Debian stable Jessi
On 1 October 2016 at 00:18, Nicolás Alvarez wrote: > 2016-09-30 6:31 GMT-03:00 Jaroslaw Staniek : >> >> Dear Debian contributors, >> I am maintainer of Kexi, one of Calligra apps. >> I've just noticed that in Debian stable Jessi the recent Calligra is 2.8.5 >> which is 13 releases old. There are no updates to 2.8.7, and zero updates to >> 2.9.*. >> >> 2.8.5 is a July 2014 version. Due to security and stability issues it may be >> even better *not* to have this version released at all than receiving >> reports and users thinking that's the most recent version (this is my own >> opinion). >> >> When users run, say, a Raspberry, they see that old and unsupported (by us) >> version. So here Jessi distributes this unstable software despite many >> updates being available. I don't see the same issue with MySQL for example, >> which was updated just this month. Maybe a man power issue? >> >> I have questions then: >> - what happens? >> - what can be done to fix the situation? >> - how to coordinate better? >> > > Jessie is frozen, I doubt Kexi 2.9 will ever be in 'jessie'. I don't > see how MySQL is different, the latest version from upstream is > 5.7.15, Jessie has 5.5.52, it was upgraded from 5.5.50 because of a > specific security fix. > > See this for the criteria to get an update in stable: > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable > > Can you mention specific security bugs that 2.8.5 has? That could > justify bringing 2.8.7 in (or backporting the security fixes). > > And maybe 2.9 could be in the 'jessie-backports' repository. But I > wouldn't expect it in 'jessie'. > > > Of course, this is in addition to the possible lack of manpower to do > such packaging :) Thanks for the useful info, Nicolás. Let's see 1st commit from 2.8.7 which removes possibility of preparing attack that can crash your db. Please see below. It's enough to cause Kexi to ask a specific question and it enters infinite loop and exits with exception, thus e.g. loosing unsaved designs. Really we did not set formal distinction between type of instabilities knowing that *normally* distributors take all fixes and deploy them to the users; because this is a connected/network software for multiuser environment consequences may be more serious than, say, in a locally running text editor. Honestly, we know via telemetrics that more than needed users run outdated software. And request free support for it. commit db59286ef26be67eccf6f0fb31e5abdcf9911d02 Author: Jaroslaw Staniek Date: Tue Nov 25 23:06:03 2014 +0100 Fix infinite recursion in msghandler.cpp The Calligra 2.7.90 build log using msvc2010 gives this warning concerning msghandler.cpp: 'KexiDB::MessageHandler::askQuestion' : recursive on all control paths, function will cause runtime stack overflow Thanks, Stephen Leibowitz CCMAIL:librestep...@gmail.com REVIEW:121180 FIXED-IN:2.8.7 Another, specific query can be passed by one user to another and cause a crash; in theory also executing arbitrary code on some architectures: commit eaefd12562da5b422ae175351423fa15fd1a2cb4 Author: Jaroslaw Staniek Date: Wed Jun 4 13:12:22 2014 +0200 Fix crash when accessing a query with duplicated table names Example query that crashed: SELECT t.foo FROM t, t. Now error message is displayed so user can fix the statement. BUG:315852 FIXED-IN:2.8.4 If the database serves more than one user it can also mean denial of service attacks: it's enough to set query to be always executed initially e.g. for a main form. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Calligra stable releases not in Debian stable Jessi
Dear Debian contributors, I am maintainer of Kexi, one of Calligra apps. I've just noticed that in Debian stable Jessi the recent Calligra is 2.8.5 which is 13 releases old. There are no updates to 2.8.7, and zero updates to 2.9.*. 2.8.5 is a July 2014 version. Due to security and stability issues it may be even better *not* to have this version released at all than receiving reports and users thinking that's the most recent version (this is my own opinion). When users run, say, a Raspberry, they see that old and unsupported (by us) version. So here Jessi distributes this unstable software despite many updates being available. I don't see the same issue with MySQL for example, which was updated just this month. Maybe a man power issue? I have questions then: - what happens? - what can be done to fix the situation? - how to coordinate better? Best regards. -- Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE Licensing Policy Updates
On 20 September 2016 at 22:54, Thomas Pfeiffer wrote: > Certainly not. AGPL is like GPL in that sense, with the extra rule >> that you must publish the source code even if you're only giving >> access over the network and not distributing binaries. >> >> I don't think an AGPL library makes much sense though. >> >> >> ALGPL makes sense then :) >> >> > > On the other hand: Is Qt still used much for web services? And if so: Are > our frameworks of much use for those? > > There are Qt related projects that facilitate adding web service compatibility to a traditional code (example I tried recently: qhttpengine). QML is network transparent, and web services with QML has been advertised by some contributors. There were commercial endeavors such as Enginio. Many more examples I just forgot about. I don't see these things advertised that as much (and infantile) as all the "awesome" web things that so often live for one year and die, or transforming themselves without looking back or caring for compatibility and are encouraging copy-paste type of usages. When asking about local vs web computing there seems to be apparent polarization, you switch tools every time you move from one world to another. That does not need to be a rule. > I think this might be more of an edge case. I suppose that if we're doing > web stuff, it's more likely to be full applications rather than libraries. > Well I'd like to see such usage increasing. Not to create unholy mix but to truly continue the x0 years old concept of client-server computing, just differently named artifacts. I think certain already good apps and libs from FOSS would be even better and more popular if they have support use cases that require web services and if placing some of the logic on the server would be an officially supported feature. Certainly also my modest usage would increase too (two Qt projects at the moment) so the ALGPL term isn't a nonsense for me. Programming for a local workstation is simpler, maybe that's why many C++ developers start there and and also stay in where the sweet spot is. For example the last time when a contributor offered help in adding to support for Oracle server in my KDE project... it was in 2004. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE Licensing Policy Updates
On 20 September 2016 at 22:00, Nicolás Alvarez wrote: > 2016-09-20 16:53 GMT-03:00 Jaroslaw Staniek : > > > > > > On 20 September 2016 at 21:42, Nicolás Alvarez < > nicolas.alva...@gmail.com> > > wrote: > >> > >> 2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek : > >> > > >> > > >> > On 20 September 2016 at 21:19, Thomas Pfeiffer < > thomas.pfeif...@kde.org> > >> > wrote: > >> >> > >> >> On 20.09.2016 19:52, Nicolás Alvarez wrote: > >> >>> > >> >>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell : > >> >>>> > >> >>>> Added: > >> >>>> ''Applications which are intended to be run on a server'' can be > >> >>>> licenced under the GNU AGPL 3.0 or later > >> >>>> Rationale: KDE Store code is under AGPL > >> >>>> Question: should this be an option or a requirement for server > >> >>>> software? > >> >>> > >> >>> I agree with this change, but I think it should remain an option. > >> >> > >> >> > >> >> I would support making it mandatory, actually, or at least > recommended, > >> >> because for an end user a web service based on GPL software is no > >> >> better > >> >> than one based on proprietary software, because they cannot tell what > >> >> software it is they're interacting with. Therefore, the AGPL closes > an > >> >> important hole in FOSS web services. > >> >> > >> >> I don't feel very strongly about this, but to me it would make sense > to > >> >> at > >> >> least recommend AGPL for web software we produce. > >> >> > >> > > >> > I see that too but also aren't we also limited here in one case: when > >> > our > >> > LGPL software is usable for services? What can we do with e.g. KF5? > Move > >> > it > >> > to AGPL and add linking exception? > >> > > >> > Sorry if that's already solved some way. > >> > >> AGPL code can use GPL and > >> LGPL libraries. > > > > > > Sure but that's not the challenge. > > Rather: can an AGPL library be dynamically linked to a proprietary > binary? > > Certainly not. AGPL is like GPL in that sense, with the extra rule > that you must publish the source code even if you're only giving > access over the network and not distributing binaries. > > I don't think an AGPL library makes much sense though. > ALGPL makes sense then :) > > -- > Nicolás > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE Licensing Policy Updates
On 20 September 2016 at 21:42, Nicolás Alvarez wrote: > 2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek : > > > > > > On 20 September 2016 at 21:19, Thomas Pfeiffer > > wrote: > >> > >> On 20.09.2016 19:52, Nicolás Alvarez wrote: > >>> > >>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell : > >>>> > >>>> Added: > >>>> ''Applications which are intended to be run on a server'' can be > >>>> licenced under the GNU AGPL 3.0 or later > >>>> Rationale: KDE Store code is under AGPL > >>>> Question: should this be an option or a requirement for server > software? > >>> > >>> I agree with this change, but I think it should remain an option. > >> > >> > >> I would support making it mandatory, actually, or at least recommended, > >> because for an end user a web service based on GPL software is no better > >> than one based on proprietary software, because they cannot tell what > >> software it is they're interacting with. Therefore, the AGPL closes an > >> important hole in FOSS web services. > >> > >> I don't feel very strongly about this, but to me it would make sense to > at > >> least recommend AGPL for web software we produce. > >> > > > > I see that too but also aren't we also limited here in one case: when our > > LGPL software is usable for services? What can we do with e.g. KF5? Move > it > > to AGPL and add linking exception? > > > > Sorry if that's already solved some way. > > AGPL code can use GPL and > > LGPL libraries. > Sure but that's not the challenge. Rather: can an AGPL library be dynamically linked to a proprietary binary? In other words: When I am changing LGPL to AGPL to get the service protections, is there any way I can still have the above right LGPL is designed for? Staying with dual license (AGPL, LGPL) is not a solution because people can pick LGPL/GPL for services, e.g. grab all the KF5, grab KDE apps, fork them and create any closed services they want. Well, some would already do that and we would never know. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE Licensing Policy Updates
On 20 September 2016 at 21:19, Thomas Pfeiffer wrote: > On 20.09.2016 19:52, Nicolás Alvarez wrote: > >> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell : >> >>> Added: >>> ''Applications which are intended to be run on a server'' can be >>> licenced under the GNU AGPL 3.0 or later >>> Rationale: KDE Store code is under AGPL >>> Question: should this be an option or a requirement for server software? >>> >> I agree with this change, but I think it should remain an option. >> > > I would support making it mandatory, actually, or at least recommended, > because for an end user a web service based on GPL software is no better > than one based on proprietary software, because they cannot tell what > software it is they're interacting with. Therefore, the AGPL closes an > important hole in FOSS web services. > > I don't feel very strongly about this, but to me it would make sense to at > least recommend AGPL for web software we produce. > > I see that too but also aren't we also limited here in one case: when our LGPL software is usable for services? What can we do with e.g. KF5? Move it to AGPL and add linking exception? Sorry if that's already solved some way. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE Licensing Policy Updates
On 20 September 2016 at 20:42, Sune Vuorela wrote: > On 2016-09-20, Jonathan Riddell wrote: > > Differences: > > Removed > > "code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1" > > Rationale: Qt is now LGPL 3 as well as 2 > > Qt is not LGPL2.1 in general. As long as we want to be LGPL2.1 compat, > we can't copy code from Qt. > Precision is needed here; I can easily copy some Qt project's code and even relicense if I find it useful. I mean the BSD examples. > > > Added: > > ''Applications which are intended to be run on a server'' can be > > licenced under the GNU AGPL 3.0 or later > > Rationale: KDE Store code is under AGPL > > Question: should this be an option or a requirement for server software? > > Not a requirement. Just like we don't have copyleft requirements > anywhere. > > And it should also be specific to things on a web server. > > For example: > An imap AGPLv3 server might be a bad thing - there is a way to notify > the user over teh imap protocol, but it is annoying for users, so it > should really not be used. (It is the way quota messages and similar > normally are sent) > > > Added: > > "Content on collaborative edited websites such as wikis must be > > licensed under the Creative Commons Attribution-Sharealike 4.0 > > International." > > Again, I don't think we should force copyleft. > > > Changed: > > "Documentation must be licensed under the Creative Commons > > Attribution-Sharealike 4.0 International" > > Also here. No need to force copyleft. > > > Removed: > > Standalone media files CC 4.. "This does not apply to icons or > > anything which is likely to be mixed with content under our normal > > (GPL etc) licences." > > Rationale: CC 4 is compatible with GPL 3 which is the licence of > > Breeze icons anyway. > > I want my icons licensed under the same terms as my application. Even > when my application is more liberal licensed than GPLv3. > This. If I have icons that are part of my LGPL framework, I don't want my icons to be viral making the framework GPL and thus severly self-limited. The same goes for icons in LGPL apps (yes, LGPL is good for modular apps that happen to be a source of frameworks). I see a similar issue with widget styles such as Breeze; their viral GPL affects apps, libs or plugins that choose to include them. For _nobody's_ benefit. I see no need to be more paranoiac when dealing with friends than it's needed. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: [kde-community] msoscheme joining kde
On 13 May 2016 at 12:28, Jos van den Oever wrote: > On Friday 13 May 2016 01:25:48 Jaroslaw Staniek wrote: > > +10 > > > > We need more general-purpose projects like > > that. > > Cool. What's the next step to getting a project? > > Look if the 'msoscheme' name is general enough according to what you (correctly) suggested. Maybe xml-something? Then: Get a git repo and phabricator project - sysadmin ticket. Create a page on the community wiki. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] msoscheme joining kde
On 13 May 2016 at 00:28, Jos van den Oever wrote: > Hello all, > > Calligra relies on a project called MSOScheme. This project generates Java > and > C++ from an XML description of the Microsoft Office binary file formats. > > The project used to be on Gitorious. Gitorious closed and MSOScheme needs a > new home. > > The code is not moving very fast and currently only Calligra uses it. The > code > only supports MS Office files, but it would be great to support more file > formats. > > Writing XML instead of code for parsing and serializing has great > advantages. > You prevent many memory errors and can work on optimization without > understanding all the separate file formats. This approach helped Calligra > to > have very fast MS Office parsers. At the time this was needed for running > well > on Nokia Maemo and Meego phones. > > As an example of the flexibility, there are 3 types of C++ generated. One > that > can parse with zero allocations, one that is a bit more easy to use but > does > use allocations and a third one that has full introspection on the parsed > data > and can output it as an XML tree for easy debugging or conversion with XML > tools. > > https://gitorious.org/msoscheme/msoscheme.git/ > > I believe the project could be useful for more than just Calligra. I'm > writing > a small demo to create a parser for tar files as a simple tutorial. > > +10 We need more general-purpose projects like that. And IMHO if there's a way to make (generate) a C++-only version of the tool then even better. Larger audience. Best regards, > Jos van den Oever > > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] [Kde-pim] A new home for Mozilla Thunderbird at KDE?
On 27 April 2016 at 15:13, Jos van den Oever wrote: > On Wednesday 27 April 2016 21:42:12 Eike Hein wrote: >> On 04/27/2016 06:36 PM, Daniel Vrátil wrote: >> > I like the idea of having Thunderbird in KDE. It shows that we are an open >> > community and welcoming towards "outside" projects and of course it would >> > be also a good PR for both sides. >> >> No, it wouldn't. The message wouldn't be "KDE community is open to the >> outside", it would be "KDE offers shelter to legacy project, hoping to >> salvage some attention from it". >> >> Make no mistake, Thunderbird is a dead project. It's built on a toolkit >> that's EOL, and hardly has enough of a development community to sustain >> the app, much less the stack beneath it. That it has users (like me) >> that still use it despite the mounting bitrot and deteriorating >> performance doesn't change that outlook. Many people who use Thunderbird >> want to switch away from Thunderbird. >> >> KDEPIM does face some similar challenges, but is actually much further >> along on componentizing its codebase to where e.g. moving from QWidget >> tovother toolkits is feasible, and QtCore is far from dead. As a >> developer, if I wanted to work on email stuff, I'd rather go there than >> invest my hours into Thunderbird. And that's part of the problem, too. >> >> If we were to incubate Thunderbird, it would need to supply really >> really strong answers for how it's going to pull its own weight to >> offset the resource and PR cost. > > Years ago, LibreOffice split off from OpenOffice. Apache OpenOffice is now > barely > alive. They hardly manage to release security fixes. And yet, still more > people > know about OpenOffice than about LibreOffice. Most of these people are on > Windows. > LibreOffice is working hard to change this but it takes very long. > > Thunderbird is a very familiar program to many. It is a strong brand. If > Thunderbird deteriorates, it will leave many to give in and go to webmail > hosted by an advertising company. That way the number of people using real > mail clients might be halved. > > If the Thunderbird team were to decide to update their codebase and perhaps > move to use Qt components, they might retain their userbase. Subsurface and > Gcompris went this way too, to technical success. Any such decisions should be > made by the Thunderbird developers and there are quite a few of those. > > Looking at the commit logs of Thunderbird, the programs certainly does not > seem dead at all. Last month there were on average two commits per day by 18 > authors. [1] Sure they might have technical debt, but so did OpenOffice. > Moving > away from the link to the Firefox release schedule, might even give breathing > room for more fundamental work. If I could be more practical, my advice would be as radical as: - legally get the Thunderbird brand while it's *still* known and positive - rename KDE PIM to Thunderbird - make the Windows port shine - grab the userbase - ... - profit? No offense. It's win-win. For Thunderbird it's escape from the technical debt (using Mozilla's own words). -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
Very good, Agustin. This shows everyone a wider picture. I think it's important to name things in a way that feels like a positive thing or at most neutral. So 'user feedback' not 'tracking', etc. And I would disagree with accusations by those that use 'tracking' terms. In this context if the vision says: "A world in which everyone has control over their digital life and enjoys freedom and privacy." The 'electronic' user feedback is exactly the important means that give users this very control. And they do not trade the freedom or privacy for that control, not more than in a case when I state that it can feel offensive when anonymous users communicate with a project when we, project members, are not hiding behind nicknames. Conversely, people are free to trade the values: trade the control for privacy and freedom. We can only hope these would be rare cases in the general user's population. Our defaults regarding the 'user feedback' policies could address that. On 21 April 2016 at 00:49, Agustin Benito (toscalix) wrote: > Hi, > > (long mail) [..] -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
On 15 April 2016 at 14:01, Sebastian Kügler wrote: > On Thursday, April 14, 2016 05:49:18 PM Jaroslaw Staniek wrote: > > One idea: KDE's tradition is integration of experience; how about a > single > > "Do not track" setting for apps (not just for the Plasma) like it's the > > case for browsers? > > I'd prefer a much simpler and easier to understand thing: > > "Plasma does not track" > > ...unless you tell it to do so, but in its pristine settings, it doesn't. > This > message can set us apart positively. > In practice: Fair enough if this also applies to, say, browsers installed on the same OS. Without that the experience is academical and sets us apart in a minimal population. I don't even know if it's possible to have a Linux system without curl, bash etc., all of these components have own visions of privacy. "x does not track" in practice leads to something like "no offline capabilities enabled by default". The question about "tracking" is a special hypothetical consequence of (presumed) lack of trust to KDE developers and/or KDE distributors. Where one group has no 100% control (in positive sense) over the other. Moreover let me analyse :how can Plasma affect this behaviour in apps when they are loosely connected as there's no longer a thing like "KDE app"? :) I'd rather apply the statement about KF5, even it's still a marginal feature because; as it was said in this thread already any application is free to have online capabilities. IMHO, while it's not easy to design, it would improve/modernize many of them but I am not pushing for anything. > -- > sebas > > Sebastian Kügler•http://vizZzion.org•http://www.kde.org > _______ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
On 14 April 2016 at 19:04, Kevin Krammer wrote: > On Thursday, 2016-04-14, 14:36:21, Jonathan Riddell wrote: > > On Thu, Apr 14, 2016 at 04:18:30PM +0200, Thomas Pfeiffer wrote: > > > Any potentially privacy-sensitive information transfer should be > opt-in, > > > not opt-out. > > > I'd assume that the vast majority of users will allow it (given that > it's > > > not personally identifiable and they trust their distro), but opt-in > puts > > > you on the safe side. > > > > What's privacy sensitive about it? It's a machine ID but not linked > > to any other information other than IP address and there's no personal > > information we can link it to. > > I am with Thomas. > > While individually pieces of information aren't personal, they can be in > combination. > > In this case the combination of a unique machine ID and IP address together > with geolocation would allows us to track movement of machines. > > Movement profiles can often quite easily be used to identify the moving > person. > > There was a huge scandal in the US a couple of years back in which a > telecom > company released fully anonymized (random unique IDs) mobile phone location > tracks. > Researchers who correlated positions with addresses were able to identify > more > than 80% of the telco customers with pretty good accuracy only shortly > after. > > Sure. But I think Jonathan only mentioned _access_ to the IP data as needed for an Internet service, not logging it for any purpose. In user stats only particular aspects are important, uniqueness is very useful to know the users better (to serve them better) but even without that, statistical information is handy too for us, who have to make informed decisions about further developments. A completely different discussion would start as soon as some kind of (FOSS) app store is involved where users can have their accounts. Stats are paired with them or existing IDs created for different reason, with, say, KDE identity IDs. There's definitely opt-in needed. At different level, any online capability of our native apps is potential means for tracking if users don't trust us that we're not logging IP numbers. Yet, the apps are typically downloaded and updated somehow via TCP/IP. At this level the access alone is an opt-in and manifestation of trust. Jonathan also said about machine ID because the software is maintained at system (machine-like) level. With container technologies such as Ubuntu Snaps (which I'd like to see working well with KDE software) it's possible to switch from a system to a user-account level. Yet, if the snap packages can be migrated with the account between machines, the connection between the user-identity and the machine/system becomes more blurry. In an interesting way for me this resonates with the ideas of form-factor-independence formulated within KDE. > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
On 14 April 2016 at 17:30, Thomas Pfeiffer wrote: > On Donnerstag, 14. April 2016 14:36:21 CEST Jonathan Riddell wrote: > > On Thu, Apr 14, 2016 at 04:18:30PM +0200, Thomas Pfeiffer wrote: > > > Any potentially privacy-sensitive information transfer should be > opt-in, > > > not opt-out. > > > I'd assume that the vast majority of users will allow it (given that > it's > > > not personally identifiable and they trust their distro), but opt-in > puts > > > you on the safe side. > > > > What's privacy sensitive about it? It's a machine ID but not linked > > to any other information other than IP address and there's no personal > > information we can link it to. > > It's still a unique identifier which can be used to track the machine. We > might > then combine it with others who also only collect the machine ID to create > a > profile. > People can be very sensitive about these topics, especially since we've > made > privacy-aware users our main target audience. > > As I said: the vast majority would give us their consent anyway, but it > just > comes across as "nicer" if we ask. > > Martin's suggestion with "Make it explicit on the download page that we > collect these data, and allow users to switch it off in privacy settings if > they don't like us to do it" works as well, but then users would need to > have > a chance to turn it off /before/ the ID is sent the first time. > Sure. All depends how large is the population of our user base that is _this_ sensitive. Or not our but for specific project (Neon, {someappname}, {someservice}) Without any negative assumptions: As a software author I don't know many people in person who refuse to use browsers, refuse using e-shops and refuse visiting traditional shops that use video recording, using GSM/etc. I only heard about the stories with RMS and his secretary (I suppose he/she is tracked via browser instead of him -- even without cookies, tracking is possible). After thinking about that long ago; it's not even clear _who_ and at _what level_ someone makes the decision about defaults of privacy. Because the chain looks like: 1. Organization sets defaults for the org 2. Authors of the code in a subproject set the default for the code 3. Distributor decides about defaults set in the binaries One idea: KDE's tradition is integration of experience; how about a single "Do not track" setting for apps (not just for the Plasma) like it's the case for browsers? Questions about level of privacy could appear on the first run of Plasma or first run of a KF5 app for given $HOME. It may be that distributors that are very afraid of privacy, think Debian, may use the feature; others may easily disable it. > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] user stats for Neon
On 14 April 2016 at 15:16, Jonathan Riddell wrote: > A while ago Albert gave a talk at Akademy about collecting some data > on our users. This got me thinking and with Neon I wanted to see how > many installs we had. Our package install software will check for new > versions being available and I could count the IPs of this check but > that's very unreliable. Canonical counts IPs from the NTP ping at > boot up but of course it's only useful at best as a relative metric of > numbers of installs not absolute numbers. So I added a machine-id to > the URL it checks which is the unique value set at install time by > systemd (/etc/machine-id) so now it has a good idea of being able to > count the number of installs. > > But KDE cares about privacy and it's in our Vision and I don't want to > be accused of violating that. But currently I can't see how this can > violate users privacy any more than an IP address can so I'm curious > to hear what arguments might come up against this. ++1 for any such stats to serve users better. They do understand the concept as it's used widely. If this is interesting for you: What I do in-app (Kexi - https://blogs.kde.org/2013/12/09/usage-stats) when users agree is: generating an UID to track unique uses (including full reinstalls as long as the $HOME dir stays. This helps to avoid dynamic IP problems. I did not find IPs so useful. > Jonathan > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Our new project metadata system
On 31 March 2016 at 14:18, Luigi Toscano wrote: > On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote: > > On 31 March 2016 at 17:13, Luigi Toscano > wrote: > > > Wait, no. The metadata there are outdated, the ones in project > > > repositories > > > have been updated _and_ translated in the meantime. > > > > Where do I find them? I can't find anything in every project's repo > > > They're sometimes in /, sometimes in src/ and similar subdirs. https://github.com/search?utf8=%E2%9C%93&q=org%3AKDE+.appdata.xml&type=Code&ref=searchresults (sorry but I probably can't search this way without github :/) -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Our new project metadata system
+1 for using wider accepted standards, whatever they are, and making life of distros easier too. On 31 March 2016 at 12:06, Luigi Toscano wrote: > On Thursday 31 of March 2016 13:55:03 Boudhayan Gupta wrote: > > Hi all, > > > > Over the last few weekends we've been doing some spring-cleaning to > > our infrastructure. You may have noticed that we've killed off > > projects.kde.org, and we have new scripts that generate our > > kde_projects.xml without having to depend on ChiliProject now. We're > > also planning to deprecate kde_projects.xml itself, and to that effect > > we've started setting up a JSON/REST API at > > https://apps.kde.org/api/v1/. > > > > The same infrastructure that is used to generate data for our API and > > the XML file can be used to generate a HTML website with landing pages > > for our applications, and this is something we intend to do in the > > coming months as a replacement for the outdated kde.org/applications > > site. To achieve that, however, we're going to need some help from > > you. > > > > Our project metadata is currently held in the sysadmin/repo-metadata > > repository. We currently hold data about the project name, repository > > and a one-line description of each project. We would like maintainers > > and anyone who can help to provide us with three things for every > > project - a *description.md* file with a bigger description of each > > project that appears on the website, and for applications with a GUI, > > a *screenshot.png* file with a screenshot of the app and two icons (a > > 256 * 256 px icon.png and a 512 * 512px icon_2x.png). > > I don't think we need to do this; we have AppStream metadata. > > Long time ago it was in fact discussed how to not duplicate the information > between the json on the website and the AppStream metadata. There was some > idea on how to generate one from the other. Check this old thread on > kde-core- > devel, from November 2013 ("Adopting AppData in KDE? > http://marc.info/?l=kde-core-devel&m=138348776618380&w=2 > http://marc.info/?l=kde-core-devel&m=138349411519937&w=2 > > And also, more recent: > https://mail.kde.org/pipermail/kde-community/2015q4/002132.html > > Now, whether we like them or not, those metadata are already available and > going to stay. I don't think we want to duplicate again the same set of > data > for the website. > > I would say then to use them for the website, adding the missing files in > the > process (most of applications are already covered). > > Ciao > -- > Luigi > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - final version
g On 16 March 2016 at 21:48, Ingo Klöcker wrote: > On Wednesday 16 March 2016 12:09:27 Sebastian Kügler wrote: > > On Tuesday, March 15, 2016 10:53:03 PM David Jarvie wrote: > > > This may read a bit better, although it does slightly alter the > > > emphasis: > > > > > > "A world in which everyone has control over their digital life and > > > enjoys freedom and privacy." > > Perfect. > > > > I love this. It conveys what we want, and brings in a positive angle > > to the freedom and privacy goals. > > +1 > Thanks everyone. This great result is motivating. > Regards, > Ingo > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On 7 March 2016 at 21:43, Alexander Neundorf wrote: > On Thursday, March 03, 2016 04:46:20 Jos Poortvliet wrote: > > replying on phone. blame faulty text completion/correction for any > rudeness! > > On Feb 29, 2016 5:40 PM, "Alexander Neundorf" wrote: > ... > > > Can we express the "not be at the mercy of some company" clearer than > > > "have full control" ? > > > > But then you have to spell it all out - it isn't just about companies but > > governments, heck even individuals or charities... > > > now that is an interesting point, being independent from governments. > More and more services of (local or national) governments are offered > online. > Just as on example, assume that some documents would be only available as > pdf. > You need at least a device, an operating system, a pdf reader. > Or other stuff, communicating only via some network service (email ?), > sending > in documents in some specific format, etc., etc. > > So IMO it should be a goal of a government to enable their citizen to use > those services using software which is free of cost (at least for their > citizen), and without having to rely on some company. There are two obvious > ways to achieve that: software development done by the government, and > development of free software supported/paid for by the government. > > > I think "sustainability" describes the concept I have in mind: something > which > works at some point in time and you can rely on that it will also work in > the > future. > Don't know how to put that into a vision, maybe something like "a > sustainable > ecosystem of software/technology/... > > > which gives everyone full control over > their digital life" ? > I would not depend on theoretical government in our visions. The ones I heard about do their best to maximize number of _controlled_ jobs because they can then "sell" them for power in their internal circles. I've touched this problem a bit personally too. Just look at healthcare IT backoffice systems in many countries. One about to be restarted in Poland after 15 years. Or one web form that costed 3B$ in the USA, money went to IBM, the bigest sponsor of Linux ever. In this light, consuming FOSS advantages directly is rather evil idea for these governments as it reduces paid/controlled jobs. And taxes! Regarding full control - I find it a bit pathetic. Todays' extremes cause that if we just call for "control" and not "full control", we're already very good. It'd say we can try to "return people control over their digital life". Not "everyone" because "everyone" is the new meaningless "nobody". > Alex > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - an alternative draft for discussion
On 15 February 2016 at 20:40, Alexander Dymo wrote: > On Mon, Feb 15, 2016 at 7:51 AM, A. Spehr wrote: > > "World domination through free software." > > > > Maybe that's too flippant, or more the vision of Linux and not KDE, but > that > > was my first thought as I glanced at this in the middle of the night, > while > > half asleep. Who doesn't want to take over the world with cool toys? > > I'm all for world domination :) But as the start, I'd be OK with KDE > dominating the software that people use on their personal computing > devices (both mobile and not). Aren't all these devices cool? > No surprise you are :) http://i.imgur.com/f3rJdnN.png /me hides ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Fwd: KDE Vision – towards “wholesame” solutions
On 15 February 2016 at 19:12, Ingo Klöcker wrote: > On Sunday 14 February 2016 23:57:56 Alexander Neundorf wrote: > > On Saturday, February 13, 2016 13:12:52 Lydia Pintscher wrote: > > > On Sat, Feb 13, 2016 at 7:45 AM, Olaf Schmidt-Wischhöfer wrote: > > > I agree that integration within our projects is important. And I > > > believe it has suffered lately as the cohesion inside KDE became > > > less. My gut feeling is that this should go in the mission. > > > > > > > I would suggest a sentence like the following: > > > > “KDE aims to offer complete, well-integrated solutions – while > > > > connecting different platforms, devices and online services.” > > > > > > That sounds good to me. > > > > To me too, but I still miss the reference that it is about software > > with graphical user interfaces (GUI's can also have gesture or voice > > input etc.), which Olaf seems to imply too. > > I mean, we are not targetting e.g. sensor networks built from 8bit uCs > > communicating to some big online server, with no user intervention > > (which would fit that description too), or are we ? > > Please don't speak for me. You've made it absolutely clear that _you_ > are only interested in GUI. That's totally fine. We need people who > focus on (G)UI applications. But we also need people who focus on non- > GUI-stuff. A large part of Frameworks 5 is non-GUI-stuff. Akonadi (and > its spin-off) is non-GUI stuff. > > Therefore, I'm against a-priori excluding anybody who is not interested > in (G)UI applications from KDE by restricting ourselves in our vision to > (G)UI applications. > > Of course, the mission statement can mention that we _mostly_ (but not > entirely) focus on (G)UI applications and supporting libraries and > services. > > > >From another angle: it's something seriously not good if mature, nontrivial apps are not layered. Then, for sufficiently complex challenges (think PIM, IDEs, RADs) the architecture benefits from having purely non-GUI layers. It's a bit more forced by-design with the Qt Quick tech but should be encouraged also for the QWidget world that is the current stable reality for us, KDE. > Regards, > Ingo > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Fwd: KDE Vision – towards “wholesame” solutions
On 15 February 2016 at 07:54, Martin Graesslin wrote: > On Sunday, February 14, 2016 11:57:56 PM CET Alexander Neundorf wrote: >> > I agree that integration within our projects is important. And I >> > believe it has suffered lately as the cohesion inside KDE became less. >> > My gut feeling is that this should go in the mission. >> > >> > > I would suggest a sentence like the following: >> > > “KDE aims to offer complete, well-integrated solutions – while >> > > connecting >> > > different platforms, devices and online services.” >> > >> > That sounds good to me. >> >> To me too, but I still miss the reference that it is about software with >> graphical user interfaces (GUI's can also have gesture or voice input etc.), >> which Olaf seems to imply too. > > I can only repeat my advice: please don't close doors for KDE by focusing on > GUI. There is a world beyond GUI and KDE partially already entered it. Don't > close it. Maybe GUI -> UI would solve that. Or "primary focus is the UI". Indeed we don't need to say "GUI" too much, that's similar case as with Qt - many outsiders relate it to "just" the GUI stuff, what, depending on the reason, isn't correct or honest. (/me as developer of KDb, non-GUI stuff, since 2004) >> I mean, we are not targetting e.g. sensor networks built from 8bit uCs >> communicating to some big online server, with no user intervention (which >> would fit that description too), or are we ? > > Please ask yourself the following question: what if a project inside KDE > started to do it? What would happen with the project? Would they stay in or > would they leave KDE? > > I understand that you want to draw a line to define what KDE is. The danger > here is that this will always only work to exclude things. Drawing the line is > not easy. Just right now in your last mail you redefined GUI to include speech > recognition so that the line would cover that. Dangerous, just dangerous. By > leaving so much open for interpretation your drawing a line doesn't work. > > So go from the other side. Look at where KDE might be going with it's own > projects and everything where it might go must be inside the line. And then > you realize that the line doesn't make much sense. > > If you draw the line to exclude you must be willing to kick projects out, > otherwise it doesn't make sense. If you don't kick them out and keep the line > to exclude projects coming in you create a two class society, a project > hostile to incorporating new projects. > > Both are things I don't want KDE to be. I don't want my projects being kicked > out because they might not do GUI. Neither do I want to be part of a community > which is excluding projects which do not fit, although KDE itself has projects > which fit. > > Thus: don't mention GUI in the vision. > > Cheers > Martin > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Wikis uneditable
Hi Ben, It seems that techbase isn't locked. There were a few acts of vandalism too: https://techbase.kde.org/Special:Log/delete PS: Any update on possible solutions for the wikis? On 2 February 2016 at 08:51, Ben Cooksley wrote: > Hi all, > > Until further notice, all wikis hosted under KDE.org have been > rendered uneditable by everyone except members of the Identity group > "web-admins". > > Unfortunately it seems bots (or a human sweatshop) have completely > automated the login (via OpenID/Identity none the less) and abusive > editing of many of our wikis. > > This appears to be an issue being experienced by other Mediawiki > installations elsewhere as well. > > At some point we may reinvestigate restoring editing rights to a more > limited number of users, but until then our wikis will remain closed > to editing. > > If necessary, we may need to consider migration to alternative Wiki software. > > Regards, > Ben Cooksley > KDE Sysadmin > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Differences between proposed vision drafts (or "inclusive" vs "focused")
On 4 February 2016 at 20:49, Alexander Neundorf wrote: > On Thursday, February 04, 2016 20:38:52 Boudhayan Gupta wrote: > ... >> Under the "focused" proposal, such a software would have no place in >> the KDE Project. In fact, a software, developed within KDE to address >> KDE's (not KDE users but the KDE Project itself) needs cannot be a >> part of the KDE Project. Do we want this situation to arise? > > just answering for myself, but it seems to be the same as Alex D. is saying: > the four points listed in the draft are where we see the focus of KDE. > It would be stupid to exclude projects which support those. > KDE never did that, why should we start with that (arts, unsermake, icecream, > eigen, etc...) > Still we don't see linear algebra libraries or build tools as the main goal > KDE is trying to achieve (...says the guy who maintained the KDE buildsystem > for more than 7 years). Build helpers in a form of cmake scripts are part of the KF5 product, if I understand correctly. That's good. Not sure it was already raised: even while having focus on traditional apps: - server software can act as enabler for some KDE apps. Any multi-user app is in this group (not that KDE rules this 'market', sure there can be improvements, who codes decides); - mobile/embedded software can be enabler for some KDE apps, e.g. think of 1. remote-controlling presentation software with a mobile/embedded app 2. remote-data-entry mobile app for an inventory management app/ (and KF5 can further grow by the way; it's exciting to see how KDE is rather good at making new frameworks this way!) > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] RFC: Distribution outreach program
On 3 February 2016 at 15:15, Martin Graesslin wrote: > On Wednesday, February 3, 2016 2:05:05 PM CET Lydia Pintscher wrote: > > On Wed, Feb 3, 2016 at 3:01 PM Martin Graesslin > wrote: > > > No, that's not what I'm saying. First of all we need to realize that we > > > have a > > > big problem (yay for Thomas), second we need to find a solution to the > > > problem. > > > Currently we are brainstorming ideas and I think that needs to > continue. > > > But > > > pretending there is no problem and continue as we used to work, does > > > obviously > > > not solve the problems. > > > > > > Personal note: as some might have noticed I'm deeply disappointed with > the > > > state of our software in distros. And I'm envious to Unity which has > > > Ubuntu > > > and Cinnamon which has Mint and GNOME Shell which has Fedora > Workstation. > > > And > > > OSX which has OSX and Windows which has Windows. > > > > Are there things we can do to help the people inside the distributions > who > > are fighting for us and want to get our software to the enduser in a good > > state? > > I think some aspects discussed here can help those people. E.g. a list of > requirements could help to have a stronger standing when a technology needs > updating. > > Also we could provide ways which make it easier for distributions to share > experiences, so that mistakes don't get repeated. > Yes, e.g. if half of us go and create a README.PACKAGRS file, or two, for KDE software they know, that's the thing :) > Cheers > Martin > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] RFC: Distribution outreach program
On 3 February 2016 at 15:01, Martin Graesslin wrote: > On Wednesday, February 3, 2016 10:46:26 AM CET Nicolás Alvarez wrote: > > > On Feb 3, 2016, at 10:16, Martin Graesslin wrote: > > > > > > On Wednesday, February 3, 2016 9:44:13 AM CET Nicolás Alvarez wrote: > > >>>> On Feb 1, 2016, at 15:31, Cornelius Schumacher > > >>>> wrote: > > >>>> On Monday 01 February 2016 13:04:37 Sebastian Kügler wrote: > > >>>> > > >>>> I'm not against automated testing at all, I just think it doesn't > work > > >>>> at > > >>>> the highest level and bears pitfalls of distros gaming the system, > or > > >>>> people actually care more about the number of points they get than > the > > >>>> actual user experience. > > >>> > > >>> I think we have to readjust the perspective here a bit. I really > > >>> appreciate > > >>> Thomas' initiative because there definitely could be better > > >>> collaboration > > >>> between distributions and KDE. We have the common goal to get our > > >>> software > > >>> to users in the best possible shape. We shouldn't see that as a > gaming, > > >>> blaming, or judging, but we should see this as an opportunity to work > > >>> together in a better way. How this is then expressed to the public > is a > > >>> second thought, and should be decided together with the > distributions. > > >>> > > >>> So defining and discussing criteria which make up a good experience, > > >>> listing and communicating requirements, talking to each other about > what > > >>> is missing, what needs to be fixed, and where it should be fixed > without > > >>> playing upstream- downstream-ping-pong, sharing and possibly aligning > > >>> roadmaps, all these things and more could happen through the > > >>> distribution > > >>> outreach program. This would be really wonderful. > > >>> > > >>> In essence I think this is about better communication between KDE and > > >>> distributions, so that we can productively work on what needs to be > > >>> fixed, > > >>> avoid misunderstandings, and keep a common momentum. > > >> > > >> Here is an idea that shouldn't be novel but I have yet to see > mentioned. > > >> > > >> If you see a distro doesn't package KDE software correctly, doesn't > > >> integrate with the system, doesn't provide a good user experience for > > >> whatever reason... file a bug on the distro's bug tracker. Instead of > > >> putting the distro on a user-facing "they don't do things good enough" > > >> list. > > > > > > You haven't seen this one proposed, because it just doesn't work. Do > you > > > really think nobody reports bugs about incorrectly packaged stuff? Or > that > > > we don't talk to the distros? Do you know how often we get answers like > > > "well I would like to, but we have $POLICY". I could give you examples > > > like outdated Qt in Kubuntu, broken cursors on Fedora, missing Wayland > in > > > openSUSE Leap, no way to suspend in Devuan, etc. etc. - I could name > you > > > a $POLICY issue for each distro. > > > > > > Sorry once you have done this for years, you realize this approach > doesn't > > > work. Personally I'm pretty fed up with the state our software is in, > in > > > various distributions. I'm sick of having to take the blame for it. > This > > > approach hasn't worked, we need to look for new ways. > > > > So we're going to shame them into complying by leaving them out of a > list? > > They'll pay attention to our wiki more than to their policies? Several > > people in this thread mentioned distro policies as a reason why this > won't > > work, in fact. > > No, that's not what I'm saying. First of all we need to realize that we > have a > big problem (yay for Thomas), second we need to find a solution to the > problem. > Currently we are brainstorming ideas and I think that needs to continue. > But > pretending there is no problem and continue as we used to work, does > obviously > not solve the problems. > > Personal note: as some might have noticed I'm deeply disappointed wit
Re: [kde-community] Wikis uneditable
On 2 February 2016 at 08:51, Ben Cooksley wrote: > Hi all, > > Until further notice, all wikis hosted under KDE.org have been > rendered uneditable by everyone except members of the Identity group > "web-admins". > > Unfortunately it seems bots (or a human sweatshop) have completely > automated the login (via OpenID/Identity none the less) and abusive > editing of many of our wikis. > > This appears to be an issue being experienced by other Mediawiki > installations elsewhere as well. > > At some point we may reinvestigate restoring editing rights to a more > limited number of users, but until then our wikis will remain closed > to editing. > > If necessary, we may need to consider migration to alternative Wiki > software. > > Thanks Ben. I hope so strong steps are not needed. I don't know the integration details but can't selected user that belong to some special group be allowed to edit? Even if manual? Use maybe extra checks? https://www.mediawiki.org/wiki/Extension:ConfirmEdit Regards, > Ben Cooksley > KDE Sysadmin > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Licensing question with header-only libraries
On 24 January 2016 at 09:37, Ivan Čukić wrote: > Hi all, > > I'm preparing a library that will probably end up being a header-only > library. > I would like to use a license like LGPL - the code in question needs > to stay free, but that it can be used from non-free code like it is > the case with other frameworks. > > The issue is that (if I'm correct) LGPL does not have anything > different to GPL in this case since this is not a library that is > dynamically linked - if someone uses it, its code becomes a part of > the end product. > > If the above is correct, I think we should add a GPL+exception to the > list of approved licences. > Hi Ivan I'd go with LGPL+exception. It's effectively the same as GPL+exception in this context but shows the intent of providing a library. If someone ever transforms the code to a regular library + headers, no change will be needed: LGPL will work for linkable code, and LGPL+exception for the embeddable headers. Cheers. > > > -- > KDE, ivan.cu...@kde.org, http://cukic.co/ > gpg key id: 850B6F76 > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] A call for finding Free imgur replacement
Yes though... there tend to be options "never remove". People are and will be using these (often closed) tools no matter how cool git, svn, or wordpress media uploads are (well the latter is really hard to use for me, dozens of clicks and naming for a simple upload). On 29 September 2015 at 11:24, Ben Cooksley wrote: > On Tue, Sep 29, 2015 at 10:20 PM, Jaroslaw Staniek wrote: >> On 29 September 2015 at 10:30, Lydia Pintscher wrote: >>> On Tue, Sep 29, 2015 at 9:02 AM, Jaroslaw Staniek wrote: >>>> Cool, there's code ("stikked"), though the service itself is >>>> independent of KDE so can we have an instance at kde.org? >>>> If it's worth the effort, we would need a means to block non-KDE users. >>> >>> Can we please first think about if this really needs to be done by us? >>> We need to focus and be smart about using free and open things that >>> are already out there. >> >> Yes, just so far I've seen no single terms of use that guarantee that >> the files won't be removed one day, e.g. because the sponsor goes out >> of business. Even the lut.im or opensuse. >> I had to once focus on replacing several most important nonworking >> image links on my blog or design documents, I wouldn't like to repeat that... > > Pastebin's aren't intended for those purposes - they're intended to be > for short, quick use items. > Even if we were to provide an image pastebin (which we don't need to > from what I can see) then it would still be for quick use only. > > Long term storage should be done via proper uploading to your blog > host (for blog images). > > Regards, > Ben > >> >> -- >> regards, Jaroslaw Staniek >> >> KDE: >> : A world-wide network of software engineers, artists, writers, translators >> : and facilitators committed to Free Software development - http://kde.org >> Calligra Suite: >> : A graphic art and office suite - http://calligra.org >> Kexi: >> : A visual database apps builder - http://calligra.org/kexi >> Qt Certified Specialist: >> : http://www.linkedin.com/in/jstaniek >> _______ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] A call for finding Free imgur replacement
On 29 September 2015 at 10:30, Lydia Pintscher wrote: > On Tue, Sep 29, 2015 at 9:02 AM, Jaroslaw Staniek wrote: >> Cool, there's code ("stikked"), though the service itself is >> independent of KDE so can we have an instance at kde.org? >> If it's worth the effort, we would need a means to block non-KDE users. > > Can we please first think about if this really needs to be done by us? > We need to focus and be smart about using free and open things that > are already out there. Yes, just so far I've seen no single terms of use that guarantee that the files won't be removed one day, e.g. because the sponsor goes out of business. Even the lut.im or opensuse. I had to once focus on replacing several most important nonworking image links on my blog or design documents, I wouldn't like to repeat that... -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] A call for finding Free imgur replacement
On 29 September 2015 at 07:31, Martin Graesslin wrote: > On Monday, September 28, 2015 7:52:29 PM CEST Jaroslaw Staniek wrote: >> Hi, >> Not everyone uses it but some KDE people do: imgur.com and similar >> services for online image pastes. >> Including me. >> >> The usage rate is much heavier than hithub but it's not indicated it >> as a big deal. >> But it is: bug report, review requests, emails (including mailing >> lists) and wikis link to these files that disappear after months or >> weeks. >> The effect is: losing information, losing the backlog. >> >> Equivalent Free services do not exist to my knowledge. I mean >> equivalent, with public access working with the pastebin plasmoid for >> example. > > What about paste.opensuse.org - that's what I use for screenshot sharing. Cool, there's code ("stikked"), though the service itself is independent of KDE so can we have an instance at kde.org? If it's worth the effort, we would need a means to block non-KDE users. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Forum improvements
Thanks for the updates Luca. Yes, as I imagined no updates in this area come entirely for free. Good that you mentioned this underinvested area. I think more actively asking for supporting this part of the infrastructure make sense. People are using it after all and benefiting from it. It's a huge part of KDE working behind the scenes. Perhaps "free software needs free tools" is easy to say and harder make reality. And keep as such. I prefer to combine that with other saying: "for your work use the best tools money can buy". On 28 September 2015 at 20:22, Luca Beltrame wrote: > Il Mon, 28 Sep 2015 15:48:02 +0200, Jaroslaw Staniek ha scritto: > > Hello Jaroslaw, > >> towards two things. Posting here so perhaps people accustomed with web >> services read this. Excuse me if this is already on someone's desk. > > As far as I know, no one is working on the forum code. Some of your > suggestions make sense, but I can't really discuss them here because we > have a much larger obstacle ahead first: the upgrade to phpBB 3.1. > > Despite being a "minor" version, phpBB 3.1 is nothing like phpBB 3.0. In > fact, I don't think, to my limited understanding, very close code wise. > An upgrade to the forum is hard because we have a lot of modifications: > > - Brainstorm (not sure how many use that nowadays, but it's there) > - Mod tools (quick ban for spammers) > - Search > - The theme itself > - ... > > Currently the staff has no time to even think about this upgrade, which > will become necessary sooner or later. And if anyone wonders about a GSoC, > I don't think it qualifies as GSoC material, and unfortunately even if it > did, I'd have no time for mentoring. > > We need someone from the community, preferably *more* than one person as > it's a large task, with good PHP knowledge, which could help us. > > Sorry for hijacking your thread. > > >> So what I do when I expect answer to an important topic is: navigating >> (nightmare on mobile device) to the topic and click via subsequent pages >> to find the answer > > I'm not sure if they changed in 3.1 compared to 3.0, as I didn't look > closely enough. > >> able to fix it (in the style sheets?) for most cases or by googling >> "phpBB-Mobile". > > We need someone to help us with the theming, but doing it for phpbb 3.0 is > IMO a wasted effort. > >> Would it be possible to have a filter (ON or OFF by default?) e.g. in > > I'm not sure it is possible (again, unsure about phpBB 3.1). > > -- > Luca Beltrame - KDE Forums team > KDE Science supporter > GPG key ID: A29D259B > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] A call for finding Free imgur replacement
Hi, Not everyone uses it but some KDE people do: imgur.com and similar services for online image pastes. Including me. The usage rate is much heavier than hithub but it's not indicated it as a big deal. But it is: bug report, review requests, emails (including mailing lists) and wikis link to these files that disappear after months or weeks. The effect is: losing information, losing the backlog. Equivalent Free services do not exist to my knowledge. I mean equivalent, with public access working with the pastebin plasmoid for example. There's some attempt to use a storage within the VDG but from what I see it's not equivalent of the image pastes. Also phab's Pholio [1] is not equivalent of the basic pastes, and is login-walled. We cannot even link to these images from KDE blogs... Similar issue are images on "kde" blogs that sit outside of http://blogs.kde.org. I am using the latter but its images storage support is so 90s that I upload images elsewhere. I imagine may people use Blogger or Wordpress with proprietary storage just like that of github or imgur. Maybe someone has ideas? Is it too resource-hungry to have? [1] https://phabricator.kde.org/pholio/new/ -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Forum improvements
Thanks to the community effort, the KDE Forum's structure is clearly much natural now! Since good investments have been made here, next how about taking steps towards two things. Posting here so perhaps people accustomed with web services read this. Excuse me if this is already on someone's desk. 1. Making forum notifications useful 2. Making forums mobile-friendly 3. Solution to avoid mixing local and archived forums with the global ones Issues I see at least: Ad 1. 1) Actually it's like <> mail subject and there's no clear idea that it's from KDE. No user name assigned to forum-ad...@kde.org or a [KDE Forum] in the subject. It grabs a few seconds more from every attempt of scanning my mailboxes... 2) Notifications somehow form a true login-walled Internet -- more than github notifications I'd say - clicking on the link for the subject brings me to a login page - quite unexpected on mobile device. So what I do when I expect answer to an important topic is: navigating (nightmare on mobile device) to the topic and click via subsequent pages to find the answer 3) Actually the notifications would decrease the traffic _if_ the content was injected in the notification screen if that's my wish; the forum engine we're using seems to be optimised to boost the visit count to get more from ads... something we totally don't need. Ad 2. The layout is like a single word in width in a phone browser; someone who knows how to apply html screen parameters correctly might be able to fix it (in the style sheets?) for most cases or by googling "phpBB-Mobile". Ad 3. Localized KDE forums (many Persian for example) and archived forums account for quite a few of the entire forum list. [1] Would it be possible to have a filter (ON or OFF by default?) e.g. in the account settings, so actual search results and browsing hierarchy is a bit simpler for many users? [1] http://i.imgur.com/xAEukdF.png -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto
On 25 September 2015 at 23:33, Albert Astals Cid wrote: > El Divendres, 25 de setembre de 2015, a les 13:16:46, Jaroslaw Staniek va > escriure: >> On 25 September 2015 at 13:15, Riccardo Iaconelli wrote: >> > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote: >> >> I really do not want the excellent parts of this impassioned >> >> discussion to get lost! We've wondered about it before, and perhaps it >> >> is time to look at this issue again. >> > >> > A web ui? >> > I think that more and more github should be our real competitor, we should >> > strive for the same user-friendliness... :-) >> > >> > A crazy idea: why don't we unite our weight with the one of sister free >> > software projects (GNOME, Wikimedia, ...) to create a free ecosystem >> > (with >> > personal repos and organization, exactly like github) where free projects >> > can be hosted, develop and flourish? >> > >> > If we all decide to host our code on the same resources, we can make this >> > work! With our developer weight visibility is guaranteed! United we >> > stand... >> e.g. Gitlab? > > AFAIR last time we tried gitlab it crawled under "KDE size" scenario, so > unless it has improved it would not work with KDE + more stuff. > Yes. Maybe it's time to for KDE to co-develop more server software? :) Sounds like something more feasible than co-developing specs around potential common development workflow. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github in the light of the KDE manifesto
On 25 September 2015 at 13:15, Riccardo Iaconelli wrote: > On Thursday, September 24, 2015 07:35:41 PM Valorie Zimmerman wrote: >> I really do not want the excellent parts of this impassioned >> discussion to get lost! We've wondered about it before, and perhaps it >> is time to look at this issue again. > > A web ui? > I think that more and more github should be our real competitor, we should > strive for the same user-friendliness... :-) > > A crazy idea: why don't we unite our weight with the one of sister free > software projects (GNOME, Wikimedia, ...) to create a free ecosystem (with > personal repos and organization, exactly like github) where free projects can > be hosted, develop and flourish? > > If we all decide to host our code on the same resources, we can make this > work! With our developer weight visibility is guaranteed! United we stand... > e.g. Gitlab? > Bye, > -Riccardo > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] "Fork Me" button within the kde git infrastructure?
On 21 September 2015 at 02:30, David Narvaez wrote: > On Sun, Sep 20, 2015 at 7:57 PM, Jaroslaw Staniek wrote: >> I see you're not used to the diverse term on github-alike sites: >> forking is more like creating a feature branch. The repo is separate >> but changes can be merged back (how it's a matter of tool set). > > It is just like feature branches, except every fly-by contributor will > have a clone repo with one patch and that way maintainers will have a > harder time figuring out what's been done where and who's working on > what. If this is the workflow you like, good for you, but I want to > opt-out from this madness and use git as it was meant to be used. Thanks for your opinion but this is not the feature and case I was talking about. No fly-by contributor, no one-time patch that could indeed go via email (often private, untracked) as it happens now. If you seem to like things codified: violating code of conduct by using 'this madness', 'terrible idea' terms closes discussion with me for _you_ because you paint things in awful colors before actually understanding basics of the case. Feel free to meet on IRC to get idea what's the case about before continuing. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] "Fork Me" button within the kde git infrastructure?
On 21 September 2015 at 01:27, Michael Pyne wrote: > On Mon, September 21, 2015 00:05:33 Jaroslaw Staniek wrote: >> PS: Freedom of forking - derivative works is not so terrible, it's a >> pilliar of FOSS. > > Last time I tried it, running git-clone against our KDE git infrastructure > still worked just fine, and thus forking is quite easy to do. Did this change > at some point? > > I haven't tried running Github's git import tool since it requires an account, > but even their instructions for manually mirroring a git repo (for use with > private repos) seem easy enough: > https://help.github.com/articles/importing-a-git-repository-using-the-command-line/ > > Likewise for Bitbucket: > https://confluence.atlassian.com/bitbucket/import-code-from-an-existing-project-259358821.html#Importcodefromanexistingproject-PushingaGitproject > The thing is: many people here raise concerns that the forking should happen within the KDE infrastructure. And I agree. If so, the infra should be accessible read-write for the 3rd-parties. > No one is arguing to *try* to make it more difficult to fork KDE or create > derivative works... the "Trinity Desktop Environment" is still up and kicking, > and others could be too with barely any work at all to setup the initial > fork... I see you're not used to the diverse term on github-alike sites: forking is more like creating a feature branch. The repo is separate but changes can be merged back (how it's a matter of tool set). This is the term used on the button. We're not talking about fork-fork like, say Trinity. Two ideas to solve the lack of r-w access without github: - give access to personal repos for with kde identity accounts (possible DoS attacks or draining resources) - use gitlab Community edition or other services that offer source code -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] "Fork Me" button within the kde git infrastructure?
On 20 September 2015 at 23:55, David Narvaez wrote: > On Sun, Sep 20, 2015 at 4:11 PM, Jaroslaw Staniek wrote: >> Hi >> I'd like to ask if this can be technically feasible and something we want: > > > > The subject sounds to me like a terrible idea, but reading the IRC log > I don't think I understand exactly what you are asking for. In > particular, I don't understand how is this different from a web > interface for users to submit a fly-by patch and developers to apply > those patches, which I think is something phabricator would support. This is about r-w git repo for KDE and non-KDE devs. In git times the need is easier to understand for someone who interacts with 3rd party projects at code level. What is your workflow in this case? Do you send git archives git via email or patch sets? And constantly merge? I hope you don't use a private git server because it's worse that any 'free as beer' git hosting solution because of the bus factor and complexity. > If you do mean a "Fork Me" button like in github then it must be > opt-in for project maintainers because I certainly don't want that > workflow in my project. The button is mentioned to note that it's possible to implement it the day when we have the open read-write repos feature (in contrast to currently 'hidden' behind KDE developer account system). PS: Freedom of forking - derivative works is not so terrible, it's a pilliar of FOSS. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] "Fork Me" button within the kde git infrastructure?
Hi I'd like to ask if this can be technically feasible and something we want: [20:05] A quick question: can someone by just creating a kde indentity, have own scratch repositories? [20:08] You may know why I am asking; people say about 'free' replacements for 'free services' but for this pretty standard case we have no support. [20:36] So here we are. There are no 'free' places to share the code in a modern way. [20:37] Not just in early phase of cooperation but also in integration projects. [20:06] sadly no although we wanted that [20:38] depends on what you mean with share [20:38] do you need write access to the same source? [20:42] yes, exactly [20:42] it's not like two step action: receive a patch, apply to a KDE repo [20:43] it's working on a common ground with set of repos usually ad-hoc forked [20:45] the result may result in patches for several projects, KDE, non-KDE, distro projects, non-standard deployments [20:46] just the way of software integration [20:47] jstaniek: I think one solution would be to add an ACL system that allows KDE developer accounts to give write access to specific repositories to non-developer IKO accounts [20:48] then a dev can make the scratch repo and give out the push url [20:48] how do you feel about that? [20:48] better than nothing! it's not a single Fork Me button but one day it definitely can be such -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Sunday, 20 September 2015, Sune Vuorela wrote: > On 2015-09-20, Kevin Krammer wrote: >> First, I have no idea where this "use github for review" comes from at = >> all. >> Who wants to do that in the first place? > > The github pull requests comes automatically with review abilities, so > once it is there and one already interacts with github, it is the simple > thing to do. But effectively it won't be reviews because the KDE reviewers won't use it. Or do you think we need some dracon law because our community cannot do self-control? Similarly kde.org has paste.kde.org. Hell, it's sometimes used for quick reviews. But apparently does not replace the official tools. > > /Sune > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On 19 September 2015 at 23:06, Eike Hein wrote: > > > On 09/19/2015 10:32 PM, Kevin Krammer wrote: >> I don't see there this github review is coming from. > > Review is an interactive process where you ask for changes and > iterate. Once you open the door to doing it on GitHub, you will: > > * Have a hard time making some contributors understand why > they should go through the trouble of moving to Phabricator > in the midst of the review process, or next time. > > * Have a hard time making some KDE developers understand why > they shouldn't just do it on GitHub. > > I don't understand why you expect thinks like "if it matters > people will take it to RB/Phab as second stage" or "after the > first patch we ask someone to get an account and switch to > Phab" will happen as a matter of course. It's so much more > likely that people who are comfortable with GitHub will ask > those who don't to comply (monitor it for requests, respond > to requests, participate), or they just won't be able to agree. There are no such people so far, no people that come and say: change this and that workflow or I'll destroy your project. I'd say many projects are rather ignored than attacked even in the very close C++ world and that's the worst thing that can happen IMHO. I wouldn't see another cases like KHTML->WebKit-type of forks for example. These two things are different: - asking people to apply for KDE developer account to just use a git storage for placing a single initial commits on first contact (the application shall be rejected anyway since they are not contributors and have no mentor's recommendation... catch-22) - asking people that decided to contribute further after first successes (hey, these KDE folks accepted my fixes, nice, I'll learn the workflow then, it pays off!) Cases with SoK and GSoC are different because applicants agree to the rules the first time they apply, they explicitly join KDE even if for a few days/weeks. Other 3rd-parties are *not yet* sure it makes sense for them. I have enough of these probabilistic analysis of what most likely happen. Most of us are largely here for fun. I am not a white collar in this relation to ask people to confront with a wall of text on the first contact. Your attitude may differ but please give me the freedom of forming relations in my way. I am feeling strong enough to trust people and integrate with the outside world. With any git storages that count in this world. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On 19 September 2015 at 21:24, Ivan Čukić wrote: >> Could you mention at least one KDE git repo that belongs to multiple > > Eike already mentioned that Plasma has a single repo in which > different parts are maintained by different people. But is Plasma a single project or not? That's the case for the big calligra.git; Calligra is a single project of somewhat related apps where people trust each other. Here I'd say every maintainer has the right to veto and the decission about github can be also delayed until there are any externally incoming patches. Realistically I don't see anyone who can offer to be a proxy for entire big repo. Maybe a bot can be. (For rather different reasons some calligra code splits out to smaller repos that if really needed, can have separate policies) Note: coincidentally just 10 minutes ago early question about code issue arrived to a mailing list I maintain. I am in process of asking the person if he can show me the code he tries to develop so we can focus on the matter. Without forcing any git hosting solution. Maybe that will be github which is mid road between, say, KDE and LibreOffice. Who knows. I'd just cherry-pick that to my scratch repo or to a feature branch in official repo. Done. The review would continue here within KDE. Then the code can fly, this is git. But the records of the review belongs to KDE. That's why I am safe talking about attracting users of GitHub. But this shows that people need a place to upload the forked repos. We as KDE do not give them write access until they are contributors. So no access to scratch repos (I shouldn't even mention if these are harder to use than the non-free competition, they are clearly too hard for for a newbie who so far made a single commit and decides what next). -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On 19 September 2015 at 21:08, Eike Hein wrote: > > > On 09/19/2015 08:58 PM, Kevin Krammer wrote: >> Even using a review tool in the first place is something that the maintainer >> asks people to do. > > No. We advertise ReviewBoard (and later Phab) as a general > interface to throw code at our maintainers. "I don't look > at ReviewBoard" is not a socially tenable position in our > community in practice, just like "I don't look at GitHub" > won't be*. The pressure will be to cover all places. Some > people will say they don't want to or can't and abandon > one for the other, and we'll have conflict over it and it > will affect who develops for KDE and who maintains our > products. > > If your (generic you) position is that people should be > comfortable with GitHub and a KDE with only people who > are comfortable with GitHub would be a better KDE, then > you don't feel that is much of an issue, and that's more > or less what some of the people in the discussion propose, > unless they trick themselves into ideas like opt-in > or two-stage review actually being viable in a general > fashion. > > * = I've explained elsewhere why making GitHub opt-in > won't work, but in a nutshell: Repositories don't map > to projects; GitHub will spread over time across repo- > sitories because it's hard to opt out again; common > ownership implicitly means there are no "project X" > devs but only KDE devs, or rather that's what we would > like to see and optimize for, so GitHub for any repo > affects all devs. Could you mention at least one KDE git repo that belongs to multiple projects? And thus maybe multiple even multiple groups of maintainers? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 19 September 2015 at 17:36, Riccardo Iaconelli wrote: > On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote: >> But that's not using the pull request. Such workflow would mean that the >> pull request is not accepted anyway, but the code is pushed through the >> infrastructure and not trough Github interface. >> >> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please >> explain exactly what is the meaning of "use Github"? Do we all agree that in >> any way pull requests will never be merged directly through Github >> interface? > > Personally speaking, yes, they will never be merged directly through Github. > > Github mirrors should be read-only, accepting pull requests (or maybe we > should call them "fetch requests") shouldn't make them read-write. Yes, freedom-wise these are like *.patch attachments in gmail e-mails. (I repeat this maybe third time?) @All Let me show the steps I am taking as a maintainer: 1. I get an email with *.patch attachments, it can be raw email or a notification from system such as github 2. I am briefly looking at the contents and decide what next 3a. If the patch comes from a first time contributor and it's worth reviewing I submit it for review in the official infra or asking a fellow contributor to do that; if not, I am gently replying to the author about reasoning and further possible steps 3b. If the patch comes from a next time contributor and it's worth reviewing I am gently asking if she would like to consider a shorter path, what is close to asking for joining KDE but in a more gentle manner 4. From now on normal KDE review process happens and if the code is accepted it lands in the read-write repo, not in the mirror. It's clear from the first minute because the project description in the GitHub mirror says so. Sometimes *popular* projects are silently forked in GitHub. People are in hurry so this happens and it's still better than keeping the patches private. In this case if I find usable code this extra step is needed: 0. Extract the patch(es) on my own from the forked repo and contact the author to come into agreement about upstream merge. In *no* step above I am attempting to patronize potential contributors based on their different tool set, skills, etc. I am also aware that in general *no bot* can replace me in this duty. I am also assuming the patches that have been created are frequently *side tasks* for the authors and not the ultimate goals. These contacts sometimes start *long-term* contributions and relations. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Saturday, 19 September 2015, Shantanu Tushar Jha wrote: > > > On Sat, Sep 19, 2015 at 1:12 PM, Martin Graesslin wrote: >> >> On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote: >> > From my experience, I was already mirroring KDE Connect in Github and I've >> > received valuable patches there. That's a big enough reason for me to want >> > Github's pull requests (and to spend 15 minutes learning how to use them), >> > but I understand not everybody wants to learn a new and non-free tool. >> >> I'm subscribed to kde-connects review requests for reviewboard. How am I as an >> interested developer able to follow the code review for github pull requests >> if I don't want to use them? >> >> Basically by the decision to opt-in for pull requests you force the complete >> team to follow them. Otherwise not-reviewed code gets in. >> >> We really need to think in the big picture of what means this to KDE. We >> shouldn't go the "selfish" road and think of your own project. By allowing >> github pull-requests we are pushing out the contributors who don't want to use >> it. You make it impossible for those contributors to comment on review >> requests, thus you have split the development. >> >> This is scary. Please don't think "selfish". Let people create the pull >> request and answer it with: >> "Sorry we do not support git hub pull request. To submit code please use >> reviewboard.kde.org. Here's how you do it..." >> >> The point is we want to get to the people on github. That's why we mirror. >> It's not about getting pull requests. We want the people! They already spent >> the effort to create the patch, they will spent the additional time to get to >> reviewboard of phabricator in future. I have so often got patches on bugzilla >> and it never was a problem to tell them "please use reviewboard for the patch >> submission as the UI is more streamlined for code review". We always got the >> patch into reviewboard. The aim of the people is not to use pull requests, the >> aim is to submit their patch! > > +1 to that. And adding to it, IMO the most important thing here is consistency. The last thing we want to have is newcomers getting confused "erm, so for this KDE project do I use reviewboard? or do I create a pull request?". > But you just got confused by the claim from Martin, use of github reviews isn't proposed also because our repos are readonly there! Please read what I propose not strawmans... >> >> Cheers >> Martin >> >> ___ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > > Cheers, > > -- > Shantanu Tushar(UTC +0530) > shantanu.io -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Saturday, 19 September 2015, Albert Astals Cid wrote: > El Divendres, 18 de setembre de 2015, a les 23:42:02, Jaroslaw Staniek va > escriure: >> >> Your experience may differ and I value that. Opt-in - nobody forces you. > > It does, once person X submits a patch using github to KDERepoY he'll complain > if he can't for KDERepoZ. > Sounds like a bit superficial premature complain. If only we had a flood of pull requests... Arguing about ease of use is out of topic. > Cheers, > Albert > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Saturday, 19 September 2015, Martin Graesslin wrote: > On Friday, September 18, 2015 5:29:01 PM CEST Albert Vaca wrote: >> From my experience, I was already mirroring KDE Connect in Github and I've >> received valuable patches there. That's a big enough reason for me to want >> Github's pull requests (and to spend 15 minutes learning how to use them), >> but I understand not everybody wants to learn a new and non-free tool. > > I'm subscribed to kde-connects review requests for reviewboard. How am I as an > interested developer able to follow the code review for github pull requests > if I don't want to use them? > > Basically by the decision to opt-in for pull requests you force the complete > team to follow them. Otherwise not-reviewed code gets in. What I meant is that review is handled in a free tool. See I asked about deprecating review board not once to have on tool for the task -phab, for a reason. Github is just like Gmail in this workflow, even less because in my book you can't keep using it for regular contributions -this is a knowledge you get after the first *motivating* success of approved patches. Even at single subproject level fellow contributors don't see a downside, only a chance for more patches. > > We really need to think in the big picture of what means this to KDE. We > shouldn't go the "selfish" road and think of your own project. By allowing > github pull-requests we are pushing out the contributors who don't want to use > it. You make it impossible for those contributors to comment on review > requests, thus you have split the development. > See above, these are not the discussed bits. > This is scary. Please don't think "selfish". Let people create the pull > request and answer it with: > "Sorry we do not support git hub pull request. To submit code please use > reviewboard.kde.org. Here's how you do it..." And can I do better than that 'slap in the face', I am free to do that. > > The point is we want to get to the people on github. That's why we mirror. > It's not about getting pull requests. We want the people! They already spent > the effort to create the patch, they will spent the additional time to get to > reviewboard of phabricator in future. I have so often got patches on bugzilla > and it never was a problem to tell them "please use reviewboard for the patch > submission as the UI is more streamlined for code review". We always got the > patch into reviewboard. The aim of the people is not to use pull requests, the > aim is to submit their patch! > This is you talking to them in person. Quite better thing than automatic closing. > Cheers > Martin > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)
On 18 September 2015 at 23:15, Ivan Čukić wrote: > We should probably put something like LLVM guys did in the project > description instead of actually having the real description. > > https://github.com/llvm-mirror/llvm >> Mirror of official llvm git repository located at >> http://llvm.org/git/llvm. Updated every five minutes. >> http://llvm.org > Sure, this is a github's own "Description" field: http://i.imgur.com/VjlXn3c.png It supports 3 lines of text or so plus a website filed. The "Website" field could be set to a project's home page; projects.kde.org/* as default but maybe something better grabbed from our metadata, e.g. https://community.kde.org/Frameworks for KF5. So do we still need to alter the READMEs? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 22:55, Andre Heinecke wrote: > On Friday 18 September 2015 22:29:31 Jaroslaw Staniek wrote: >> I don't argue with that it needs free tools. Of course we need to be >> able to operate as usual when the nonfree tools disappear. > > As one of the KDE-Windows developers. Who would be able to cope if their > precious Visual Studio is unavailable? Well probably you, Ralf and me (Because > I never used that compiler). The other developers are suckered in a "I'ts free > (as in beer)" (just like github) mentality and didn't learn to how the basics > work that are automated when they use visual studio. So their knowledge is > dependent on the tools. I learned that investing in mimicking *nix experience on windows (cygwin, mingw, finally plasma on Windows) is a dead end. If msvc disappears I'll be more than happy and fund a big company the next day. Hundreds of folks would come to for help to port/maintain somehow the their codebase on the new standard dev platform[tm]. If you care to look why: by using "standards" on the platform I minimize my risks. When I support my apps on GNOME I obey to the rules of GNOME. Same for Unity, Windows, Mac, and mobile etc. or don't proceed. Everything else is not worth my time. Your experience and interest may be different and I accept that. Cheap example: I know people running win95 on an android phone. If you pick mingw for example, you're just picking different boundary that you can effectively accept between Free and non-Free. I'd ask, even if MS changed its attitude 179 degrees now, what happens if mingw can't be effectively (technically/legally) used on Windows? And what's more probable? There's no clear answer. Note, I am developing on Linux which objectively is far better environment for the task. So no matter what compiler I use, this is mostly a deployment task. Plus maybe making things so beauty that users of non-free platforms (99.5+% for my market) donate to drive the open development. >> I do argue with 'Free software needs to reject nonfree tools even at >> the cost of alienating most of the non-KDE world'. > > I would argue against that. Encouraging Free Software tools even if they are > not as convenient as proprietary tools is very important. Hell I'm hacking > together Outlook Addins using free tools because the Idea is that you should > not rely on proprietary tools to work on / with Free Software. > >> Disclaimer: unlike >> rms I don't have access to secretary who browser the internet for me. >> And I still use GSM. > > What do those two sentences mean? I interpret the first one as a cheap shot > against Richard Stallman. (Uhh He eats things from his toes!!! Have you > seen the video?!!) > I fail to understand the second sentence. Scary :) It's a cheap and colorful example of an unrealistic approach of someone who sometimes forget he's just a human being. I know I just won't meet too many contributors if I am suspicious on the first contact. The second sentence means that we're all (except for rms :)) using closed protocols for vital parts of our lives. BTW, rms isn't consistent - last time he travelled to Poland via plane full of closed-source software and even worse hardware. It's his choice but forcing it on me steals parts of my freedom. >> It comes down to the question if one acts more inclusive or exclusive. >> >> For you: that's like 'reject closed-source drivers for kwin even if I >> won't be able to use cool kwin features' type of rejection. >> >> I wouldn't have problem if presence on github would be completely >> opt-in as Friedrich suggested, based on subprojects' requests. It >> would also help to sort out the issue with some obsolete repos. >> Yesterday just dying in project.kde.org playgrounds and today >> everything is mirrored on github. Or is it too late? > > No I don't think that is the point. For me it is more like "Do we start to > accept patches that are created by this proprietary tool and review them using > this same tool?" I did not say that. It's not even similar. Read this as opt-in. You don't get these notifications in projects where I am the maintainer. Patches are created by like-minded individuals in their brilliant minds. How they are encoded, transmitted and visualised does not matter. They can come to me by email and land in proprietary inbox that I read with the help of my properietary x86 CPU. So what. > It's like asking me to install Visual Studio to review and accept patches. No > I will not do this (Yeah github is a webapp but the principle still > applies imo) I did not say that. It's not even similar. There
Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)
On 18 September 2015 at 22:37, Ben Cooksley wrote: > On Sat, Sep 19, 2015 at 8:10 AM, Friedrich W. H. Kossebau > wrote: >> Hi, > > Hi, > >> >> Am Freitag, 18. September 2015, 17:12:12 schrieb Boudhayan Gupta: >>> Ladies and gentlemen, as you read this mail github.com/kde is being >>> populated by the initial sync of all repositories. >> >> Pardon for the late input, missed the dynamic of the people behind this idea >> (and actually expected it would be shot down, at least to me it seems not a >> good idea to add value to a proprietary platform by also adding our source >> code there). >> >> Can we please only mirror those projects whose maintainers are okay with the >> added workload due to another public interface which allows interaction from >> 3rd-party? Too many people will not get that this is only a mirror, even if >> you put it in bold there. Or worse, not accept it is a mirror, because their >> time is more valueable than the time of the maintainers of course. >> >> I have no time (and actually also no interest) to care for people poking via >> github (incl. the time needed to redirect them to the real official KDE >> infrastructure and any bad vibrations because having to argue why I/we do not >> support github really). Other people might have that time and interest, so >> their decision. >> But I don't. I joined KDE for some reason and am doing my FLOSS software >> development here, because of certain values. >> Same would be true for sourceforge.net, gitlab.com, code.google.com (okay, >> dead) or whereever else some people think we should mirror because it's where >> "the people" are currently. >> >> So as maintainer I would like to have at least the repos of Okteta, >> libkoralle, cagibi removed from the official KDE github page. > > Sorry, but an incomplete mirror would cost additional effort to > maintain, as sysadmin would have to maintain a list of repositories > which were blacklisted. > Note that because a chunk of the code that drives this is in bash, it > is not easy to create such a list easily. > > Additionally, an incomplete mirror would be confusing to those who > expect the mirror to be complete - so this blacklist would result in > Sysadmin receving queries of "why isn't this repository on Github?". > Wouldn't lack of opt-in from Friedrich just mean that the bot will be enabled with a friendly note (i.e. the default)? Allright, he (and his projects' members) won't be 'spammed'. > I suggest you instead put a clear notice in the README file noting > that patches and other code contributions should be submitted via our > usual infrastructure. This addition to README.md could be hopefully scripted in a clever way as we have so many projects. Myself I use README.md files for some time as KF5 do, so replacing these a whole README.md with a standard disclaimer is not an option; just saying, I know you did not mean replacing of couse. I'd welcome a nicely crafted template. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 22:14, Martin Graesslin wrote: > On Friday, September 18, 2015 9:52:46 PM CEST Jaroslaw Staniek wrote: >> On 18 September 2015 at 21:16, Marco Martin wrote: >> > On Fri, Sep 18, 2015 at 9:12 PM, Sune Vuorela wrote: >> >>> 2. Regarding the issues/pull requests - nobody agreed/disagreed to my >> >>> proposal. Is anyone against an *opt-in* possibility of enabling Issues >> >>> and/or Pull Requests for a given mirrored repo? Opt-in by maintainer of >> >>> the patches. We can easily draft a policy if someone is afraid. >> >> >> >> Yes. I'm against. And I'm also against mirroring on github, but I didn't >> >> voice my opinion by that because it was said that issues and pull >> >> requests are not to be enabled. >> > >> > yes, i'm not willing to deal with pull requests from github as well. >> > >> > I don't like being on github, but if everybody likes to have a copy >> > here that's fine, until it's a copy and i don't have to use it. >> >> You don't have to use pull requests, as I said: opt-in feature of a repo. >> >> I won't use it too in my workflow. Treat it as an exception: some folks in >> KDE friendly and openly accept patches sent by email and _friendly_ >> encourage that next time for non-trivial work it will be better to use >> official tools. >> >> @Sune you're from KDE but for example packagers often use email to >> send "fix build" patches. >> >> Nobody responded to this to so I'll repeat: I won't reject early >> attempts of people wanting to contribute so if I have to I'll use >> personal forks on github and any other places where I actually can >> meet contributors. >> >> Then the Issues thing is another matter: I'd appreciate that you read >> - I am not proposing to use it as alternative bugzilla (which is >> terrible BTW) but to solve integration issue I am having. Hopefully it >> will be sorted more cleanly one day. >> >> PS: We're also supporting "nonstandard" approach: patches in bugzilla >> (that can never be marked as rejected if are invalid), shouldn't this >> feature be blocked? > > This is completely different. Bugzilla is free software and if we move patch > review to bugzilla (GNOME does that) we have not moved to a proprietary > platform. > > I must say I'm uneasy with the thought of allowing pull requests - even as an > exception. Seeing this raised on the day the mirroring started makes me sad > that I initiated the whole thing. > > So I join Sune, Eike and Marco: "Free software needs free tools, no > proprietary pull requests for KDE development!" I don't argue with that it needs free tools. Of course we need to be able to operate as usual when the nonfree tools disappear. I do argue with 'Free software needs to reject nonfree tools even at the cost of alienating most of the non-KDE world'. Disclaimer: unlike rms I don't have access to secretary who browser the internet for me. And I still use GSM. It comes down to the question if one acts more inclusive or exclusive. For you: that's like 'reject closed-source drivers for kwin even if I won't be able to use cool kwin features' type of rejection. I wouldn't have problem if presence on github would be completely opt-in as Friedrich suggested, based on subprojects' requests. It would also help to sort out the issue with some obsolete repos. Yesterday just dying in project.kde.org playgrounds and today everything is mirrored on github. Or is it too late? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 21:16, Marco Martin wrote: > On Fri, Sep 18, 2015 at 9:12 PM, Sune Vuorela wrote: >>> 2. Regarding the issues/pull requests - nobody agreed/disagreed to my >>> proposal. >>> Is anyone against an *opt-in* possibility of enabling Issues and/or >>> Pull Requests for a given mirrored repo? Opt-in by maintainer of the >>> patches. We can easily draft a policy if someone is afraid. >> >> Yes. I'm against. And I'm also against mirroring on github, but I didn't >> voice my opinion by that because it was said that issues and pull >> requests are not to be enabled. > > > yes, i'm not willing to deal with pull requests from github as well. > > I don't like being on github, but if everybody likes to have a copy > here that's fine, until it's a copy and i don't have to use it. You don't have to use pull requests, as I said: opt-in feature of a repo. I won't use it too in my workflow. Treat it as an exception: some folks in KDE friendly and openly accept patches sent by email and _friendly_ encourage that next time for non-trivial work it will be better to use official tools. @Sune you're from KDE but for example packagers often use email to send "fix build" patches. Nobody responded to this to so I'll repeat: I won't reject early attempts of people wanting to contribute so if I have to I'll use personal forks on github and any other places where I actually can meet contributors. Then the Issues thing is another matter: I'd appreciate that you read - I am not proposing to use it as alternative bugzilla (which is terrible BTW) but to solve integration issue I am having. Hopefully it will be sorted more cleanly one day. PS: We're also supporting "nonstandard" approach: patches in bugzilla (that can never be marked as rejected if are invalid), shouldn't this feature be blocked? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 14:17, Ben Cooksley wrote: > On Sat, Sep 19, 2015 at 12:14 AM, Jaroslaw Staniek wrote: >> On 18 September 2015 at 14:00, Ben Cooksley wrote: >>> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek wrote: >>>> On 18 September 2015 at 13:42, Boudhayan Gupta wrote: >>>>> Ladies and gentlemen, as you read this mail github.com/kde is being >>>>> populated by the initial sync of all repositories. >>>>> >>>>> Maybe someone should make a public announcement? >>>>> >>>>> Shout out to Ben, he truly is a superhero. >>>> >>>> Thanks a lot! >>>> Is it possible to enable Issues support for a given project? (as I >>>> said needed by the bountysource infra at least) >>> >>> From what I saw of the above consensus, issues and pull requests would >>> be disabled as those should go through our usual infrastructure >>> (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a >>> post otherwise i'd be happy to be pointed to it though? >> >> I see what you mean but there was no discussion about this matter in >> this thread at least. >> >> For code I maintain I welcome: >> - any form of patches even if they come via pull requests, just like >> for me emailed patches are also better than no patches >> - any form of donations for features -> for that Issues are needed >> >> It's possible to fork these mirrors to get this support and I am doing >> this now for a test in case of kreport.git. >> https://github.com/staniek/kreport-1 >> >> But again, please consider this as less controlled/predictable >> activity - that forking will happen anyway, as this is the value of >> github-based collaboration, and (IMHO) sense of our existence on >> github. > > The decision isn't mine, it's the community's decision. I know :) > I've already > added a note suggesting people submit patches on Reviewboard. > Don't we slowly drop support for Reviewboard? (even I am still not sure how to correctly update phabricator diff from command line) > For a decision on those two points, i'd welcome pointers to where that > was made in the above thread - or the opening of a new thread on those > topics. @all I think this is still the very same thread "KDE mirrored on github". 1. A friendly bot is a good idea. Friendly i.e. not saying that "you're doing bad thing using github". But if I was external contributor I'd find rejecting my carefully crafted patch rather offensive. Couldn't the link to the patch be sent by email to a right mailing list? 2. Regarding the issues/pull requests - nobody agreed/disagreed to my proposal. Is anyone against an *opt-in* possibility of enabling Issues and/or Pull Requests for a given mirrored repo? Opt-in by maintainer of the patches. We can easily draft a policy if someone is afraid. Until we have "free" bountysource-like infra, I do need github Issues. I also work with bountysource so they find a way to better support bugs.kde.org; for now one can paste the url and it works but issues "for adoption" are not listed. Thanks again! PS: Also I think that I don't spend time on projects to educate people that they shouldn't use github. I am not competing in github's businesses. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 14:00, Ben Cooksley wrote: > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek wrote: >> On 18 September 2015 at 13:42, Boudhayan Gupta wrote: >>> Ladies and gentlemen, as you read this mail github.com/kde is being >>> populated by the initial sync of all repositories. >>> >>> Maybe someone should make a public announcement? >>> >>> Shout out to Ben, he truly is a superhero. >> >> Thanks a lot! >> Is it possible to enable Issues support for a given project? (as I >> said needed by the bountysource infra at least) > > From what I saw of the above consensus, issues and pull requests would > be disabled as those should go through our usual infrastructure > (todo.kde.org / bugs.kde.org / reviewboard.kde.org) - if there is a > post otherwise i'd be happy to be pointed to it though? I see what you mean but there was no discussion about this matter in this thread at least. For code I maintain I welcome: - any form of patches even if they come via pull requests, just like for me emailed patches are also better than no patches - any form of donations for features -> for that Issues are needed It's possible to fork these mirrors to get this support and I am doing this now for a test in case of kreport.git. https://github.com/staniek/kreport-1 But again, please consider this as less controlled/predictable activity - that forking will happen anyway, as this is the value of github-based collaboration, and (IMHO) sense of our existence on github. >> >>> >>> On 17 September 2015 at 20:00, David Edmundson >>> wrote: >>>> >>>> >>>> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth wrote: >>>>> >>>>> Hm I have an existing github mirror with some stars. Instead of >>>>> creating a new mirror I'd prefer to just set KDE to the new owner of >>>>> the Project. >>>>> I guess this is not the only project where that kind of migration is >>>>> preferable. >>>>> So what to do for those projects? >>>>> >>>> >>>> We would need to add you as an admin member of the github KDE group, then >>>> you click "Transfer ownership" in the repo settings. >>>> Stars and forks migrate (I tested this just now). >>>> >>>> Providing the repo names match KDE, the script we have shouldn't create a >>>> new repo but will just push into this one. >>>> >>>> More info at: https://help.github.com/articles/transferring-a-repository/ >>>> >>>> David >>>> >>>> >>>> ___ >>>> kde-community mailing list >>>> kde-community@kde.org >>>> https://mail.kde.org/mailman/listinfo/kde-community >>> ___ >>> kde-community mailing list >>> kde-community@kde.org >>> https://mail.kde.org/mailman/listinfo/kde-community >> >> >> >> -- >> regards, Jaroslaw Staniek >> >> KDE: >> : A world-wide network of software engineers, artists, writers, translators >> : and facilitators committed to Free Software development - http://kde.org >> Calligra Suite: >> : A graphic art and office suite - http://calligra.org >> Kexi: >> : A visual database apps builder - http://calligra.org/kexi >> Qt Certified Specialist: >> : http://www.linkedin.com/in/jstaniek >> ___ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 13:42, Boudhayan Gupta wrote: > Ladies and gentlemen, as you read this mail github.com/kde is being > populated by the initial sync of all repositories. > > Maybe someone should make a public announcement? > > Shout out to Ben, he truly is a superhero. Thanks a lot! Is it possible to enable Issues support for a given project? (as I said needed by the bountysource infra at least) > > On 17 September 2015 at 20:00, David Edmundson > wrote: >> >> >> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth wrote: >>> >>> Hm I have an existing github mirror with some stars. Instead of >>> creating a new mirror I'd prefer to just set KDE to the new owner of >>> the Project. >>> I guess this is not the only project where that kind of migration is >>> preferable. >>> So what to do for those projects? >>> >> >> We would need to add you as an admin member of the github KDE group, then >> you click "Transfer ownership" in the repo settings. >> Stars and forks migrate (I tested this just now). >> >> Providing the repo names match KDE, the script we have shouldn't create a >> new repo but will just push into this one. >> >> More info at: https://help.github.com/articles/transferring-a-repository/ >> >> David >> >> >> ___ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On 17 August 2015 at 11:14, Patrick von Reth wrote: > So I just started the process of Incubating my project and moving it to the > KDE infrastructure, I gained a modest level of visibility on Github and I'm > a bit afraid of losing it. So a github mirror sounds like something > interesting for me as I currently still provide my own github mirror. > > For some projects not for all the issue tracker on github might be a smaller > barrier to report issues as it doesn't require a separate login. Would it be > possible to allow github logins to phabricator for non kde members? BTW There's "Transfer ownership" function on github so I wouldn't have a problem with transferring the ownership to a community account. https://help.github.com/articles/transferring-a-repository/ Bountysource integration with github is my only concern, not tested that with transfer but I know that Issues are transferred too. > From: mgraess...@kde.org > To: kde-community@kde.org > Date: Mon, 17 Aug 2015 10:14:19 +0200 > Subject: Re: [kde-community] Official KDE mirror on github > > > On Monday, August 17, 2015 10:10:17 AM Jos van den Oever wrote: >> On Monday 17 August 2015 09:16:02 Martin Sandsmark wrote: >> > On Mon, Aug 17, 2015 at 12:35:09PM +0530, Bhushan Shah wrote: >> > > In my opinion first two are too wrong arguments to begin with.. If our >> > > repositories can not be found from outside then it requires >> > > improvement from our side. Putting source code on Github is not going >> > > to solve this problem. >> > >> > I don't think improving discoverability of our own infrastructure and >> > putting mirrors of our code on Github are mutually exclusive. I think >> > both >> > will improve our "visibility" so to speak. >> > >> > > Even if people will use github to search projects eventually they will >> > > have >> > > to use our infrastructure to contribute. >> > >> > In my opinion all of our projects should have a short description about >> > how >> > and where to send us their patches, even if we don't push things to >> > Github. >> > If we ensure that our git repositories can be found via search engines >> > people still need to know how to contribute. >> >> Agree. This is a good idea regardless of mirroring on GitHub. >> >> A mandatory preamble in the README.md for each KDE project could go >> something like this: >> >> == >> $name is a [KDE](https://www.kde.org/) project. The source code for $name >> can be found at [$git.kde.org/$name](https://$git.kde.org/$name). KDE >> welcomes you to [join KDE](https://community.kde.org/Get_Involved) and >> contribute to $name. You can report [issues and >> wishes]($git.kde.org/$name] >> (https://$git.kde.org/$name). >> >> == >> >> In this way, even if our repos are not completely indexed, the pagerank >> will >> increase a lot. > > and is also something we could actually install with the software. > >> >> > And I think lowering the threshold for people to contribute in general >> > is >> > also something that should be done (and is being worked on already), and >> > is >> > a bit separate from this thing about mirroring stuff on Github. >> > >> > > And about people being surprised that our code is not on Github, it is >> > > really clear that Github is _not_ standard place to get open source >> > > software. >> > >> > We might think so, but I don't think the rest of the world agrees. >> > >> > > So, In short IMO there is nothing wrong with having Github mirror but >> > > that should be read-only and we should have real reason to do it. >> > > Currently sysadmins are reworking our git infrastructure. So lets wait >> > > little bit and see how it goes and then think of this. >> > >> > Yeah, I agree that the reworking of our own infrastructure should be >> > prioritized, and we should disable the pull requests, bug reporting, >> > etc. >> > for everything we put on github. >> >> ___ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > > > ___ kde-community mailing list > kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Phabricator: Make it happen already!
+1 (I am using it as if it was official) On 26 August 2015 at 20:05, Kevin Ottens wrote: > Hello all, > > So we've been evaluating different options to modernize our tooling, and for > some reason it looks like we're still waiting on some external pressure to > pick one. I'll then try to be this external pressure with this war cry: > > Phaaab! Make it happen already! > > It is basically what I reported during the Phabricator BoF at Akademy this > year. For some obscure (to me) reason, I ended up being one of those who tried > all the contenders, and to me, Phabricator is the best fit for our > community[*]. > > Also recently I'm seeing a surge of use in the test instance, so I'd say it is > time to get it out of limbo and make it official. > > Sysadmins, could we move forward with it please and start migrating for real? > > Thanks for your attention. > > Regards. > > [*] Obviously I'm leaving plenty of details here, I'm not debating the why, > I'm just trying to get the ball rolling. > -- > Kévin Ottens, http://ervin.ipsquad.net > > KDAB - proud supporter of KDE, http://www.kdab.com > > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On 26 August 2015 at 10:52, Luigi Toscano wrote: > Martin Graesslin ha scritto: >> On Wednesday, August 26, 2015 3:38:52 AM CEST Boudhayan Gupta wrote: >>> Hi, >>> >>> Top posting here. Summary so far: >>> >>> 3 votes for Kapture, 1 for KScreenshot, none for any of the non >>> K-prefixed names suggested (Safelight, Selfie, Iris). >>> >>> Generic names like Screenshot aren't being considered. >> >> I suggest two names: >> * on Plasma: Screenshot >> * on non-Plasma: KDE Screenshot >> >> This makes it a nice generic name. Let's face it: nobody would care that it's >> a generic name if Apple or Microsoft called such a tool "Screenshot". The >> only >> "problem" is that we want to have the app also outside of Plasma and we think >> that it's too generic then. So let's add our "KDE" brand name to it. That's >> quite common: brand + generic name. At least the gnome devs do that quite >> often. > > I personally always disliked this choice, since someone called Words a program > about words. It's like "stealing" a generic name from common usage. > > That said, I also think that the name should be unique, which means no double > name in different environment, or it would be complicated. > > My personal vote is for anything but a generic name. Yeah, KDE + generic name is something else though. KDE prefix is not about a brand of the desktop. How can we convince people to the proper meaning of KDE if not by using the prefix consistently? MS Office is MS Office also on Mac, precisely: MS Office for Mac. If someone adds a nice integration[*] for Ubuntu or Gnome in a KDE Foo app, the app perhaps can be even called KDE Foo for Gnome, etc. I remember in KOffice time how frequently reviewers (quite naturally) called it KDE Office. 2c [*] At least I won't oppose Kexi integration on 3rd party desktops if this expands the current FOSS community. > > Ciao > -- > Luigi > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On 24 August 2015 at 20:48, Ivan Čukić wrote: > When I said part of Plasma, was aiming at KDE workspace, not part of > plasma-* package. I don't believe it will be popular amongst Gnome, > MINT, Elementary, etc. users, right? > > Just the same as Gnome Music will not be used by us. Oh why? I hoped we could aim high... outside of the ghetto in a niche. Why we have all the modularity and Qt-ifying of apps? > Ch > > On 24 August 2015 at 16:45, Luigi Toscano wrote: >> Ivan Čukić ha scritto: >>> +1 for snapshot >>> >>> It is a part of Plasma workspace (and possibly other friendly >>> workspaces), so I don't even see it as a problem if other applications >>> with the same name exist (the only thing I've checked is that debian >>> has no package named 'snapshot'). >> >> It's not part of Plasma (no need to be). >> >>> >>> If other projects can take names like Music, etc. i do not see why >>> this would not be acceptable. >> >> It does not mean we should follow (I personally don't like that pattern for >> names). >> >> Ciao >> -- >> Luigi >> >> ___ >> kde-community mailing list >> kde-community@kde.org >> https://mail.kde.org/mailman/listinfo/kde-community > > > > -- > Cheerio, > Ivan > > -- > While you were hanging yourself on someone else's words > Dying to believe in what you heard > I was staring straight into the shining sun > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Renaming KScreenGenie
On 24 August 2015 at 16:00, Luigi Toscano wrote: > Jaroslaw Staniek ha scritto: >> On 24 August 2015 at 15:53, Martin Klapetek >> wrote: >>> On Mon, Aug 24, 2015 at 9:24 AM, Boudhayan Gupta wrote: >>>> >>>> On 24 August 2015 at 18:45, Martin Klapetek >>>> wrote: >>>>> KSnapshot2. >>>> >>>> One of the points brought up was that KDE Applications are moving away >>>> from using a K-prefixed name, so I want to ride that bandwagon. >>> >>> >>> My other suggestion would then be Snapshot. Keeps it simple and >>> recognizable, >>> kinda tied to KSnapshot even, no need for the fancy/cryptic names, I'd say. >>> >> >> +1 >> >> If KSnapshot is going to be abandoned why to loose the great privilege >> to use the Snapshot name. > > If there are other "Snapshot" applications around, it's a no-go. KDE Screenshot Utility (c) 1997-... For me it was around earlier and we, as the community, had the K prefix for the same purpose others has Microsoft or Oracle but just harder to understand/pronounce. But here the maintainer has more to say. To me there's a lot of sense in Snapshot, the same sense that made let us to introduce some new names for Calligra. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community