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 that? >>> >>> This is the one you reviewed https:
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 <ly...@kde.org> wrote: > On Mon, Apr 30, 2018 at 10:41 PM Jaroslaw Staniek <stan...@kde.org> 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 4 April 2018 at 12:37, Ben Cooksley <bcooks...@kde.org> wrote: > On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek <stan...@kde.org> wrote: > > > > > > On 3 April 2018 at 10:17, Ben Cooksley <bcooks...@kde.org> wrote: > >> > >> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <stan...@kde.org> > wrote: > >> > > >> > > >> > On 2 April 2018 at 22:56, Lydia Pintscher <ly...@kde.org> wrote: > >> >> > >> >> Hey Jaroslaw :) > >> >> > >> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <stan...@kde.org> > >> >> 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=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 sta
Re: Telemetry Policy - Remaining Questions
On 3 April 2018 at 10:42, Volker Krause <vkra...@kde.org> 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 <stan...@kde.org> > 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= > > > 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 <bcooks...@kde.org> wrote: > On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <stan...@kde.org> wrote: > > > > > > On 2 April 2018 at 22:56, Lydia Pintscher <ly...@kde.org> wrote: > >> > >> Hey Jaroslaw :) > >> > >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <stan...@kde.org> > 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=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 agree o
Re: Telemetry Policy - Remaining Questions
On 2 April 2018 at 22:56, Lydia Pintscher <ly...@kde.org> wrote: > Hey Jaroslaw :) > > On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <stan...@kde.org> 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=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 <ly...@kde.org> 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 <vkra...@kde.org> 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=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 <starb...@netrunner-os.com> 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 <b...@valdyas.org> >>> 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=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 <b...@valdyas.org> 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: Telemetry Policy - Remaining Questions
On 31 October 2017 at 11:56, Sebastian Kügler <se...@kde.org> 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 <vkra...@kde.org> 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 <oliv...@churlaud.com> 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 <stan...@kde.org> a > écrit : >> >> On 10 October 2017 at 21:48, Olivier Churlaud <oliv...@churlaud.com> >> wrote: >>> >>> Hi >>> >>> Le lundi 9 octobre 2017, 21:56:42 CEST Jaroslaw Staniek a écrit : >>>> >>>> On 9 October 2017 at 21:49, Olivier Churlaud <oliv...@churlaud.com> >>>> 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=Special%3ASearch=1 >> >>> Cheers, >>> Olivier >>>>> >>>>> Le 8 oct. 2017 à 21:29, Jaroslaw Staniek <stan...@kde.org> a écrit : >>>>> >>>>> On Sunday, 8 October 2017, Olivier Churlaud <oliv...@churlaud.com> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I wanted to share with you that I added a page for KDE talks and >>>>>>
Re: Added a resources page on community.ko
On 9 October 2017 at 21:49, Olivier Churlaud <oliv...@churlaud.com> 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 <stan...@kde.org> a écrit : > > > > On Sunday, 8 October 2017, Olivier Churlaud <oliv...@churlaud.com> 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 <oliv...@churlaud.com> 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 <nicolas.alva...@gmail.com> wrote: > >> El 24 ago 2017, a las 07:41, Jaroslaw Staniek <stan...@kde.org> escribió: >> >>> On 24 August 2017 at 11:10, Adriaan de Groot <gr...@kde.org> 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 <gr...@kde.org> 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=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 <vkra...@kde.org> wrote: > On Friday, 18 August 2017 11:23:49 CEST Jaroslaw Staniek wrote: > > On 17 August 2017 at 16:19, Volker Krause <vkra...@kde.org> wrote: > > > On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote: > > > > On 16 August 2017 at 18:56, Volker Krause <vkra...@kde.org> wrote: > > > > > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > > > > > On 16 August 2017 at 14:13, Volker Krause <vkra...@kde.org> > 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 t
Re: Telemetry Policy
On 17 August 2017 at 16:19, Volker Krause <vkra...@kde.org> wrote: > On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote: > > On 16 August 2017 at 18:56, Volker Krause <vkra...@kde.org> wrote: > > > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > > > On 16 August 2017 at 14:13, Volker Krause <vkra...@kde.org> 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 acceptable for our users
Re: Telemetry Policy
On 17 August 2017 at 18:20, Thomas Pfeiffer <thomas.pfeif...@kde.org> wrote: > > On 17. Aug 2017, at 17:38, Mirko Boehm - KDE <mi...@kde.org> wrote: > > Hi, > > On 17. Aug 2017, at 01:46, Thomas Pfeiffer <thomas.pfeif...@kde.org> > 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 <vkra...@kde.org> wrote: > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote: > > On 16 August 2017 at 14:13, Volker Krause <vkra...@kde.org> 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
Re: Telemetry Policy
On 16 August 2017 at 14:13, Volker Krause <vkra...@kde.org> 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 > > > > <christian.loo...@fuchsnet.ch> wrote: > > > Hi, > > > > > > thank you very much for this work, sounds great! > > > > > > Only point I have: maybe make sure that the opt-in / default settings > are > > > not only mandatory for application developers, but also for packagers / > > > distributions. > > > > > > Some distributions have rather questionable views on privacy and by > > > default > > > sent information to third parties, so I would feel much more safe if > they > > > weren't allowed (in theory) to flick the switch in their package by > > > default to "on" either. > > > > > > Kind regards, > > > > > > Christian > > > -- 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 <j...@jriddell.org> 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: state of release and release plan
On 27 October 2016 at 13:11, Friedrich W. H. Kossebau <kosse...@kde.org> 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 <m...@debian.org> 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 <nicolas.alva...@gmail.com> >> wrote: >> >>> 2016-09-30 6:31 GMT-03:00 Jaroslaw Staniek <stan...@kde.org>: >>> >> 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: KDE Licensing Policy Updates
On 20 September 2016 at 22:54, Thomas Pfeiffer <thomas.pfeif...@kde.org> 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 <nicolas.alva...@gmail.com> wrote: > 2016-09-20 16:53 GMT-03:00 Jaroslaw Staniek <stan...@kde.org>: > > > > > > 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 <stan...@kde.org>: > >> > > >> > > >> > 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 <j...@jriddell.org>: > >> >>>> > >> >>>> 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: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 <j...@jriddell.org>: >> >>> 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 <nos...@vuorela.dk> wrote: > On 2016-09-20, Jonathan Riddell <j...@jriddell.org> 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 <j...@vandenoever.info> 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 <j...@vandenoever.info> 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 <j...@vandenoever.info> 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
On 15 April 2016 at 14:01, Sebastian Kügler <se...@kde.org> 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 <kram...@kde.org> 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 <thomas.pfeif...@kde.org> 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 <j...@jriddell.org> 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 <luigi.tosc...@tiscali.it> wrote: > On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote: > > On 31 March 2016 at 17:13, Luigi Toscano <luigi.tosc...@tiscali.it> > 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=org%3AKDE+.appdata.xml=Code=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 <luigi.tosc...@tiscali.it> 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=138348776618380=2
> http://marc.info/?l=kde-core-devel=138349411519937=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 <kloec...@kde.org> 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 <neund...@kde.org> 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" <neund...@kde.org> 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 <a...@alexdymo.com> wrote: > On Mon, Feb 15, 2016 at 7:51 AM, A. Spehr <sp...@kde.org> 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 <kloec...@kde.org> 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 <mgraess...@kde.org> 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 <bcooks...@kde.org> 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 <neund...@kde.org> 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:01, Martin Graesslin <mgraess...@kde.org> wrote: > On Wednesday, February 3, 2016 10:46:26 AM CET Nicolás Alvarez wrote: > > > On Feb 3, 2016, at 10:16, Martin Graesslin <mgraess...@kde.org> wrote: > > > > > > On Wednesday, February 3, 2016 9:44:13 AM CET Nicolás Alvarez wrote: > > >>>> On Feb 1, 2016, at 15:31, Cornelius Schumacher <schumac...@kde.org> > > >>>> 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 with the > state of our software in distros.
Re: [kde-community] RFC: Distribution outreach program
On 3 February 2016 at 15:15, Martin Graesslin <mgraess...@kde.org> 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 <mgraess...@kde.org> > 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] Wikis uneditable
On 2 February 2016 at 08:51, Ben Cooksley <bcooks...@kde.org> 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ć <ivan.cu...@kde.org> 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
On 29 September 2015 at 07:31, Martin Graesslin <mgraess...@kde.org> 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] 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 <bcooks...@kde.org> wrote:
> On Tue, Sep 29, 2015 at 10:20 PM, Jaroslaw Staniek <stan...@kde.org> wrote:
>> On 29 September 2015 at 10:30, Lydia Pintscher <ly...@kde.org> wrote:
>>> On Tue, Sep 29, 2015 at 9:02 AM, Jaroslaw Staniek <stan...@kde.org> 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 <ly...@kde.org> wrote:
> On Tue, Sep 29, 2015 at 9:02 AM, Jaroslaw Staniek <stan...@kde.org> 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
[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 13:15, Riccardo Iaconelli <ricca...@kde.org> 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] Official KDE mirror on github in the light of the KDE manifesto
On 25 September 2015 at 23:33, Albert Astals Cid <aa...@kde.org> 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 <ricca...@kde.org> 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] "Fork Me" button within the kde git infrastructure?
On 21 September 2015 at 02:30, David Narvaez <david.narv...@computer.org> wrote: > On Sun, Sep 20, 2015 at 7:57 PM, Jaroslaw Staniek <stan...@kde.org> 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 <mp...@kde.org> 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 <david.narv...@computer.org> wrote: > On Sun, Sep 20, 2015 at 4:11 PM, Jaroslaw Staniek <stan...@kde.org> 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
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On 19 September 2015 at 21:08, Eike Hein <h...@kde.org> 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] Bikeshedding - our strength apparently *sigh*
On 19 September 2015 at 21:24, Ivan Čukić <ivan.cu...@kde.org> 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] What is a GitHub pull request exactly?
On 19 September 2015 at 23:06, Eike Hein <h...@kde.org> 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] Official KDE mirror on github
On Saturday, 19 September 2015, Albert Astals Cid <aa...@kde.org> 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 <mgraess...@kde.org> 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] Official KDE mirror on github
On 19 September 2015 at 17:36, Riccardo Iaconelli <ricca...@kde.org> 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 18 September 2015 at 14:17, Ben Cooksley <bcooks...@kde.org> wrote: > On Sat, Sep 19, 2015 at 12:14 AM, Jaroslaw Staniek <stan...@kde.org> wrote: >> On 18 September 2015 at 14:00, Ben Cooksley <bcooks...@kde.org> wrote: >>> On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <stan...@kde.org> wrote: >>>> On 18 September 2015 at 13:42, Boudhayan Gupta <bgu...@kde.org> 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 21:16, Marco Martin <notm...@gmail.com> wrote: > On Fri, Sep 18, 2015 at 9:12 PM, Sune Vuorela <nos...@vuorela.dk> 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] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)
On 18 September 2015 at 23:15, Ivan Čukić <ivan.cu...@kde.org> 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] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)
On 18 September 2015 at 22:37, Ben Cooksley <bcooks...@kde.org> wrote: > On Sat, Sep 19, 2015 at 8:10 AM, Friedrich W. H. Kossebau > <kosse...@kde.org> 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:55, Andre Heinecke <aheine...@intevation.de> 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 people willing to help with a simple thing of pasting a patch into phabricator. Writing a patch is quite more expensive so if it la
Re: [kde-community] Official KDE mirror on github
On 18 September 2015 at 13:42, Boudhayan Gupta <bgu...@kde.org> 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 > <da...@davidedmundson.co.uk> wrote: >> >> >> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth <vonr...@kde.org> 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 18 September 2015 at 14:00, Ben Cooksley <bcooks...@kde.org> wrote: > On Fri, Sep 18, 2015 at 11:54 PM, Jaroslaw Staniek <stan...@kde.org> wrote: >> On 18 September 2015 at 13:42, Boudhayan Gupta <bgu...@kde.org> 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 >>> <da...@davidedmundson.co.uk> wrote: >>>> >>>> >>>> On Thu, Sep 17, 2015 at 1:12 PM, Patrick von Reth <vonr...@kde.org> 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] Phabricator: Make it happen already!
+1 (I am using it as if it was official) On 26 August 2015 at 20:05, Kevin Ottens er...@kde.org 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] stackexange site for krita
On 27 February 2015 at 01:39, Albert Astals Cid aa...@kde.org wrote: El Dijous, 26 de febrer de 2015, a les 11:56:15, Jaroslaw Staniek va escriure: On 26 February 2015 at 10:56, jQM Consultant jqmconsult...@gmail.com wrote: [..] Having a micro-community inside a macro-community will have a negative impact on the micro-community. You won't have your own rules nor will you have your own personality (as a community). While we're looking for optimized forum/QA experience for sub-communities, this reminds me similar question: Krita (or Kexi, for the record) forum(s) dive in the large KDE forums family. It's easy to get lost. Do you think the above note, usability-wise, also applies to forum.kde.org? Would own forum instances, still managed by KDE admins, be better? More controversial note is also: it's not necessarily natural for majority of their non-contributing users (Krita, Kexi) being outside of the KDE Plasma orbit, to visit and contribute to KDE [community] forums. In best case they may see themselves rather as a part of a standalone application's community. Just like Angry Birds fans do not call themselves iOS/Android community. Are you saying Kexi users are not smart enough to differentiate subforums in a bigger forum? Do they get confused because the kexi forum is part of a bigger thing? Honestly I'd say the IQ needed to use Kexi is bigger that the IQ needed to understand subforums inside a bigger forum. I completely disagree. Don't make them think :) [tm] -- 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] stackexange site for krita
On 26 February 2015 at 13:27, Dweeble dweeble01...@gmail.com wrote: On Thu, 26 Feb 2015 06:36:48 -0500, Laszlo Papp lp...@kde.org wrote: On Thu, Feb 26, 2015 at 11:32 AM, Martin Klapetek martin.klape...@gmail.com wrote: Anyone btw. knows how the Ubuntu instance at askubuntu.com fits in? It is part of the Stack Exchange system. You can easily check it by going to a Stack Exchange account that has subaccounts on multiple sites including AU. The subdomains are listed at the top of left an account. Furthermore, the Stack Exchange logo is even in the banner on the top left of the cover page for AU. I wonder if it is hosted by Canonical or just by SE Inc. and running on its own domain...and if Ubuntu people got more power in the moderation and stuff. Well, surely, they are slightly more empowered on a separate site, but in the end of the day, as Omar also wrote, the big boss is Stack Exchange. I want KDE to be the big boss for a KDE project. I really do not want to compromise that. Cheers -- Martin Klapetek | KDE Developer ___ 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 I don't see where this is so much better than what exists - to me it looks like a forum without sub-forums, where (at least on the LO and Ubuntu sites) not that many people vote and answers are basically posts. And surprisingly considering the size of the Ubuntu community there aren't as many answers as I would have expected. I would think making the existing facilities better would be more cost/labor efficient and imo and what would be a worthy goal in supporting the community would be is to provide responses to all questions asked on the Forum, if one looks at the number of unanswered questions that number should not be considered acceptable. Yeah, one example: search that actually works. On https://forum.kde.org/kexi when I type TABLE I get results for Amarok, KMail, Okular, even VDG. Maybe 3 for Kexi. People search, do not browse, especially if they're confronted with a large hierarchy. Isn't that an idea for GSoC or whatever action? -- 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] retiring unmaintained modules?
On 11 January 2015 at 00:00, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 10 de gener de 2015, a les 23:37:30, Rick Timmis va escriure: Hi Text idea below On Sat, 10 Jan 2015 23:13:20 +0100, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 10 de gener de 2015, a les 22:56:06, Boudewijn Rempt va escriure: On Sat, 10 Jan 2015, Albert Astals Cid wrote: Some of them like kword and koffice are already in unmaintained and closed for bugs, not much more we can do with them other than deleting them which i'm not sure it's a good idea. Close the bugs as unmaintained? There's no reason to keep bugs open for dead projects. In an ideal world you'd have biliions of bug triagers that would go through all the open bugs and move the ones that still exist to calligra for example (meaning i think there's still some sense to keep them there) Others like kftpgrabber may be either suggested for new people to adopt them and if not moved to unmaintained. I don't believe in that -- asking for maintainers never works. It's vanishingly rare that an unmaintained project gets a new lease of life, and it never happens if there's no maintainer around anymore to answer questions. I don't believe in things you belieave and vice-versa ;) I guess we should also be really careful, as you said some software is done and the fact that it didn't get any development doesn't mean it should be killed. Of course. But kmail (not kmail2) is _dead_. It's bugs should be closed. It's silly to see it cluttering up bugzilla's weekly top-twenty stats. Same as before, ideally we'd have someone going over the bugs and deciding what still happens and what still not and move over to kmail2. Now one way of doing this is crowdsourcing it to the reporters via a nice bug closing email for every of the unmaintained bugs/apps. In one hand it always pisses me a bit off when that happens (i.e. i reported a bug and the only acknowledgement i get is years later saying that it was against an unmaintained version that i should re-check), in the other if someone is able to write a nice text it may not be so bad. I like this idea... possible text It's nice. We would need another version for those bugs that belong to products that have other products the bug may apply to, say kmail - kmail2, kword - calligrawords, etc. When Calligra appeared bugs have been copied from KOffice for duplicated apps -- IIRC. Or not? -- 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 office (was: Your KDE highlight of 2014?)
Hi. Let's put a nice KDE Community logo on the doors, done. After all we're educating rest of the world what KDE means, this is one more opportunity to do that. Happy Holidays. On 29 December 2014 at 13:43, Mirko Boehm mi...@kde.org wrote: Hi, On 28 Dec 2014, at 09:21, Aaron J. Seigo ase...@kde.org wrote: On Thursday, December 25, 2014 00.15:25 Jonathan Riddell wrote: Um, what? You don't want KDE to work on KDE project together and call it KDE? Call the result KDE software, call your efforts part of KDE, but putting KDE on an office door and calling it a KDE office creates a level of responsibility on behalf of KDE and anything that may happen in that office reflect on KDE. If there is some process for setting up such a space such that it meets the shared principles of KDE and is managed in a responsible fashion, then it can work. Random people randomly setting up physical spaces that are KDE is simply risky. You may be fine with that. I would caution against it. I would not put too much worry into this. Having too many people that are over-eager to build and expand our community and it’s presence is probably the least of our worries. If a significant portion of commits are coming from that room, why wouldn’t it be a KDE office? :-) Happy holidays, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist Request a meeting: https://doodle.com/mirkoboehm ___ 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 fundraisers and things we've learned
On 23 December 2014 at 21:45, Boudewijn Rempt b...@valdyas.org wrote: On Tue, 23 Dec 2014, Jaroslaw Staniek wrote: We had opportunity to learn about the positive example of Krita. I don't extrapolate to other projects. Fundraising for *single* sub-project is a part time job alone or two, with incredibly intelligent people knowing the domain (art), with project's brand present at conference booths. Most likely for large apps we need business partners for that to happen (Krita had one), to get them we need ability to align to their needs, whatever that means in every specific case. Well, KO GmbH wasn't involved with the Krita fundraiser at all -- that was purely a volunteer effort in the Krita community. When we're out of the 2.9 crunch, we'll have to do another one, work on that will start in January, and we really should go live with it in March. Strictly speaking, true, but what I mean: KO in this case were the enablers. Krita was a quite widely used and finished app prior to the fundraising efforts. So risks of Catch-22 situations like these were reduced: [User] I'll start using your product and maybe even support you if you a add feature FOO; [Dev] We have this fundraising exactly for the feature FOO. [User] -EINVAL The topics will be animation, osx, python scripting and making krita faster than photoshop, I expect. Cool to see this phase... -- 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] Your KDE highlight of 2014?
On 19 December 2014 at 11:08, Lydia Pintscher ly...@kde.org wrote: 2014 is coming to an end. This gives us some time for reflection. What are your KDE highlights of 2014? A team that kicked ass? A really good release? An event where you made great new friends? Something entirely different? My personal highlight of 2014 is that we have an amazing visual design and usability team that really gets what KDE is all about and makes our software look great and ready for many more users. Spending some powers on cooperation with Visual Design Group is refreshing; many new members of Kexi Team includes hyperactive non-coders; realization (backed by real data) that the Plasma shell can be a small fraction of places where a KDE app is used; back to Akademy! Thanks. -- 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] Give People Access to Great Technology - a possible vision
and transfer files/library * Stream music/video between device and desktop * Send desktop audio to bluetooth speakers * Send desktop video to TV (e.g. chromecast) * Device as additional input or display (e.g. games, touchscreen-as-touchpad, device sensors like microphone, accelerometer, gyroscope, ambient light sensor, etc.) * Remote access to desktop capabilities and services * More? * Many of these examples are already in KDE Connect and may well be on its (or others’) road map to build deep, powerful desktop-wide integration. * Highly capable integration with cloud services * Don’t just duplicate. Make it better. * Examples: * Synced offline email, contacts, calendar * Beyond-the-desktop search/query (App repositories, OpenStreetMap, TVDB, MovieDB, Last.fm, DBpedia, dictionary, translation) * Integrated map/directions to contact address * More discoverable cloud file storage, browsing and syncing * Web apps as first-class applications on the desktop * (Properly) Integrated social network contact, group and event info * Sharing to social networks from anywhere * Easier sharing of customizations. * Group text/video chat * In-app collaboration * App-driven usability metrics and surveys * Remote git-based workflows * Seamlessly access and play cloud-stored music in my desktop music player * Synched media activity (ratings, play count, times, etc.) * More? * Many of these examples we already have in place, are working on, or have the basics in place to build deeper, even more powerful desktop-wide integration. These include Kontact, dictionary and translate runners and plasmoids, Marble, KIO, web view plasmoid, KPeople +WebAccounts, Share-Like-Connect, KTE Collaborative, Amarok, Tomahawk and more. * Quality * Applicable to design, code, documentation and translations. * Pride of workmanship. Encourages adoption. Encourages contribution. Collapsed down to 5 top-level items for conciseness: Desktop at the center. Frameworks as enabler. Highly capable integrated applications. Highly capable integration with devices and the cloud. Quality. So, how might we preserve what has already been accomplished and tackle what comes next? Here is my personal interpretation of Cornelius Schumacher's advice from his keynote. * Be free * Bias support towards free-er platforms * Bias support towards open standards. Open standards lead to free-er platforms. * But don’t be shy about supporting people (us) where their (our) ecosystem is. Taking advantage of existing platforms may have a significant impact to people who stand to benefit most. It may also help to form the foundations upon which to create and support open standards and free-er platforms of the future with greater capability. Knowing the greater goal is crucial, but effective strategy (correctness*commitment) is what moves us toward that goal. * Bias towards working in the open to encourage participation and preserve sustainability. * Maintain our purpose * Give people access to great technology. * By our own users’ measure, we make a fantastic desktop environment and applications. We can do even better by giving people access to the greater capabilities of a technological ecosystem that includes the desktop and applications as full-fledged, relevant and highly capable participants that can make other elements in that ecosystem better. * Have fun * We get to participate in the exciting new and emerging elements of our technological ecosystem. * We make the best desktop environment and applications even kooler! There are probably a million holes to poke through this. Maybe it’s too ambitious. Maybe it’s much too limited. Maybe it’s entirely the wrong focus. Ultimately, it’s fine if we end up choosing a different approach than the one considered here. The hope though is for a clear, unambiguous focus that acknowledges our strengths as well as the reality of the trends in our technological ecosystem. I just wanted to share this collection of thoughts that have been festering in mah noggin since Akademy in the hopes it might be helpful to a community I’ve come to treasure. Hope this helpful and I'm genuinely happy to be a part of such an amazing community, Andrew Lake KDE VDG member -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] Sad news (fwd)
On 28 August 2014 08:15, Jens Reuterberg j...@ohyran.se wrote: That is a good point, Boud would probably be able to get a hold of the guys friend (who wrote on the Calligra list on his behalf) just to check in and make sure we don't do something they'd rather not see. Hi All, As I am preparing the announcement, I'd like to ask if there's go ahead so we dedicate Calligra 2.8.6 to Mojtaba and write a paragraph in this Wednesday release announcement. Or 2.9.0? which is planned in 3 months, what would make sense better for you? On 26 August 2014 18:04, Mehrdad Momeny mehrdad.mom...@gmail.com wrote: Hi Calligra developers, I hope you are all fine. I guess some of you should know Mojtaba Shahi, He was working on some parts of Calligra as I know. I have a really sad news for those of you, it's yet unbelievable for myself. Mojtaba has passed away some days ago due to a brain stroke. Today was his burial in his hometown, Mashhad. May his soul rest in peace now. On Wednesday 27 August 2014 22.03.34 Valorie Zimmerman wrote: Jens, I think that would be lovely. It is so hard to lose a member of the community. And to lose a young person, who would otherwise have a long career ahead of them, feels tragic. I would like to see a respectful Dot story, and some nice memories on blogs as well. And a named Calligra release seems perfect. Does anyone have contact with the family, to be sure that this attention to their loved one is welcome? Valorie On Wed, Aug 27, 2014 at 8:54 AM, Jens j...@ohyran.se wrote: +1 Moji or Mojtaba release sounds nice - should I do a black web banner or something that we can add to our respective blogs? Just to show some respect for someone who contributed to something that benefit us all. On Wednesday 27 August 2014 12.14.48 Thomas Pfeiffer wrote: On Wednesday 27 August 2014 09:00:04 Jens Reuterberg wrote: Thats terrible news. As a community would it be appropriate to write up a short retrospective of Mojtaba? Perhaps combined with a photo, some information about him, his work and his life and post it on one of the larger KDE blogs? I don't know how Iranian burial customs work and we should check in with his family and friends (Mehrdad perhaps if you could help out) but with their allowance it seems as a nice gesture to do towards someone who has been a part of our community as well as worked on things that benefit us all (beyond our own community). What do everyone else think? When community member Claire Lotion passed away in 2012, there was a Dot story ( https://dot.kde.org/2012/05/20/remembering-claire-lotion ) and the KDE SC 4.9 release was dedicated to her memory ( http://www.kde.org/announcements/4.9/ ). Chakra followed suit and named their KDE SC 4.9 release series Chakra Claire. Maybe dedicating a Calligra release to Mojtaba would make more sense than a KDE SC release because Calligra was his focus, but a dot story would surely be due. ___ 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 / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] kde.sexy...
Off topic: Do you know this page? http://kde.sexy -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] Sad news (fwd)
On 26 August 2014 19:18, Jos van den Oever j...@vandenoever.info wrote: This is very sad news indeed. Mehrdad, I am sad for you and Mehrdads family and friends and for the Calligra community. Here is a lovely quote from his blog which I think is very inspiring: my day is a good day if i do something in calligra http://shahimoji.wordpress.com/ Mojtaba was, is, one of us. I remember the quote too, for me it describes him as one of us. Mehrdad, my condolences to you and the family. -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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 change of heart
+1 for Reply-By-Email! Forum.kde.org's anonymous notification can depress users that are AFK... On 25 August 2014 13:53, David Wright david.wright12...@gmail.com wrote: I did send this originally to the kde-www address but I thought I'd send it here as well for a bit of fun. Kind regards, David -- Forwarded message -- From: david.wright12...@gmail.com Date: 17 Aug 2014 00:24 Subject: A change of heart To: kde-www kde-...@kde.org Cc: Hi guys, I've been doing a bit of research lately on CMS's and stumbled across http://commonsinabox.org/ which is basically a bundled buddypress plugin which powers http://commons.gc.cuny.edu/ amogest other. Given the social nature of this setup, and the fact it is built upon wordpress (it is basically a set of wordpress plugins that have been tested together), I felt that this might be something that KDE might like to take under consideration? A standard install would include forums, groups, collaborative docs, social @ mentions, user profiles etc, etc. Also, using the multi user aspect of wordpress it would still allow certain projects to keep their identity, but remain under the networks umbrella, as evidenced by: http://helpwanted.commons.gc.cuny.edu/ Naturally, being exposed then to the wordpress plugin ecosphere would allow then a better integrated events management, job board, even a store if desired. Ultimately though, the goal is to increase funding. The KDE websphere is too spread out, and this would help reign it in so we can really do focused funding campaigns on users. That would be the advantage of the groups, as we could tailor funding drives to particular interests and hopefully have better success. Administration might also be made easier as we could get rid of a fair few subdomains by moving to this kind of platform. Anyway, it's late, and I'm jabbering. Let me know what you think! :-) ps There is also a buddypress app that could be rebranded: https://github.com/yuttadhammo/buddydroid Mozilla were also working on bugzilla intergration a while back: https://bugzilla.mozilla.org/show_bug.cgi?id=643570 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] Proposal One: KDE (Core) Apps and Suites
On 22 April 2014 11:31, Mario Fux kde...@unormal.org wrote: Proposal: Reduce the amount of KDE Core Apps according to a definition and release the other apps in independent groups or suites like e.g. KDE Edu, KDE Games, KDE PIM, Amarok or the Calligra Suite. Details: We could decide on a group of KDE Core Apps (for the Desktop) based on a definition like this: - Allows you to manage your files and documents (e.g. = Dolphin, Ark, K3b?) - Allows you to view documents and pictures (e.g. = Okular and Gwenview) - Allows you to watch movies and listen to music (e.g. = Dragon and Juk) - Allows you to administrate and manage your system (e.g. = print-manager, ksane, systemsettings) - Allows you to do this in an accessible way*: (e.g. = Simon, Jovie and Co) - Allows you to write some notes and find them again (e.g. = Kate/Kwrite) One note, I would not call Kate as core app. It rather belongs to a Specialized Apps group (with KDevelop, Konsole and... Kexi for example). Anyone unconvinced can look at, say, Kate's Tools menu :) So my idea could be to start from optics of basic user, discovering personas, their goals or needs, and then realistic groups would appear naturally. BTW, does even Core Apps sound fine for the basic user? -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] Windows licenses
On 24 January 2014 21:01, Laszlo Papp lp...@kde.org wrote: On Wed, Jan 22, 2014 at 8:19 AM, Patrick von Reth patr...@von-reth.de wrote: In my experience it is no problem having mingw and msvc setup on one system, you probably don't want to compile with both all the time but the system will handle it quite fine Unfortunately Stack Overflow and the Windows forum are full of interoperability issues. Laszlo, I have no clear idea what you're talking about. Obviously various compilers are not compatible. And definitely debugging formats. Sounds good that you had no issues though. I am envy. :-) For pacman: pacman is as far as I know only part of msys2 , and quite useful there to install dev tools etc, but it is of no use for us, as we don't want users to install msys to install kde. Yes, but we do not want end users to install emerge, etc, either. :-) In other words: it can be managed without ithese helper softwares n my opinion. So also without pacman and archlinux that you mentioned before. End-user software do not require compilation, compilers, shells and so on. Depending on how active is given project, standalone installers can be an option, see the case of Krita for example. Unless you've found a *big* sponsor, with guaranteed dedication, KDE package managing for windows took years already and it works. It works, do not touch please. Kudos to the team. and we don't want to develop stuff inside of msys. I am personally very much interested in getting that workflow forward. I think it could be nice to get everything done properly for KDE development. Consider that the KDE Arch developer nicely built up frameworks development packages. I think it would cool to get them ported over and share some work with a Linux distribution in that sense. Please do not get me wrong. I am not saying emerge would not remain useful. It is all about personal choice I guess. :) -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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] Qt Community partner
On 18 September 2013 15:43, Claudia Rauch ra...@kde.org wrote: On 18 September 2013 15:24, Jaroslaw Staniek stan...@kde.org wrote: Hi Claudia, Attached re-worked HTML that's relevant to Calligra. Some of that is a simple replacing KOffice-Calligra. I hope the quote from Boudewijn still applies to Calligra and can be put this way. Calligra folks and others, please comment and improve if possible :) Other changes: more recent screenshots, updated app names, Coffice screenshot for Android replaced maemo's KOffice, new Krita video from David Revoy. Great, thanks, Jaroslaw! Let me know when this is final. Hi Claudia, I see no other feedback. Please consider this as final already. I am sorry for delay. On 10 September 2013 10:38, Claudia Rauch ra...@kde.org wrote: On 9 September 2013 22:33, Jaroslaw Staniek stan...@kde.org wrote: By the way, Jos All, I am looking for a Digia contact so we can send updated content for [1]. As you see it stills explains KOffice. Perhaps someone would like to refresh the KDE 4 part too? Thanks for the pointer. I have a call with Digia about the partner program next week and will ask them to change it. Any suggestions for an updated text are welcome :) [1] http://qt.digia.com/Product/Qt-in-Action/KDE-and-KOffice/ On 5 September 2013 09:36, Jos Poortvliet jospoortvl...@gmail.com wrote: On Wednesday 04 September 2013 16:09:08 Cornelius Schumacher wrote: On Wednesday 04 September 2013 00:35:41 Aleix Pol wrote: I don't really understand how can it happen that Digia has a community program around Qt and we don't know about it... What am I missing? The partnership program was presented at the DevDays last year and some KDE people were there. So it's not that we know nothing. That doesn't mean that the communication around it can't be improved. From our point of view, I would just take it from where we are and get involved. Ok, will talk to them. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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 -- Claudia Rauch Business Manager KDE e.V. Linienstr. 141 10115 Berlin Germany Phone: +49 (0) 30 2023 7305 0 Fax: +49 (0) 30 2023 7305 9 Mobile: +49 178 522 3086 Twitter: @frankfurtine KDE e.V. is a German Verein registered at the Amtsgericht Berlin (Charlottenburg), with number VR 31685 B. Its president is Cornelius Schumacher. For more information please see http://ev.kde.org, and http://kde.org/ ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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 -- Claudia Rauch Business Manager KDE e.V. Schönhauser Allee 6/7 10119 Berlin Germany Phone: +49 (0) 30 2023 7305 0 Fax: +49 (0) 30 2023 7305 9 Mobile: +49 178 522 3086 Twitter: @frankfurtine KDE e.V. is a German Verein registered at the Amtsgericht Berlin (Charlottenburg), with number VR 31685 B. Its president is Cornelius Schumacher. For more information please see http://ev.kde.org, and http://kde.org/ ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen 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
