Re: Proposal for using gitlab for kdereview process
Long time ago, but perhaps there are still memories... Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell: > I've gone ahead an updated the Sanity checklist Having come across the checklist items * Passing KDE neon build * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate I tried to understand the background & motivation, but only found this "I've gone ahead an updated" here and the diff from your edit on 4 July 2023: https://community.kde.org/index.php? title=ReleasingSoftware&diff=next&oldid=97120 I assume this was the result of some community discussion. If so I failed to witness and now fail to find it. Could you help me to get more insight into the previous discussion here? Cheers Friedrich
Re: What can we expect from our developers
Am Montag, 29. Januar 2024, 10:38:11 CET schrieb Sune Vuorela: > On 2024-01-29, Jonathan Riddell wrote: > > This sort of comment makes me really sad. The All About the Apps goal, > > which in principle is still ongoing, was an attempt to get KDE developers > > to realise it was important not just to write apps but to actually make > > them available to users, I find it astonishing how we still don't have a > > culture where making our apps available to users is part of our > > responsibility. There's teams in KDE to help with all these formats. > > Sorry to complain here as the issue is larger than just this one app but > > it's so sad that nobody within KDE wants to help get users using our > > software directly. > > I think this is taking it too far. I think the goal is more about not > getting in the way of people who wants to do this. What Sune says. I am sorry to be among those saddening you by not living up to your hopes. To share you my perspective, for me almost all of these platforms are the same challenge as I face with localizations: I do not speak the "language" or live the "culture", thus cannot do anything effectively there to properly integrate the artifact generated from the sources written. I have only x leisure time to spend, so I spend it on the things I feel I understand & can responsibly create proper results at. And leave it to the domain experts to do what is needed or useful in their field. Like translators, to localize things for a given locale. Or packagers, to generate the binary blobs which work on a given platform. Or sysadmin, to maintain and run the environment which only enables us to work on software here in this place. Next, making apps available to users on their platforms also means supporting them there. Which again needs proper clue (and access to those platforms) to be effective with the given resources one can take from ones capabilities. I am sharing the result of my developing efforts here as sources, by a very grateful license which also emphasizes the sources, not some platform specific binary blob. To allow those interested to make use of the product with their platforms of choices/realities, adapting and enhancing it where they want to their desires. Similar to making the software localizable, so those interested can make it fit their local culture. Likewise visual styles or other configuration options. Additionally: I think I understand where you are coming from, that all the work on software done here makes the more sense the more users there are. IMHO though reaching more users of Free Software should be done in ways and for platforms which are not giving more power to monopolists or those which seem set to become some. Flatpak, Snap, Windows, macOS... they are all about binaries. There is no simple way, part of the concept, to get the sources, patch something to one's likes and then regenerate the very same package, just as custom one. Or is there? Which makes the apps basically "free beer apps" for those users. Not the business I am here for. But again, packaging is not my domain anyway. Cheers Friedrich
Re: planet forwarding to discuss?
Am Mittwoch, 21. Juni 2023, 15:02:31 CEST schrieb Jonathan Riddell: > The downside is splitting where discussion happens but it's not a big ask > to expect KDE devs to visit Discuss at times. Am Mittwoch, 21. Juni 2023, 18:53:56 CEST schrieb Nate Graham: > probably nobody is actually expecting you or anyone else to participate there. Now what... ? Everything is true and false at the same time? :) > It seems like the people who have expressed negativity or apprehension > about the idea so far admit they don't use discuss.kde.org. And that's > fine. But my recommendation for those folks (yourself included) would be > to just continue ignoring it, because that's 100% okay and I fear the point did not made it across: if all planet blog posts would get a discussion thread on discuss.kde.org, there is chance comments intended to catch the attention of the author or other blog readers (at a later point) will fail to reach the audience. That is a change to now. One cannot ignore that. If considered "apprehension", why not respect that sentiment and act on it, instead of what comes across as dismissing? Please try to have the open mind to solve this e.g. by a flag to the planet blog registration metadata, if people would like to participate in that undertaking and have automatically also a discussion thread on a post. Or an opt-out if you think everyone by default should think this is an awesome thing to have. To state it explicitly: I am fine with and also curious (for reasons stated) to see if it works out for those who are interested. No objections (would be strange also) to have your and others' blog posts announced with discussion-enabled on discuss.kde.org But myself I do not spend time on discussion on dicuss.kde.org, also not reddit, twitter, *whatever* . And will not, given other things in life to do. So I am not happy to be "expected" to either have to use discuss.kde.org (as stated by at least one) or to miss out some comments to me or other blog post readers. Let's have solutions that work for everyone. That's also why people asked about this instead of just implementing something, right? Cheers Friedrich
Re: planet forwarding to discuss?
Am Mittwoch, 21. Juni 2023, 17:20:09 CEST schrieb Nate Graham: > On 6/21/23 16:57, Friedrich W. H. Kossebau wrote: > > Am Mittwoch, 21. Juni 2023, 16:20:21 CEST schrieb Nate Graham: > >> Regarding the topic of having comments split across multiple places, I'm > >> afraid that ship has sailed. I have comments on my blog, and the > >> discussion nevertheless gets split across Reddit, Mastodon, Phoronix, > >> and Discuss already. > > > > Isn't it a difference if a discussion happens at some external place or if > > it happens in some KDE place? People might rather expect the original > > post author around in a KDE one, no? > > The concern sounds quite theoretical and I'm not sure it's actually a > problem in practice. Have you had this experience in the past? It is as theoretic as the idea that people have been waiting to discuss blog posts on discuss.kde.org instead of general purpose sites they already have accounts for other things in their lifes. Not that many people circle just aronud "KDE". And actually not that theoretic concern, see below. > Speaking from personal experience as someone whose blog posts are > syndicated quite widely, I've never once run into the expectation that I > would be available for comment on the old forum.kde.org, or the new > discuss.kde.org. On the contrary, the only place I've experienced this > expectation has been on Reddit, which we don't have control over. Well... * blog posts had not been covered on forums.kde.org(?), so nothing to compare * discuss.kde.org is intended to replace kreddit? so expectations transferred? * "it's not a big ask to expect KDE devs to visit Discuss at times" in the very email that triggered my initial reply :) To summarize: please have that as an opt-in to invite people to discuss blog posts on discuss.kde.org. Friedrich
Re: planet forwarding to discuss?
Am Mittwoch, 21. Juni 2023, 16:20:21 CEST schrieb Nate Graham: > Regarding the topic of having comments split across multiple places, I'm > afraid that ship has sailed. I have comments on my blog, and the > discussion nevertheless gets split across Reddit, Mastodon, Phoronix, > and Discuss already. Isn't it a difference if a discussion happens at some external place or if it happens in some KDE place? People might rather expect the original post author around in a KDE one, no? Perhaps it could be only done for blog posts where authors/people opt-in to use discuss.kde.org for follow-up discussions. E.g. IIRC Kate blog posts have had decided to use kreddit as the central discussion/commenting place. And might consider perhaps to switch to discuss.kde.org instead (though will people follow? yet another account needed? yet another UI, yet another set of user names?) And there are discussions, and there are value-adding comments. IMHO social-clubbing discussions are fine to have elsewhere, but if people point out mistakes or have additional information, please let's not invite them to other seemingly KDE-officially places when the original blog post allows comments. So just because things are bad already, let's not make it worse for more people. Friedrich
Re: planet forwarding to discuss?
Am Mittwoch, 21. Juni 2023, 15:02:31 CEST schrieb Jonathan Riddell: > The downside is splitting where discussion happens but it's not a big ask > to expect KDE devs to visit Discuss at times. Being a developer, I think it is ;) There is only so much (leisure) time one can spent on writing code, reviewing MRs. dealing with bug reports, debugging code, being on online chat, discussing on developer mailing lists... Personally I never had time left for forums.kde.org, discuss.kde.org does not change that fact. If I write a blog post (actually doing this very minute ;) ) I would also fancy any reaction next to it, not somewhere else (also for people finding that blog post only later). An idea to just forward all commenters to discuss.kde.org as the single place, so linking to an external (and potentially one day also no longer existing/ working because the platform changed again) comment area is adding complexity, and half of post readers might not follow such links so miss comments adding value, also it might add burden when it needs yet another account for random commenters. So not a fan, would harm my own experience. Cheers Friedrich
Licensing questions for CMake code, example code & generated code
Hi, applying Andreas' license digger (tool to convert existing license headers to SPDX compliant headers. see https://invent.kde.org/sdk/licensedigger ) on some code resulted in some more reflections about the respective code and its current licenses, which could not immediately be resolved by looking at KDE's Licensing Policy ( https://community.kde.org/Policies/Licensing_Policy ). So to get help with those questions, I opened three respective tasks on phabricator, hoping that the usual suspects as well as others also with licensing knowledge could help resolve those, so the policy can be updated where needed: Clarify usage of BSD-3-Clause license with (CMake) code https://phabricator.kde.org/T13344 Recommended/required license for example code https://phabricator.kde.org/T13345 Recommended/required license for generated code https://phabricator.kde.org/T13346 TIA, Cheers Friedrich
Influence of infrastructure on development pace (was: Re: Import of personal repositories to Gitlab)
Hi Bernie, Am Sonntag, 21. Juni 2020, 14:03:23 CEST schrieb Bernie Innocenti: > On 21/06/2020 20.25, Bernie Innocenti wrote: > > I was arguing with a friend that the pace of development of KDE is > > accelerating thanks to various process and infrastructure improvements. Please also argue with him about how nice it is and what impression it leaves to others to hijack email threads and/or not adapting the subject line when doing so ;) > > My friend believes that it hasn't changed. Perhaps my perception is > > affected by Nate's awesome weekly updates giving wider visibility to > > changes. Who knows? > > > > If anyone is graphing things like commits, issues fixed, and other > > simple project health metrics, I'd be really curious to see if there are > > noticeable changes around major migrations such as Subversion -> git and > > Phabricator -> GitLab. > > Jonathan Corbet might have developed some cool data mining scripts to > help put together his periodic kernel statistics and his keynotes on the > state of kernel development. You might be also interested in https://framagit.org/ervin/ComDaAn (see https://chzn.fr/blog/tooling-for-community-data-analytics for an introduction). When it comes to older work in the KDE community about data-based introspection, Paul Adams (see also references in above links) some years ago made interesting related work, find traces in the web archive: https://web.archive.org/web/20160316102926/http://blogs.fsfe.org/padams/? tag=visualization Or see (sadly, listen is almost impossible) a talk given at Akademy: https://conf.kde.org/en/Akademy2014/public/events/167 But please, start a new own thread for this, thanks :) Cheers Friedrich
Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 05:11:31 CEST schrieb Nate Graham: > However I think there is a bigger challenge that just the technical > issues. My interactions in bug reports have been quite negative, I have > to say, and I don't feel like the developer culture is very welcoming > right now. It takes two to tango. I have not had negative experience with KDE PIM people. And Nate, if I saw you advocating to have my KDE software removed from KDE- centric distributions (even more when triggered because some proprietary- privacy-screwing service support being broken, is that what KDE is about?) like in https://phabricator.kde.org/T12486 , that would magically lower the quality of my interaction in bug reports with you as well. And no, this is not about who started. Please, let us keep this a community working together, not against each other, and one showing respect to each others efforts. All of Plasma, KDEPIM, KDevelop etc. pp. have lots of issues. We could be bitching about each others products all day long and where their developers have not instantly cared about our very important issues and our oh so very clever and well done solution/fixes/improvements, with all their politeness, spending all of their time just for us, or where we see them going wrong ways and how they fail to meet other products quality and features. He, one could use Gnome, Visual Studio Code, Thunderbird. etc. pp., who needs KDE!!1! I am missing what this email thread here should achieve, despite being demotivating for those whose product is talked about or even bad-mouthing them. We all know there are big and small flaws. Those get fixed by people working on them. Not by people showing off their knowledge that there are flaws. And I doubt the developers of the products do not know about the flaws. They just do not have the resources left to handle them, given resources are limited. And when you compare KDEPIM to Evolution and Thunderbird, you also want to compare the current resources behind. Which of those products has developers behind that work on them during paid jobs, not only in their leisure time? I am happy to be able to use KMail, all the years. If you want to help KDEPIM, but cannot become the needed qualified developer to help by being another resource yourself, see to make business plans instead to organize the needed resources to get more funded developers. If you also cannot do that, bad luck. World will not be improved by you. PIM is more complex given all the various data and service specifications and various buggy implementations of them which have to be handled to please user expectations. And you have to be able to also manage massive amounts of data without annoying the user by waiting times. It's not what your beginner/ amateur developer can easily do. KDEPIM thankfully still has some professional developers around who invest their leisure time now and then. I am thankful they do, so KDEPIM is not dead. From my few bug reports in the last months, some of them were fixed the other day or were already before. Cheers Friedrich
Re: Sysadmin Load Reduction: Subversion Infrastructure
Am Samstag, 9. November 2019, 21:22:16 CET schrieb Ben Cooksley: > On Sun, Nov 10, 2019 at 8:37 AM Albert Astals Cid wrote: > > El dissabte, 9 de novembre de 2019, a les 19:27:07 CET, Ben Cooksley va escriure: > > > On Sun, Nov 10, 2019 at 7:18 AM Alexander Potashev wrote: > > > > сб, 9 нояб. 2019 г. в 03:20, Ben Cooksley : > > > > > This would include the shutdown of WebSVN in particular, which when > > > > > coupled with the shutdown of our two CGit instances would also allow > > > > > for us to eliminate an entire virtual machine from our systems. > > > > > > > > Will there be any web interface for SVN after shutdown of WebSVN? > > > > > > > > Can we assume https://phabricator.kde.org/source/svn/ remains > > > > available during the next 10 years? > > > > > > Phabricator's browser will be retired as part of the shutdown of > > > Phabricator, which will take place once Gitlab has assumed > > > responsibility for code hosting and review, and the tasks have been > > > migrated from Phabricator. > > > > > > Should WebSVN be shutdown as well, then there would be no web > > > interface to our SVN repository. > > > > That's not acceptable. > > Mind explaining why? FWIW, everytime I had to deal with translations as developer (like checking pot files as well as .po files contents) I found having the web interface and its browsing feature very valuable to quickly find what I was looking for, over having to locally mess around with svn commands and juggling between commandline & file viewers. Including url bookmarks for quick access to browsing certain sets of files. Incidents which I remember right now included: * finding out whether extraction scripts were working as intended * comparing translations seen by users over what they should see Are there any other KDE clients of the svn repos still around, besides translation system? Perhaps the "full clone" needed for WebSVN could be reduced to the translation subtrees, would that improve situation to a degree if possible? (well, you surely thought of this yourself, just in case) For me as developer contributor to projects in KDE spheres, losing the web browsing interface for raw translation files would be a regression in developer experience. Cheers Friedrich
Re: Sysadmin Load Reduction: Subversion Infrastructure
Am Samstag, 9. November 2019, 21:35:47 CET schrieb Ben Cooksley: > On Sun, Nov 10, 2019 at 9:14 AM Friedrich W. H. Kossebau > > wrote: > > Am Samstag, 9. November 2019, 19:16:20 CET schrieb Ben Cooksley: > > > On Sun, Nov 10, 2019 at 6:04 AM Ingo Klöcker wrote: > > > > On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote: > > > > > On top of this, i'd also like to remove commit access to it for > > > > > everyone but translators and those who need to work on the small > > > > > number of websites remaining on Subversion and only provision this > > > > > for > > > > > people on an as-needed basis. > > > > > > > > > > In the next year or so i'd expect the remaining websites to complete > > > > > their migrations to Git, after which only translators would receive > > > > > access. > > > > > > > > Restricting access to the translations repository is against the > > > > letter of > > > > our manifesto which states > > > > "All source materials are hosted on infrastructure available to and > > > > writable by all KDE contributor accounts" > > > > https://manifesto.kde.org/commitments.html > > > > > > > > AFAIK, "all source materials" includes translations. > > > > > > > > There are a few reasonable exceptions for this requirement, e.g. for > > > > the > > > > sources of our websites, but I don't see a good reason for restricting > > > > access to the translations. > > > > > > > > I think restricting access to the translations will create a precedent > > > > for > > > > restricting access to other source materials and undermines the values > > > > stated in our manifesto. Therefore, I don't think we should go down > > > > this > > > > route. > > > > > > The access isn't being *restricted* at all. > > > It is just something you have to request be enabled separately, and it > > > won't be withheld from anyone with a developer account should they > > > feel they need it. > > > > This is a model we also see with rights to kick off build jobs on > > build.kde.org, and I think it does not work out: > > having to beg for access and having to wait for access being granted is an > > obstacle. > > Even more when this is nowhere documented, but a secret traded only in > > people's minds. > > As a general principle, filing a Sysadmin ticket has always been the > way to get access to systems (developer accounts being the only > exception), and the same applies to the CI system. Hence why there is > no explicit documentation around this. It stays an obstacle for everyone on first contact though. And makes one feel in begging position, when one should not, by ideas of the manifesto. And often enough one needs access _now_, instead of having to hope some sysadmin is around in the near time. > > So, by default there are de-facto restrictions experienced, and they get > > in > > the way of developer work-flows. > > It's a bit unusual that a lack of access to the CI system would impact > someone's workflow, as the CI system is supposed to automatically > trigger itself. > Do you have a specific scenario in mind here? The usual scenarios where one needs to manually trigger build jobs: a) build metadata changed (e.g. dependencies) b) builds failed for bko-internal issues c) branches changed, need manual first-run trigger All things normal developers want or need to do once in a while, if they care for their project on KDE CI. > > My 2 cent on this matter when it comes to conditions decided about. > > > > Otherwise, thanks for all the admin work you are doing here once again :) > > > > Cheers > > Friedrich, who only an hour ago had to help someone kicking off builds > > jobs on CI, as he once got the access granted after poking a few times > > informally... > Fortunately switching to Gitlab CI will resolve that specific scenario > (needing the DSL Job run when a release is being made) as the DSL Job > will be rendered unnecessary. "When a release is being made" should mean, when a new stabe branch has been created, I guess? That would be an improvement. Still leaves scenarios a) & b). Cheers Friedrich
Re: Sysadmin Load Reduction: Subversion Infrastructure
Am Samstag, 9. November 2019, 19:16:20 CET schrieb Ben Cooksley: > On Sun, Nov 10, 2019 at 6:04 AM Ingo Klöcker wrote: > > On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote: > > > On top of this, i'd also like to remove commit access to it for > > > everyone but translators and those who need to work on the small > > > number of websites remaining on Subversion and only provision this for > > > people on an as-needed basis. > > > > > > In the next year or so i'd expect the remaining websites to complete > > > their migrations to Git, after which only translators would receive > > > access. > > > > Restricting access to the translations repository is against the letter of > > our manifesto which states > > "All source materials are hosted on infrastructure available to and > > writable by all KDE contributor accounts" > > https://manifesto.kde.org/commitments.html > > > > AFAIK, "all source materials" includes translations. > > > > There are a few reasonable exceptions for this requirement, e.g. for the > > sources of our websites, but I don't see a good reason for restricting > > access to the translations. > > > > I think restricting access to the translations will create a precedent for > > restricting access to other source materials and undermines the values > > stated in our manifesto. Therefore, I don't think we should go down this > > route. > The access isn't being *restricted* at all. > It is just something you have to request be enabled separately, and it > won't be withheld from anyone with a developer account should they > feel they need it. This is a model we also see with rights to kick off build jobs on build.kde.org, and I think it does not work out: having to beg for access and having to wait for access being granted is an obstacle. Even more when this is nowhere documented, but a secret traded only in people's minds. So, by default there are de-facto restrictions experienced, and they get in the way of developer work-flows. My 2 cent on this matter when it comes to conditions decided about. Otherwise, thanks for all the admin work you are doing here once again :) Cheers Friedrich, who only an hour ago had to help someone kicking off builds jobs on CI, as he once got the access granted after poking a few times informally...
Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)
My last reply here due to getting OT, though still KDE related at end, more in PM if. I need to spend the available time on KDE software itself again :) Am Freitag, 20. September 2019, 02:00:38 CEST schrieb Thomas Pfeiffer: > On 19.09.19 20:58, Friedrich W. H. Kossebau wrote: > > If you look at history, politicians will also not be really impressed by > > peaceful strikes, other than looking where they need to adapt their image. > > The numbers they look at are poll results > > Yes, and poll results are affected by voters' opinion being influenced > by images of protests. > > Before Fridays for Future started, climate change was ranking pretty low > in people's priorities. Now, for example, 63% of Germans believe that > climate protection should take precedence over economic growth [1]. When > even Germans think that, that says a lot. > > Of course FFF wasn't the only thing that happened between then and now, > we've also had several temperature records, news of melting ice caps and > burning forests so there is no clear causal link, but I still believe > that when people see so many young people out on the streets every week, > it does affect them. I fear that people experiencing things by themselves has the bigger effect here, when they have been struck by weeks of unusual hot days, no more snow in winter and are seeing the rivers & lakes close-by almost dried out, their gardens and forests and fields next to their home dying away, burning forests in the news for weeks as well as its smell in the nose of many. And remarkably less dead insects on the car fronts. Seeing/feeling is believing for most, isn't it? The protests might be adding a bit, but aren't they rather an expression of the actual opinion of people? Do adults really change their mind (and actions) because kids are on the street (worse, avoiding school)? Now, the link you gave also tells that quite some people believe the FfF protests have an influence on politics. You will also find research that even more people believe in the influence of the moon on humans. So research needed on effects, not believe. And today's blocking of streets (here in Ger), I doubt this will win over more people, rather enforce existing opinions. (even mean more resource usage,as people will have to by-pass blockades to reach their destination or sit waiting in running cars, so smart, do protesters really understand the challenge, or just celebrate their street powers?) > > And the numbers business looks at are sales results. If you want to change > > things with them, use those numbers. Or become politician or business and > > try to do the right thing. > > And that's also how real strikes work; business not being able to make > > business, to pressure business leaders' mind to change. > > School kids not going to school does bother people, as evidenced by lots > of people having a strong opinion about it, one way or another. Why is > it not a "real strike" just because those striking are still in school? Because the pupils are not striking on their opponent or the cause in the matter, but actually on themselves and the future. They are stealing education options from themselves, the chance to become better enabled & more informed grown-ups. How do you want to save the world in a competent way if you are lacking in e.g. math, chemistry, biology, physics? How can you understand and try to verify the reports of scientists which research the world and try to analyze the observations done and their potential causes? How can you understand if actions & laws proposed to deal with things are properly done? How can you tell whether the changes you put on your list of demands actually make sense, do scale, are effective and deployable? Why are you harming the needed knowledge to once become an accountable business leader or politician oneself? Striking on education is actually the most counter-productive anti-future thing to be done here, no? Dump people will do dump things. It should be public striking of consumption of resource-hugging entertainment & luxury goods as well as the bad alternatives for real needs, that would be in line instead with what would be the intention of those FfF activists. Be out in the shopping streets on Saturday, but not buying stuff, instead invite other consumers to be informed about their effects and options. Present to people in perceptible ways the mechanisms of what they do and what it does in places usually invisible to them. And what they could do instead already now for the same purposes, so they can compare effective costs (money and conscience). And what you propose politicians should do and why. Would that not have much bigger changes to reach and convince other people not yet sharing the opinion and views?
Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)
Am Donnerstag, 19. September 2019, 19:35:53 CEST schrieb Nate Graham: > On 9/19/19 11:05 AM, Friedrich W. H. Kossebau wrote: > > More, I see all those "strikes" are substitutes for people actually > > handling or at least for postponing their own handling. Do you really > > need politicians to decide for you that you should look at what you > > consume and do and what harm it does to others, and then adopt things > > accordingly? Are you really all helpless victims of the bad evil system? > > Not responsible for the damage you create, because "politicians did not > > put a bin here, their fault that I drop my garbage on the ground"? > > It's a common polluter tactic to get people to internalize the idea that > each individual must take action on their own. And we should take > individual action! So you have internalized that? ;) > But it is not enough, and it never will be. Yes. And no-where did I (intent to) say otherwise. In case you missed my point, allow me to repeat it: asking others to move first, while not moving oneself is not a convincing argument. To be a serious proposer for a goal, one should show that one strives to the goal already. KDE as organization so far has not. And thus so far is not a convincing supporter of the goal. Like a car company which does blabla about how small EVs should be used by people rather and how they might build some in the future, but currently selling big SUVs and wasting lots of resources (and it does not matter what worker privately do, when it comes to company business). Having lip-only supporters as allies is not helping, it's hard to trust them. And actually it harms an organisation as well if it shouts "save the world!" but has not shown own efforts. Like someone eating meat and mumbling "people should eat vegetarian". Who should feel motivated to change things for you, who takes you serious? If you look at history, politicians will also not be really impressed by peaceful strikes, other than looking where they need to adapt their image. The numbers they look at are poll results And the numbers business looks at are sales results. If you want to change things with them, use those numbers. Or become politician or business and try to do the right thing. And that's also how real strikes work; business not being able to make business, to pressure business leaders' mind to change. I would like to see KDE here being long-term serious, and not just doing an ad-hoc "yes, evilevil, we agree, protest against it, people, are we not also good (and back to current harmful business)", without existing track. Cheers Friedrich
Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)
Hi Thomas, Am Donnerstag, 19. September 2019, 15:04:41 CEST schrieb Thomas Pfeiffer: > Of course KDE needs to care about our own environmental impact, which is > why we have the ongoing discussion about an environmental policy (it's > currently happening on the KDE e.V. members list because we first > thought about a KDE e.V. policy), and yes, we should do even more. Okay, that's promising a bit. > However, that should not keep us from participating in this campaign. > Promoting the Global Climate Strike today through our channels (it has > to be today, since the strike is tomorrow!) could in itself have an > effect. This is not about a grand gesture, this is about informing our > audience about the strike. And this is what I have been concerned about. That this is just a sudden gesture following mainstream, so "we also have done something! we are also part of the good ones! (now back to current harmful practice)". Actually this is blurring the amount of things which would need to be done to get serious effects for real, and also not helping to find what actually can be done here. What I said is said in the context that I have not seen serious targeted KDE community activity WRT environment destruction matters. And thus am totally unsure if the overall KDE community is a reliable partner here for those who work on fixing the world WRT environment damage. Or if most here do not care, or even dispute it or their personal responsibility to adapt their lifestyle. Heck, KDE members use Gmail & other questionable services despite the claim to aspire "[a] world in which everyone has control over their digital life and enjoys freedom and privacy.". So what level of being serious can be expected here? More, I see all those "strikes" are substitutes for people actually handling or at least for postponing their own handling. Do you really need politicians to decide for you that you should look at what you consume and do and what harm it does to others, and then adopt things accordingly? Are you really all helpless victims of the bad evil system? Not responsible for the damage you create, because "politicians did not put a bin here, their fault that I drop my garbage on the ground"? Who actually are the people striking against? Any chance it could be: themselves? To me this is rather destructive activism, organized shifting of responsibility to others/the system, with a dose of self-celebration. And stealing focus from those who are active, but missing e.g. proper promotion. Has Free Software been created by striking? Do not black the pages, list the solutions/approaches known so people can do act now in more responsible ways. Cheers Friedrich
Re: FSF leadership
Am Donnerstag, 19. September 2019, 10:31:38 CEST schrieb Christian Loosli: > I think that people should be elected into positions based on their > suitability for that position, which means that things like sex, gender, > race, cultural background, sexual orientation etc. pp. Race? Sounds like people are proposing there are human races? You might be reusing phrases here by people you think are out there for a more humanist world, but please reflect a bit on this very term, and if it makes sense to copycat that phrase and if it really represent what you are thinking. And if you are not actually copying terms and ideas of racists, when you might not be one. Cheers Friedrich
KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)
Am Mittwoch, 18. September 2019, 18:01:18 CEST schrieb cahfof...@tuta.io:
> Hello to all members of the KDE community,
>
> this friday (september the 20th) will be a big day in climate protests and
> hopefully also in human history: People in more than 3500 places worldwide
> are joining the Global Climate Strike to draw attention to the rising
> climate crisis.
>
> The question I want to ask you is: Should KDE join this protests and show
> solidarity with the people engaging for this very important topic?
If KDE (as organization) found this topic important, it should rather have it
on its agenda every day, instead of just signaling one day the year "oh yes,
so important topic, we also agree someone(tm) should fix this!!1!" , and the
rest of the year continue using flights also for KDE activities ("it's quicker
& less expensive, sorry") or buy that new device because it is more powerful
("I could not stand the old one, sorry").
I would find it ridiculous and would be embarrassed to see someone doing this
in my name (as active contributor to KDE software projects), when it's not
backed by official applied policies. You are actually harming the strike, and
shadowing those people who are not just signaling, but serious by what they
do.
Act first, then demand acts from others, please. And yes, I am aware there are
individuals here who privately act with environment in mind (he, I would
consider myself one). But as organisation KDE does not really care currently.
So it should not pretend it does.
Like, are KDE's products evaluated in hindsight of their impact on
environment, other than side-effect of economically importance to be short on
need of device resources?
Is e.V. travel support making sure people tried hard to pick the most
environment-neutral traffic way (where possible to tell), instead of just
looking at money?
And do KDE make sure its servers are run on environment-neutral resources?
If not, shutting them down on strike would be an act indeed, there I agree ;)
Cheers
Friedrich
Re: Anonymous contributions
Am Dienstag, 16. April 2019, 22:59:52 CEST schrieb Boudewijn Rempt: > I completely fail to understand what you're trying to say. This has nothing > to do with a commit hook that makes a misguided attempt at parsing strings > and validating them as real names. ? It has. For the start, it simply uses our existing big data of valid real names (a.k.a. identity.kde.org). For registered persons pushing, that would cover validating their name. And as nice bonus prevent unwanted accidental use of private data (like private/company email address or private user name). For unregistered persons, that validation would be shifted to the person doing the commit (!= author), who then would do the validation on their account. So this would actually implement what you ask for: no guess work about valid names. Cheers Friedrich
Re: Anonymous contributions
Am Dienstag, 16. April 2019, 22:29:49 CEST schrieb Friedrich W. H. Kossebau: > Am Dienstag, 16. April 2019, 22:16:40 CEST schrieb Boudewijn Rempt: > > On dinsdag 16 april 2019 22:10:54 CEST Friedrich W. H. Kossebau wrote: > > > I wonder if the commit push hook could not actually compare against > > > identity.kde.org to check for validness of name & email address, at > > > least > > > for the committer. The schema there already has name & email-address, > > > perhaps could be extended to allow configuring custom commit name & > > > email > > > address for those who need. > > > > You cannot do that, because new contributors aren't in identity, > > necessarily. > > For new contributors, that's where I proposed to use some commit message key > word, so the "old" contributor (as in, registered with identity.kde.org and > having push rights) who is pushing that commit can flag the author data as > "new person, I checked validness of author metadata". Or to give concrete example (assuming some person called, say, Linus Torvalds who might have sent a patch for Subsurface Drawing Mode for Krita). --- 8< --- committer: Boudewijn Rempt author: Linus Torvalds message: Subsurface Drawing Mode Adds UI variant for Subsurface Drawing Tablet EXTERNAL_AUTHOR --- 8< --- The hook would check the committer first, then the author, both against identity.kde.org. If the author is not matched, some explicit keyword (e.g. EXTERNAL_AUTHOR or whatever makes sense) in the commit message could overrule that check and hint the committer takes responsibilty that the metadata of that external author is okay. Cheers Friedrich
Re: Anonymous contributions
Am Dienstag, 16. April 2019, 22:16:40 CEST schrieb Boudewijn Rempt: > On dinsdag 16 april 2019 22:10:54 CEST Friedrich W. H. Kossebau wrote: > > I wonder if the commit push hook could not actually compare against > > identity.kde.org to check for validness of name & email address, at least > > for the committer. The schema there already has name & email-address, > > perhaps could be extended to allow configuring custom commit name & email > > address for those who need. > > You cannot do that, because new contributors aren't in identity, > necessarily. For new contributors, that's where I proposed to use some commit message key word, so the "old" contributor (as in, registered with identity.kde.org and having push rights) who is pushing that commit can flag the author data as "new person, I checked validness of author metadata". Or are there workflows where also the "committer" (other than the "author" metadata) is that of someone not yet registered? Cheers Friedrich
Re: Anonymous contributions
Am Dienstag, 16. April 2019, 22:00:24 CEST schrieb Nate Graham: > On Tue, 16 Apr 2019 13:38:04 -0600 Ben Cooksley > wrote > > This hook was implemented in the first place to ensure that people had > > correctly setup Git on their local machine. On some versions of Git > > (maybe all?) it will automatically use the local user account name as > > the name. This leads to people committing as "me", "user" and "nobody" > > without meaning to, but which still leads to a situation in which the > > metadata of a commit has ended up being useless. I'd rather maintain a > > small list of exceptions for those who do have names without a space in > > them to ensure that for the vast majority of our users do correctly get > > informed they need to fix their local setup. Cheers,Ben > > The only people who have commit access have been specifically granted this > privilege. I think it's fair to say that all of them have git set up > correctly on their machines by the time they've been approved for commit > access. History has shown that people still (accidentally) reset their git config (e.g. on new os setup) or, more often, have different git identities and might accidentally commit with a wrong id (think work vs. personal vs. otherorg). Sometimes even leaking unwanted info, or misleading copyright hints (company or personal work). I wonder if the commit push hook could not actually compare against identity.kde.org to check for validness of name & email address, at least for the committer. The schema there already has name & email-address, perhaps could be extended to allow configuring custom commit name & email address for those who need. For the author in case of pushing work of 3rd-party non-identity.kde.org- registered persons, one could perhaps have a keyword saying "yes I checked author data of the commit metadata". Cheers Friedrich
Re: [kde-community] Cervisia?
Am Sonntag, 5. Juni 2016, 14:22:45 CEST schrieb Nicolás Alvarez:
> > El 5 jun 2016, a las 09:08, Martin Koller escribió:
> >> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> >>
> >> Some i18n issues:
> >>
> >> It is a QApplication so you have to add the translators tab manually with
> >> aboutData.setTranslator
> >
> > ok. what shall I write there (names, emails ?)
> >
> > Isn't that a limited approach to name the translators in the sourcecode,
> > since every new translation added will need a source change ?
>
> No; you use something like i18n("TRANSLATOR NAME") (I don't remember the
> exact string), so that the name comes from the translation itself.
It would be
setTranslator(i18nc("NAME OF TRANSLATORS", "Your names"),
i18nc("EMAIL OF TRANSLATORS", "Your emails"));
And it needs to be these very strings, as they are here, both comment and
content, because for those by definition there will be in the catalog
translation strings which then contain the names of the people who did the
translations for the given language. Which means, the i18nc call will then
return the names (and emails) of the translators for the current language, as
stored in the currently used translation catalog. (So not the names of all the
translators who translated to any languages, just for the current).
And there will be always such strings with their translation in the
translation catalog, they do not need to be present in the actual code which
makes uses of them, and thus do not need to be present in the catalog template
(pot file).
And as Albert already said in his email, it might not need to be done when
using KMainWindow (or derived classes like KXmlGuiWindow), as by tradition the
KMainWindow constructor ensures those strings are set on the global
KAboutData::applicationData object.
See
https://api.kde.org/frameworks/kcoreaddons/html/
classKAboutData.html#a9a0a3e87cede16d6bb2e96d5bc5e5d4b
for all the details in the API documentation of KAboutData.
Cheers
Friedrich
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Wikis uneditable
Am Samstag, 27. Februar 2016, 00:47:39 CET schrieb Ingo Malchow: > Am Dienstag, 2. Februar 2016, 20:51:40 CET schrieb Ben Cooksley: > > 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 > > This has been fixed now. The wikis are updated and the login was changed to > an OAuth2 based login via Phabricator. > This means you need an identity account, and have it activated on http:// > phabricator.kde.org > For more information see https://community.kde.org/Sysadmin/Wiki-Phablogin Very good. And can confirm it works. Thanks for fixing and protecting some more against those awful socially challenged spammers! One issue: on first login with phabricator to e.g. userbase, on the form to enter a new account name or pick an existing account, if picking new account and entering a name which is already taken, there is no feedback besides a blank page. So one has to guess there was a name collision. Thanks again Friedrich ___ 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)
Am Samstag, 19. September 2015, 08:37:54 schrieb Ben Cooksley:
> On Sat, Sep 19, 2015 at 8:10 AM, Friedrich W. H. Kossebau
>
> wrote:
> > Am Freitag, 18. September 2015, 17:12:12 schrieb Boudhayan Gupta:
> > 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.
Could that effort not be crowd-sourced, as with the build metadata?
> 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?".
Who would expect the mirror to be complete? Besides, that could be mentioned
in the description on github.com/KDE:
"Official mirror of the KDE project. Only contains repos of projects whose
maintainers support it."
And "KDE Github Mirror" perhaps should be "KDE Github Readonly Mirror".
> 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.
People do not read READMEs, I lost my hopes there at least. Because most
READMEs are outdated/unmaintained. So not really sure people can be blamed for
that behaviour.
> If people do ignore that notice and submit stuff via Github pull
> requests, they can be handled by the bot suggested on the other thread
> - or simply ignored (as the person failed to read our instructions).
Which opens a chance for people being pissed off because their effort on
creating a patch is ignored, when they just missed the note that it's not
possible. And I do not like to piss off people. But I also do not like using
github for my FLOSS work. So now I feel forced to support people on github ->
me not happy, questioning KDE values.
So if I look at the problems presented initially in look for a solution:
* people not finding our git repositories
* people being surprised that our code is not on github
* some projects starting to use github in addition to our own infrastructure
For the first, my answer is not: mirror on github, but rather: make this info
better accessable (heck, perhaps simply put in the About dialog, in a new tab
"Developers").
People who are surprised our code is not on github: have a page explaining
why. Education is needed.
If some projects started to use github, they might have specific needs, which
should be investigated and learned from how we could improve our
infrastructure to meet that.
I miss to see why e.g. Okteta code should be mirrored on github officially by
KDE, if the full power of github is not used. This does not make any sense to
me. Who is targetted here, for what?
I only see lose-lose, making ourselves feel our infrastructure is anything but
usable and giving a bad experience on github ("suckers just have bots telling
me to represent my patch in some alien infrastructure that I first have to
learn now additionally, why here and not using github?!1").
Cheers
Friedrich
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)
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. Cheers Friedrich ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Why were there no talks about Ubuntu Mobile at Akademy?
Am Donnerstag, 15. August 2013, 21:34:44 schrieb Aaron J. Seigo: > [...] and are > using KDE technologies such as Marble and apparently Konsole (?) quietly > without any apparent contact with the projects may also be another negative > indicator. People love rumors, so give them to them, especially if they help keeping images simple, and life is complex enough ;) But the rumor about Marble I have to spoil a little, as things were initiated right in front of me, between Michael Zanetti, proud owner of KDE and Canonical hats, and Mr. Marble tackat himself, and right at Akademy. Michael missed a good navigation program on his otherwise by own definition quite usable Ubuntu Touch phone (dogfooding), and Torsten encouraged him to take Marble and port it to Qt5, including the routing code. "apparent", "may"... let's try to stay with facts even when emotional, yes? :) Cheers Friedrich ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
