Re: Proposal unify back our release schedules

[Albert Astals Cid]

El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va 
escriure:
> Ok, so happily I actually see quite a bit of agreement here, regardless
> of what else we do.
> 
> 1. Fibonacci bugfix releases are good, and we could benefit from having
> Gear adopt these.
> 
> 2. Severing implicit dependencies is a good idea. Shared libraries in
> Gear are especially problematic and could benefit from being moved to
> Frameworks.
> 
> 3. Fast frameworks releases in some capacity are a benefit and we don't
> want to lose this.
> 
> 
> All in agreement? If so, that would be amazing.
> 
> ---
> 
> Now, let's say we make Gear use Plasma's current release schedule by
> syncing up the feature releases and adopting the Fibonacci bugfix
> releases. If we don't end up changing Plasma's own release schedule then
> we already make our promo store more coherent by letting the marketing
> team do three big glossy announcements of user-facing products a year,
> rather than being stretched thin for 6. Even if we make Plasma go down
> to 2 releases a year, then we have two synced Gear+Plasma
> "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both
> of these options would improve the promo story IMO.
> 
> ---
> 
> Moving on, the biggest points of contention I see revolve around
> Frameworks. Personally I want to push back a bit on the idea of
> developing an app against released frameworks. 

I disagree.

In my ideal world, applications should be able to be built against a one year 
old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu 
22.04, which makes sure virtually everyone can contribute to it without having 
to build the world.

There's virtually no need in Okular to depend against any new frameworks shiny 
feature, the existing features are more than enough.

Cheers,
  Albert


> This is only realistic if
> you use a rolling release distro and are okay with waiting a month to
> use the new Frameworks code. 
>
> For users looking to contribute with common
> discrete-release distros, it is not at all realistic as many Frameworks
> consumers require versions newer than what those users have on their
> system, so they have to build some Frameworks anyway (note: not all of
> them; kdesrc-build/kde-builder are smart enough not to do unnecessary
> work). The older the distro's packages, the more likely this is to be.
> 
> Furthermore, because Frameworks has time-based releases and no beta
> releases, in practice the QA is provided by developers living on master.
> If KDE developers deliberately avoid this, they're not participating in
> QA. There are of course other ways to improve Frameworks' QA as well,
> but continuing to encourage KDE developers to use distro-packaged
> Frameworks goes against the larger goal: we can't QA software versions
> we're not using.
> 
> While 12 releases a year of Frameworks feels fast, it's actually not.
> Gear also has 12 releases a year: 3 feature releases and 9 bugfix
> releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix
> releases. The lack of bugfix releases is notable. With Plasma if a major
> bug is discovered a day after the release (which is common) I can ship a
> fix within a week, whereas for Frameworks, it takes a month. This is not
> a theoretical problem; it has happened many times over the years.
> 
> To me it has always felt strange that the product that benefits most
> from stability gets 4 times as many yearly feature releases as Gear and
> Plasma, but no bugfix releases at all. And there have been many
> occasions oven the years where new features in Frameworks could have
> benefited from a bit more QA time in master before final release.
> 
> In this sense I find Frameworks' release schedule to be both too fast
> and too slow: too fast for new features and too slow for bugfixes.
> Shouldn't the product with the strongest stability guarantee ship
> bugfixes at least as fast as Plasma?
> 
> If Frameworks got a feature release every 2 or 3 months and a guaranteed
> bugfix release one week after each feature release, IMO the result would
> be much better. We could ship fixes for important bugs faster,
> developers would be more incentivized to live on master and therefore
> provide their own QA, the period of time during which issues with new
> features could be caught before release would be doubled or tripled, and
> we could even still have 12 total releases per year.
> 
> ---
> 
> Thus, if we make Gear's release cycle identical to Plasma's to get it
> faster bugfixes, and then we also lengthen Frameworks' release cycle so
> it gets the bugfix releases it could benefit from while slowing down its
> feature releases to improve QA, then the result looks a lot like Carl's
> proposal, and that's ultimately why it looks appealing to me.
> 
> This doesn't preclude breaking implicit dependencies and relocating
> software into groups/release vehicles more suited for them. I don't find
> the argument convincing that 

Re: Join the Goals sprint in Berlin!

[Albert Astals Cid]

El dissabte, 30 de març de 2024, a les 16:01:57 (CET), Adam Szopa va escriure:
> Hi everyone,
> 
> In a couple of weeks (20-24th of April, arrivals on the 19th) there is a
> Goals sprint happening in Berlin.

A couple of weeks is not enough time for most people to be able to attend an 
event that is in possibly another country and on top of that happens during 
the work-days.

I know organizing events is hard, but please next time let's try to organize 
things with more time :)

Best Regards,
  Albert

P.S: I can probably make it but that's not the point I'm trying to make here 
:)

> 
> If you'd like to participate, please add your name on the community wiki
> here: https://community.kde.org/Sprints/Goals/2024
> 
> There you can also find some more details as well. The exact location is
> still being confirmed, but nevertheless if you're interested in meeting
> fellow KDE community members and work on the KDE goals please consider
> joining.
> 
> If you have questions, you can reach out to the individual Goal
> champions (https://kde.org/goals/) for specific Goal plans; or to me
> here or on matrix (@adam:kde.org) for general sprint questions.
> 
> 
> - Adam

Re: [GSoC] org applications open from 22 January - 6 February (deadline at 18:00 UTC)

[Albert Astals Cid]

El dimarts, 23 de gener de 2024, a les 12:22:14 (CET), Joseph P. De Veaugh-
Geiss va escriure:
> == GSoC 2024 ==
> 
> It is time to start discussing among your teams what ideas will be great
> to have for GSoC this year and who is willing to mentor.
> 
> The organization application period began yesterday and the deadline is
> on 6 Feb 2024 at 18:00 UTC. We need a wiki page filled with ideas by
> then! More info can be found at:
> 
> 
> https://opensource.googleblog.com/2024/01/google-summer-of-code-2024-mentor-> 
> organization-applications-now-open.html
> 
> Johnny has updated the skeleton wiki ideas page for the 2024 season:
> 
>https://community.kde.org/GSoC/2024/Ideas

Please folks, add more ideas, I'm sure you have many of them :)

Cheers,
  Albert

> 
> == Any Co-Admins? ==
> 
> Are there people willing to help co-admin this year?
> 
> I (Joseph) will not be able to co-admin as a new KDE Eco project begins
> in April.
> 
> Having a team is not only very helpful but it also feels great to see
> all the work that comes out of your assistance in administering the
> projects!
> 
> Cheers,
> Joseph & Johnny

Re: Installing KDE utilities on macOS using Homebrew

[Albert Astals Cid]

El dilluns, 11 de desembre de 2023, a les 15:25:44 (CET), Yoann LE BARS va 
escriure:
> Hello, everybody out there!
> 
>   I am a long time Unix, more precisely GNU/Linux, user, and I use
> several KDE utilities on a daily basis. I need to do some tests on macOS
> with a M1 processor, therefore I try to install KDE utilities with
> Homebrew,

This is off-topic for this list.

The topic of the list is: "provide a place for non-technical information and 
discussions which are relevant to the KDE community as a whole"

I'd say https://mail.kde.org/mailman/listinfo/kde-mac is the appropriate list 
for your issue.

Cheers,
  Albert

KDE's 6th Megarelease release parties

[Albert Astals Cid]

Hello Community!

Those of you old enough probably remember that we used to have release parties 
when we did releases, but that died down a while ago.

With the upcoming KDE's 6th Megarelease we have upon us the greatest of the 
excuses to do another of those glorious parties.

Add yours to 
https://community.kde.org/Promo/Events/Parties/KDE_6th_Megarelease

Let's party like it's 2016!
  Albert

P.S: This is all David Edmundson's fault/responsibility I'm just the messenger

Please send KDE related talks to FOSDEM calls for papers

[Albert Astals Cid]

The devrooms have been announced

https://fosdem.org/2024/news/2023-11-08-devrooms-announced/

and most of the call for papers are open (and will close "soon").

There's quite a few devrooms that probably we can send talks to. 

Please do, it's not only important to do great stuff, we need the world to 
know we do great stuff ;)

Cheers,
  Albert

Re: [call to action] "KDE For All" goal | Adding video subtitles

[Albert Astals Cid]

El dilluns, 16 d’octubre de 2023, a les 14:31:14 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
> Hello! As part of the /KDE For All/ accessibility goal [1], KDE is now
> adding subtitles to videos, including translations.
> 
> Will your team join us in making KDE's videos accessible for all?
> 
> Recently Johnny Jazeix, GCompris contributor and leader in the
> mentorship programs SoK/GSoC, expanded the existing subtitling workflow
> so that the translation team is involved. Once translations are
> completed, posting videos in more languages is now more or less automatic.
> 
> By subtitling videos and providing translations, KDE's media can reach
> more people and more communities around the world.
> 
> So how does it work?
> 
> The creator of the video uploads the SRT (subtitle formatted file) in
> English to Invent along with a short configuration file. Translators
> then translate the SRT into different languages. These translations will
> gradually be uploaded to both PeerTube and YouTube. For details about
> creating video subtitles using Kdenlive and uploading them to
> invent.kde.org, see this page at the community wiki:
> 
> * https://community.kde.org/Video_Subtitles

I'm a bit confused that page doesn't mention the workflow of using .po files 
that seems should be the preferred one? 

Cheers,
  Albert

> 
> The whole process may take several days, as different translation teams
> work in different time zones and work at different rates. For examples
> of videos using the system on both platforms, see the following:
> 
> * https://tube.kockatoo.org/w/3moubSFAnn6n5UAQoyuetW
> * https://tube.kockatoo.org/w/3Sb8KKCmdQcPgoQsyK24YE
> * https://www.youtube.com/watch?v=RFlQR0ymisE=31s
> 
> The Krita team has already begun using this workflow [2], and we would
> like to involve more and more of KDE's teams in this effort.
> 
> For support, please reach out to the community at:
> 
> * https://go.kde.org/matrix/#/#kde-www:kde.org
> 
> For translation support, please see the wiki page:
> 
> * https://community.kde.org/Get_Involved/translation
> 
> Thanks to Johnny Jazeix and Paul Brown for their excellent work in
> making this possible.
> 
> Cheers,
> Joseph
> 
> [1] "Add video subtitles":
> https://invent.kde.org/teams/accessibility/collaboration/-/issues/29
> [2] https://mail.kde.org/pipermail/kimageshop/2023-September/016874.html

Re: [discussion] archiving and retiring the Dot

[Albert Astals Cid]

El dimarts, 3 d’octubre de 2023, a les 22:01:26 (CEST), Paul Brown va 
escriure:
> On Tuesday, 3 October 2023 20:30:51 CEST Albert Astals Cid wrote:
> > El dimarts, 3 d’octubre de 2023, a les 19:18:37 (CEST), Paul Brown va
> > 
> > escriure:
> > > Hello,
> > > 
> > > > That is not correct, Akademy makes a huge use of the dot for sharing
> > > > info
> > > > to the wider community
> > > > 
> > > > You can see this by looking at the articles on https://dot.kde.org/
> > > 
> > > But that reasoning is a bit weird, no? I am reading "There are many
> > > Akademy
> > > articles on the dot because Akademy articles are posted on the dot". But
> > > surely the same could be said of another site, say akademy.kde.org, if
> > > we
> > > started posting Akademy articles there, right?
> > > 
> > > I don't see how that makes using the dot over any other site better.
> > > 
> > > > KDE needs somewhere for official news, having that just mixed in with
> > > > blog
> > > > posts would make them much harder to find and be drowned out in noise
> > > 
> > > I would argue that it is not noise. Blog posts  collected on the planet,
> > > by
> > > and large _are_ KDE news.
> > > 
> > > If anything the dot brings more noise to the planet than any other
> > > source,
> > > as multiple largely unrelated  topics are covered on the dot, while
> > > blogs
> > > of the different projects and developers tend to focus on narrow,
> > > specific
> > > topics.
> > > 
> > > In any case, if noise is what you want to avoid (and it is a valid point
> > > to
> > > bring up), it makes much more sense to publish Akademy news on the site
> > > that hosts all the other Akademy info, that is: on akademy.kde.org and
> > > interested parties can go there to get their news.
> > 
> > I disagree, I see akademy.kde.org as the page for people explicitly
> > interested in Akademy, but even people not really interested in Akademy
> > are
> > potentially interested in what happened in it,
> 
> As far as I know, there is no plan to stop posting news about Akademy or
> impede those people who are interested in Akademy news from reading them,
> albeit elsewhere.
> 
> > e.g. because they are
> > interested in the decision we took to rename Plasma to Quark.
> 
> What?!?

That was just an hypothetical example of something that may be decided in 
Akademy (and thus reported in the Akademy news) that people that are not 
interested in Akademy per se would like to know about.

Cheers,
  Albert

Re: [discussion] archiving and retiring the Dot

[Albert Astals Cid]

El dimarts, 3 d’octubre de 2023, a les 19:18:37 (CEST), Paul Brown va 
escriure:
> Hello,
> 
> > That is not correct, Akademy makes a huge use of the dot for sharing info
> > to the wider community
> > 
> > You can see this by looking at the articles on https://dot.kde.org/
> 
> But that reasoning is a bit weird, no? I am reading "There are many Akademy
> articles on the dot because Akademy articles are posted on the dot". But
> surely the same could be said of another site, say akademy.kde.org, if we
> started posting Akademy articles there, right?
> 
> I don't see how that makes using the dot over any other site better.
> 
> > KDE needs somewhere for official news, having that just mixed in with blog
> > posts would make them much harder to find and be drowned out in noise
> 
> I would argue that it is not noise. Blog posts  collected on the planet, by
> and large _are_ KDE news.
> 
> If anything the dot brings more noise to the planet than any other source,
> as multiple largely unrelated  topics are covered on the dot, while blogs
> of the different projects and developers tend to focus on narrow, specific
> topics.
> 
> In any case, if noise is what you want to avoid (and it is a valid point to
> bring up), it makes much more sense to publish Akademy news on the site that
> hosts all the other Akademy info, that is: on akademy.kde.org and
> interested parties can go there to get their news.

I disagree, I see akademy.kde.org as the page for people explicitly interested 
in Akademy, but even people not really interested in Akademy are potentially 
interested in what happened in it, e.g. because they are interested in the 
decision we took to rename Plasma to Quark.

> 
> The same goes for KDE e.v. announcements (new sponsors, Board sprints,
> advisory board meetings, etc.), and news and blog posts covering KDE's
> mentorization programs: they should live on the sites that talk about those
> things so people who are only interested in those things can avoid all other
> noise.
> 
> And if you want a wider array of news (i.e. something noisier), well, that
> is what the planet is for. 

I disagree, the planet is an assortment of blogs from contributors, not a news 
page.

> By removing the dot from the equation, we are
> helping readers reduce their exposure to noise.
> 
> It is also worth pointing out that the traffic to the dot is extremely low
> and does not make up for the effort of writing for it and probably
> maintaining it. While monthly visits to other sites are beyond the
> thousands, sometimes the 10s of thousands, monthly visits to the dot are in
> the hundreds, rarely breaking 10 visitors a day.
> 
> I understand that not all projects equally popular, so there will be a a
> wide differences in traffic,  but the dot is a news site. Maintaining a
> news site nobody reads makes no sense.

Maybe nobody reads it because nothing is written into it. Last news item is 
from month ago, why would anyone visit a news page with so little news?

Cheers,
  Albert

> 
> Cheers
> 
> Paul

Re: Handling licences for generated files

[Albert Astals Cid]

El dissabte, 9 de setembre de 2023, a les 14:58:39 (CEST), Johnny Jazeix va 
escriure:
> Hi,
> 
> for the new project to translate subtitles for KDE videos, we generate
> subtitles files (srt files) from po files.
> 
> To generate the translated file, we use the original srt file (which
> is under the licence/copyright of the creator choose) and the po files
> written by the translators (some po files have licence and/or
> copyright, other none of it).
> 
> For the generated file, is there a constraint of licence/copyright due
> to how we create them (and from which data)?

Yes, generated files [must] have the license of the file they are generated 
from.

Imagine a GPL file, then you "generate" a new one by one space in front of the 
file, you can't decided to simply consider it to be CC-BY-SA-4.0 after doing 
that generation step, the file is still GPL.

Cheers,
  Albert

> 
> Or could I simply consider all the generated files as CC-BY-SA-4.0
> with a generic copyright ("2023 This_file_is_part_of_KDE" for
> example)?
> 
> Cheers,
> 
> Johnny

Re: using gitlab ultimate

[Albert Astals Cid]

El dimecres, 2 d’agost de 2023, a les 15:44:48 (CEST), Harald Sitter va 
escriure:
> I don't think so

This seems to disqualify it, I don't think it makes any sense to use non Free 
Software to something as core as code hosting.

Cheers,
  Albert

> 
> On Wed, Aug 2, 2023 at 3:39 PM Sune Vuorela  wrote:
> > On 2023-08-02, Harald Sitter  wrote:
> > > Ahoy!
> > > 
> > > How about we start using the gitlab ultimate rather than the free
> > > version?
> > 
> > Is it free software ?
> > 
> > https://mako.cc/writing/hill-free_tools.html
> > 
> > /Sune

Re: discuss announce forum forward to kde-announce list

[Albert Astals Cid]

El dimecres, 21 de juny de 2023, a les 16:41:03 (CEST), Kenny Duffus va 
escriure:
> On Wednesday, 21 June 2023 15:33:34 BST Jonathan Riddell wrote:
> > Can we set up the Discuss announce forum to forward to the kde-announce
> > mailing list?
> > 
> > https://discuss.kde.org/c/announcement/9
> > 
> > https://mail.kde.org/pipermail/kde-announce/
> > 
> > Currently we have to post twice and that often doesn't happen
> 
> Doing it mailing list to forum sounds better?

Much better

Re: Akademy 2023 schedule

[Albert Astals Cid]

El dijous, 1 de juny de 2023, a les 14:32:42 (CEST), Scarlett Moore va 
escriure:
> On Thursday, June 1, 2023 4:56:34 AM MST Joseph P. De Veaugh-Geiss wrote:
> > The schedule for Akademy 2023 has been published:
> >https://conf.kde.org/event/5/timetable/#20230715
> >
> >  > Akademy 2023 will be a hybrid event, combining on-site and remote
> > 
> > sessions, and will include talks, workshops, Birds of a Feather (BoF)
> > meetups, training and coding sessions. The conference is expected to
> > draw hundreds of attendees from the global KDE community to discuss and
> > plan the future of the community and its technologies. Many participants
> > from the broad Free and Open Source software community, local
> > organizations and software companies will also attend.
> > 
> > Looking forward to seeing many of you from 15-21 July at University of
> > Macedonia (UoM) in Thessaloniki, Greece and online!
> > 
> > Cheers,
> > Joseph
> 
> I see I am lined up with the KDE-eV stuff, I am in the KDE-eV and believe I
> should be in this meeting? Conflict?

No, the KDE eV assembly is on Monday.

The weekend eV reports are a nicety for the non members to get informed if 
they want to.

You can get informed by thereports as sent to the membership mailing list and 
and ask questions either on said mailing list on the AGM meeting on Monday.

Cheers,
  Albert

> Scarlett

Re: (low-frequency) mailing lists | suggestions & summary of prior thread

[Albert Astals Cid]

El dimecres, 24 de maig de 2023, a les 9:35:38 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
> On 5/24/23 00:03, Albert Astals Cid wrote:
> > El dimarts, 23 de maig de 2023, a les 14:10:37 (CEST), Joseph P. De
> > Veaugh-
> > 
> >> Beyond typical forum functionality, Discourse integrates well with email
> >> and RSS. Something to consider for low-frequency mailing list groups:
> >> there may be projects and communities that benefit by officially moving
> >> communication to Discourse. Although I have no data to back up the
> >> claim, I suspect having users interact on a more active platform could
> >> generally increase engagement within KDE.
> >> 
> >> A nice feature of Discourse is: for mailing list subscribers who wish to
> >> continue receiving posts in their mail clients,
> > 
> > Is it really? I remember once that i visited, commented on a post and
> > never
> > ever got emails when people answered me on that post. I am not a crazy
> > person that plans visiting discuss.kde.org every 5 minutes just in case
> > someone has answered me, the site must send me an email and in my 1 time
> > experience it failed to do so.
> 
> Is this with "mailing list mode" enabled?

No, because it from your description it doesn't seem what i want at all.

  I do not want to get emails for all the posts sent to all the places in the 
site.
  I do not want to answer to things via email

I just want a sensible notification policy in which when someone answers to 
something i posted I get a notification by email.

> 
> I think what you are describing is related to general email settings for
> notifications. This can be found under Profile > Preferences > Emails.
> This looks like the relevant place: "Email me when I am quoted, replied
> to, my @username is mentioned, or when there is new activity in my
> watched categories, tags or topics." Perhaps check your settings there?
> 
> Note there may also be relevant settings under Profile > Preferences >
> Tracking for "tracking" and "watching", word choices which do not make
> the distinction clear, in my opinion. Right now I am not well-informed
> about the options here.

It is broken, it seems watching is more intense than tracking (which my non 
English brain disagrees with) and watching is what i want. It also seems 
broken in which you have to set it tracking and then to watching again for it 
to actually work? (according to some random forum posts)

So what i want is apparently "When I post in a topic, set that topic to 
Watching"

Let's see if i ever post to discuss.k.o again it works as promised.

Cheers,
  Albert

> 
> However, I am testing "mailing list mode" and I receive dozens of emails
> a day for the categories I did not mute (see info below). I have not
> tested the reply by email function yet, though.
> 
> Cheers,
> Joseph
> 
> >> it is possible to follow
> >> discussions via RSS or by enable mailing list mode in Discourse. It
> >> takes some setting up; see below for more.
> >> 
> >> Info about using Discourse with email and RSS:
> >> * Users can enable "Mailing list mode", which allows one to receive
> >> 
> >> and respond to posts via email (i.e., just like a mailing list). By
> >> default, users receive posts to /all/ categories -- limiting posts to
> >> specific categories requires manually "muting" the other categories. See
> >> 
> >> the community wiki for more detail, including how to mute categories:
> >>   https://community.kde.org/KDE.org/KDE_Forums#Mailing_List_Mode
> >> 
> >> * Alternatively, one can follow specific categories, tags, etc. as an
> >> 
> >> RSS feed. Again, see the community wiki for details:
> >>   https://community.kde.org/KDE.org/KDE_Forums#Following_RSS_Feeds

Re: (low-frequency) mailing lists | suggestions & summary of prior thread

[Albert Astals Cid]

El dimarts, 23 de maig de 2023, a les 14:10:37 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
> Follow-up discussion to the post "Inactive mailing lists".
> 
> tl;dr There are three topics discussed here:
> 
>1. For mailing list admins: *Suggestions For Information To Add To
> Mailing List Descriptions*
>2. For mailing list communities: *Moving Certain Groups To Discourse?*
>3. For everyone: *Summary Of Prior Discussion About Inactive /
> Infrequently Used Lists*
> 
> As always, the discussion is open for your feedback and ideas!
> 
> _1. Information To Add To Mailing List Descriptions_
> 
> If you are a list admin, consider adding the following to the mailing
> list description. This way subscribers are well-informed about the
> communication channels used for your project/community:
> 
>* Other communication channels for this project and their intended
> use (e.g., for announcements, user support, live chat, etc.)
>* Relevant links for the project (e.g., website, wiki, etc.)
>* Intended scope for the list (i.e., what it is for / not for)
>* Policies regarding moderation, code of conduct, etc.
> 
> For examples, see:
> 
>* Energy-efficiency:
> https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency
>* Kde-soc: https://mail.kde.org/mailman/listinfo/kde-soc
>* Visual-design: https://mail.kde.org/mailman/listinfo/visual-design
> 
> _2. Moving Certain Groups To Discourse?_
> 
> Beyond typical forum functionality, Discourse integrates well with email
> and RSS. Something to consider for low-frequency mailing list groups:
> there may be projects and communities that benefit by officially moving
> communication to Discourse. Although I have no data to back up the
> claim, I suspect having users interact on a more active platform could
> generally increase engagement within KDE.
> 
> A nice feature of Discourse is: for mailing list subscribers who wish to
> continue receiving posts in their mail clients,

Is it really? I remember once that i visited, commented on a post and never 
ever got emails when people answered me on that post. I am not a crazy person 
that plans visiting discuss.kde.org every 5 minutes just in case someone has 
answered me, the site must send me an email and in my 1 time experience it 
failed to do so.

Cheers,
  Albert

> it is possible to follow
> discussions via RSS or by enable mailing list mode in Discourse. It
> takes some setting up; see below for more.
> 
> A few language and country-specific communities already have made a move
> to Discourse. See:
> 
> https://discuss.kde.org/c/local-communities/
> 
> Some of these groups also have low traffic mailing lists. Unless current
> list subscribers also move to Discourse, there is the risk of fracturing
> the community as list subscribers are seperated from the people at the
> forum. In this case, archiving and closing the infrequently-used mailing
> list might be beneficial. Of course, that is for the list admin and
> relevant community to decide.
> 
> Info about using Discourse with email and RSS:
> 
>* Users can enable "Mailing list mode", which allows one to receive
> and respond to posts via email (i.e., just like a mailing list). By
> default, users receive posts to /all/ categories -- limiting posts to
> specific categories requires manually "muting" the other categories. See
> the community wiki for more detail, including how to mute categories:
> 
>  https://community.kde.org/KDE.org/KDE_Forums#Mailing_List_Mode
> 
>* Alternatively, one can follow specific categories, tags, etc. as an
> RSS feed. Again, see the community wiki for details:
> 
>  https://community.kde.org/KDE.org/KDE_Forums#Following_RSS_Feeds
> 
> _3. Summary: Prior Discussion About Inactive Mailing Lists_
> 
> Here are some bullet points from the discussion about inactive /
> infrequently used mailing lists. For the full thread, go to:
> 
> https://mail.kde.org/pipermail/kde-community/2023q2/007577.html
> 
>* Some lists deliberately have archiving disabled, so an empty
> archive is not necessarily an indicator of no activity.
>* Some lists are primarily used for following bug reports (e.g.,
> *-bugs) or commits.
>* Subscribing to a low traffic email list is rarely something people
> notice, and the UI of mail clients rarely gets in the way. By contrast,
> the UI of e.g. Matrix very much gets in the way of staying in 200 low
> traffic channels.
>* Low email traffic does not mean subscribers will not answer
> appropriate posts sent to it.
>* Unless current subscribers also make the move to a new channel,
> moving discussion to a new platform risks separating the people who have
> answers (the current subscribed people) with the people who have the
> questions (the people redirected elsewhere).
>* For lists that are unquestionably no longer in use, please file a
> sysadmin ticket and they will get removed.
>* See this ticket for mailing lists that have been or 

Re: Inactive mailing lists

[Albert Astals Cid]

El dijous, 27 d’abril de 2023, a les 23:42:47 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
>   * It may not be obvious to new (or even old) contributors that a list
> is no longer in use, resulting in wasted energy signing up for an
> inactive one.

The fact that there's no traffic doesn't necessarily mean that the people that 
are subscribed won't answer appropriate emails sent to it, does it?

Cheers,
  Albert

Re: Inactive mailing lists

[Albert Astals Cid]

El divendres, 28 d’abril de 2023, a les 0:10:25 (CEST), Nicolas Fella va 
escriure:
> Am 27.04.23 um 23:42 schrieb Joseph P. De Veaugh-Geiss:
> > Cross-posting to the relevant mailing lists.
> > 
> > To discuss, please answer to kde-community@kde.org.
> > 
> > tl;dr There are several inactive or unused lists of the 181 mailing
> > lists at KDE. What do we want to do with them?
> > 
> > This is a post about inactive or unused mailing lists. For a general
> > discussion about (active) mailing lists at KDE, please start a new
> > thread or wait until I address that, likely in the very near future.
> > 
> > _Inactive Mailing Lists_
> > 
> > For a better understanding of what works and what needs improvement in
> > KDE's internal communications, I started by looking at the 181 mailing
> > lists publicly listed at:
> > 
> > https://mail.kde.org/mailman/listinfo/
> > 
> > Here I see 51 mailing lists which might be considered inactive, some
> > of which were never used at all. There may be more to add to this upon
> > further inspection, but these seem like a good place to start.
> > 
> > By inactive I mean there has been very low or no activity in the past
> > 2-3 years at least, and for most lists the last post was 4+ years ago.
> > For several of these lists, there are long gaps in activity, often
> > with no community responses to the most recent posts.
> > 
> > The 51 mailing lists are included at the end of this email.
> > 
> > Importantly, I know a list with infrequent activity is *not* the same
> > as a list that has no activity. Some communities do not need regular
> > communication for that community to be active. If you see your
> > community's mailing list here and think it is a mistake, please let me
> > know! My apologies in advance if this is the case.
> > 
> > Crucially, do not interpret an inactive mailing list to mean a project
> > is inactive. It only means the mailing list is not a frequently used
> > channel of communication. There are many other channels for community
> > discussion (e.g., Matrix, Discuss, etc.).
> > 
> > _Some Questions To The KDE Community_
> > 
> >  * What do we want to do with inactive or unused mailing lists?
> > 
> >  * Is there a policy for retiring inactive lists? I didn't see
> > anything at the Community Wiki. [1]
> > 
> >  * Does KDE have internal infrastructure to archive mailing lists for
> > posterity? I see kwrite-devel [2] archived old posts at the "Mailing
> > list ARChives" [3].
> > 
> >  * Do we want to nudge traffic from low activity mailing lists to
> > somewhere with generally higher activity (specifically, I am thinking
> > Discuss)? I can imagine being in a more active online space could
> > increase general participation for otherwise low activity groups.
> > 
> > _Inactive Lists: To Close Or Not To Close_
> > 
> > I am sure there are reasons both for and against closing mailing
> > lists. Here are just some reasons I can think of to close inactive ones:
> > 
> >  * The more communication channels there are, the more fractured KDE's
> > communication is.
> > 
> >  * It may not be obvious to new (or even old) contributors that a list
> > is no longer in use, resulting in wasted energy signing up for an
> > inactive one.
> > 
> >  * Trying to engage with an inactive list may reduce motivation for
> > futher contributions from members, especially when posts go unanswered.
> > 
> >  * Moving some communities to more lively platforms may increase their
> > overall activity.
> > 
> >  * There could be a slight efficiency/ecological benefit for KDE's
> > server infrastructure by removing or deactivating unused services.
> > 
> > Pleae keep in mind: I am not judging the value of any particular group
> > by pointing out low activity, or arguing we need to close any specific
> > list. If there is a reason -- any reason at all -- to keep a list
> > open, then let's keep it open! I myself like mailing lists for various
> > forms of communication (announcements, long-form discussion,
> > information which I want to archive locally for future reference, etc.).
> > 
> > If I made any mistakes in my summary here, please let me know. It is a
> > challenge to go through 181 lists and not make any errors, though I
> > tried my best not to.
> > 
> > I look forward to reading your thoughts and suggestions!
> > 
> > Cheers,
> > Joseph
> > 
> > [1] https://community.kde.org/Infrastructure/Mailing-Lists
> > [2] https://mail.kde.org/mailman/listinfo/kwrite-devel
> > [3] https://marc.info/
> > 
> > # Overview
> > 
> > Of the 181 mailing lists listed publicly, I found the following:
> > 
> >  * 12 are lists that have never been used and 1 was already closed
> >  * 27 are potentially-inactive general lists
> >  * 11 are potentially-inactive language or country-specific lists
> > 
> > # Unused / Closed Mailing Lists [13 Lists]
> > 
> > ## Never Used [12 lists] ("No messages have been posted to this list
> > yet, so the archives are currently empty.")
> > 
> >  * Calligra-author: 

Re: Retirement of Capacity

[Albert Astals Cid]

El diumenge, 15 de gener de 2023, a les 7:36:03 (CET), Ben Cooksley va 
escriure:
> Hi all,
> 
> Since time immemorial, KDE has had a custom PHP framework known as Capacity
> which we've used to build a good number of our websites.
> 
> With the rise of Static Site Generators such as Jekyll and Hugo though,
> we've been phasing this out and given that Hugo especially is now well
> established as the go-to-tooling for building KDE websites

> it is time we retire Capacity.

Why? The code is there and it works. It seems we're giving ourselves lots of 
work for what is really just a "few" lines of PHP.

Cheers,
  Albert

> 
> In addition, in the next few weeks the current server for our
> static/capacity sites, Nicoda, will be replaced by a new system (Tyran)
> that is currently awaiting configuration and i'd very much prefer to not
> have to deploy legacy Capacity support there.
> 
> I have checked our server configuration this evening and it looks like the
> following sites still rely on Capacity in some form or another:
> 
> konversation.kde.org
> pe.kde.org
> marble.kde.org
> kmplayer.kde.org
> www.kde.org
> games.kde.org
> docs.kde.org
> czechia.kde.org
> freebsd.kde.org
> kmymoney.org
> edu.kde.org
> multimedia.kde.org
> ro.kde.org
> konqueror.org
> kpdf.kde.org
> jp.kde.org
> utils.kde.org
> events.kde.org
> kst-plot.kde.org
> conference2004.kde.org
> conference2005.kde.org
> akademy2006.kde.org
> akademy2007.kde.org
> akademy2008.kde.org
> akademy2009.kde.org
> www-staging.kde.org
> il.kde.org
> umbrello.kde.org
> krusader.org
> ev.kde.org
> okular.kde.org
> kdemail.net
> extragear.kde.org
> lakademy.kde.org
> kphotoalbum.org
> 
> Having a quick look through the repositories/sites, I see:
> - Some that have already made the jump to Hugo/Jekyll (so likely just need
> their Capacity support switched off)
> - Some that are just redirects to apps.kde.org or elsewhere, and therefore
> just need Capacity support switched off (and probably the repository
> archived on invent.kde.org too)
> - Others where the site content is still in Subversion and the site talks
> about Maemo (eek!)
> - Others where the site content is many years out of date and it is
> probably best we just redirect it to www.kde.org / apps.kde.org.
> 
> It would be appreciated if people could please take a look through these
> sites.
> 
> For the akademy2xxx.kde.org sites, it would be nice if we could get their
> content migrated and incorporated into the new Hugo based akademy.kde.org
> site, but in the absence of that I will be turning them into static sites
> 
> Many thanks,
> Ben

Re: Funding opportunity for your projects

[Albert Astals Cid]

El divendres, 28 d’octubre de 2022, a les 14:22:06 (CEST), Scarlett Moore va 
escriure:
> Would packaging all the apps in the different formats ( snap, appimage,
> flatpak ) be considered a project?

I can't speak for what NLnet will or will not decide to donate to, but I can 
speak about the fact that your project needs attainable goals, because you 
only get donated once you meet the goals you originally said you'd meet.

So "Package all the apps for different formats" seems like a bad idea since 
it's an almost impossible to achieve milestone ;)

As an example, the 5 goals i set when i did some Okular project earlier this 
year

1. Support for signing unsigned signatures
2. Support digital signatures in the Okular Windows version
3. Make signature text support all character sets
4. Write Okular-mobile user interface to show signature status
5. Support digital signatures in the Okular Android version

Cheers,
  Albert

P.S: Of course each of the goals/milestones had some more description that 
just 1 sentence, but I hope you get the idea that you need to be a bit more 
precise in what you're going to do.

> Scarlett
> 
> On Thu, Oct 27, 2022, 5:03 PM Nate Graham  wrote:
> > Hello KDE community members and developers!
> > 
> > I'm writing to everyone about something very exciting: the NLnet
> > Foundation (https://nlnet.nl) has made us aware that they have
> > substantial quantities of funds available for FOSS projects that KDE is
> > eligible for: up to 5€ per project. If you have an idea for a big
> > project or feature you've always wanted to do but lacked the funding
> > for, here's your chance!
> > 
> > If you're worried that your idea doesn't meet the criteria, don't be;
> > practically everything KDE does is eligible for funds in the Open Call
> > (https://nlnet.nl/news/2022/20221001-call.html) which ends on December
> > 1st, so there's still plenty of time for you to apply to get your
> > project funded. Click that link for details.
> > 
> > Remember: what KDE does is good for the digital world. So if it's good
> > for KDE and you can articulate its benefits, it's a worthy project!
> > 
> > If the process seems intimidating, you'd like someone to review your
> > grant proposal, or you need guidance or assistance for any other reason,
> > the KDE e.V. stands ready to help your grant proposal succeed. Email
> > kde-ev-bo...@kde.org and we can help!
> > 
> > 
> > Nate
> > 
> > 
> > 
> > P.S. This information can also be found on
> > https://community.kde.org/Make_A_Living

Re: Gitlab update, 2FA now mandatory

[Albert Astals Cid]

El dimarts, 25 d’octubre de 2022, a les 12:19:36 (CEST), Dan Leinir Turthra 
Jensen va escriure:
> On Tuesday, 25 October 2022 11:11:46 BST Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (cullmann.io)
> 
>  a écrit :
> > > On 2022-10-23 08:32, Ben Cooksley wrote:
> > > > Hi all,
> > > > 
> > > > This afternoon I updated invent.kde.org [1] to the latest version of
> > > > Gitlab, 15.5.
> > > > Release notes for this can be found at
> > > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/
> > > > 
> > > > There isn't much notable feature wise in this release, however there
> > > > have been some bug fixes surrounding the "Rebase without Pipeline"
> > > > functionality that was introduced in an earlier update.
> > > > 
> > > > As part of securing Invent against recently detected suspicious
> > > > activity I have also enabled Mandatory 2FA, which Gitlab will ask you
> > > > to configure next time you access it. This can be done using either a
> > > > Webauthn token (such as a Yubikey) or TOTP (using the app of choice on
> > > > your phone)
> > > > 
> > > > Should you lose access to your 2FA device you can obtain a recovery
> > > > token to log back in via SSH, see
> > > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authenticat
> > > > io
> > > > n.html#generate-new-recovery-codes-using-ssh for more details on this.
> > > > 
> > > > Please let us know if there are any queries on the above.
> > > 
> > > Hi,
> > > 
> > > whereas I can see the security benefit, this raises the hurdle for one
> > > time contributors again a lot.
> > > 
> > > Before you already had to register to get your merge request,
> > > now you need to setup this too (or at least soon it is mandatory).
> > > 
> > > I am not sure this is such a good thing.
> > > 
> > > I see a point that one wants to avoid that e.g. somebody steals my
> > > account  that has enough rights to delete all branches in the Kate
> > > repository via the web frontend.
> > > 
> > > Could the 2FA stuff perhaps be limited to people with developer role or
> > > such?
> > 
> > Yes this would be ideal. We don't need to require 2fa for people who just
> > started contributing or want to give some feedback on a MR/ticket.
> > 
> > This should be possible with the following features:
> > https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce
> > -2 fa-for-all-users-in-a-group
> > 
> > We can just require 2fa for developers because with great powers come
> > great
> > responsibilities.
> > 
> > Cheers,
> > Carl
> 
>   i concur - after spending so long trying to attract casual contributors,
> putting up a huge barrier like this is just not helpful. So, 2FA for people
> who area able to actually mess stuff up, absolutely, we have responsibility
> here and that's fine, but for casual contributors, that is precisely the
> sort of thing that just outright makes people go "lol no" and go away
> again, and is that really something we can afford?

From personal experience I agree, i was going to report a VLC issue, their 
gitlab also uses mandatory 2FA and I was very close to just giving up, and 
that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account holders.

Cheers,
  Albert

>   I absolutely applaud the attempt at increasing out trustworthiness as a
> community, and 2FA for people who can actually push things certainly helps
> us get to that, but i also can't help but notice that the particular choice
> of making it a blanket community involvement requirement, that is, in this
> particular case, was made with a somewhat narrow focus, so... just thought
> i'd lend my voice to the "Yeah, please don't make our hard won casual
> contributors go away before they even get here".

There's a phishing campaign for KDE identities going on

[Albert Astals Cid]

I just got an email that said it had been sent my em...@kde.org that said 
something along the lines of

Your email is being deactivated as you asked, please login here if it was a 
mistake

And it sent to a place that was not in kde.org but looked loosely similar to 
our web pages (kde logo, blue theme, etc) that was obviously trying to get me 
to enter my login details.

Please be extra careful when using mobile or some other place where seeing 
that the address doesn't really belong to kde.org may be harder.

And as always if you think you may have fallen into the trap, change your 
password as soon as possible and tell sysadmin so they can try to see if your 
identity was abused in some way.

Stay safe!
  Albert

Re: macOS, Hombrew and KAte

[Albert Astals Cid]

El dilluns, 18 de juliol de 2022, a les 19:30:10 (CEST), Yoann LE BARS va 
escriure:
> Hello, everybody out there!

This doesn't belong to this list

"
The purpose of the mailing list is to provide a place for non-technical 
information and discussions which are relevant to the KDE community as a whole
"

This is both technical and not relevant to the KDE community as a whole.

I suggest you try https://mail.kde.org/mailman/listinfo/kde-mac

Akbert

> 
>   I am mostly used to Linux, but right now I have to use a computer
> running macOS. I want to install Kate and KDEvelop on it – I really like
> these tools, by the way, thank you for this very good job.
> 
>   The DMG installer did work for Kate, but not for KDEvelop. So I 
figured
> out I rather install them with Hombrew, and I have already used it. I
> have installed KDE specific Hombrew repository
> (https://invent.kde.org/packaging/homebrew-kde).
> 
>   Then, I have uninstalled Kate and try to install it back, this time
> using Homebrew, but I got the error given at the end of this message. As
> I am quite new in using macOS, I must say I do not really know what I
> should do. Can anyone help me?
> 
>   Best regards.
> 
> 
> The error message:
> 
> ==> Installing kde-mac/kde/kate dependency: kde-mac/kde/kf5-plasma-frame
> ==> Patching
> ==> Applying dff1b034c1162062aa2292099d3d01fc53dafdf6.diff
> patching file CMakeLists.txt
> Hunk #1 FAILED at 118.
> 1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
> patching file src/declarativeimports/core/CMakeLists.txt
> Hunk #1 FAILED at 70.
> 1 out of 1 hunk FAILED -- saving rejects to file
> src/declarativeimports/core/CMakeLists.txt.rej
> 
> Do not report this issue to Homebrew/brew or Homebrew/core!
> 
> /opt/homebrew/Library/Homebrew/utils/github/api.rb:304:in `raise_error':
> Validation Failed: [{"message"=>"The listed users and repositories
> cannot be searched either because the resources do not exist or you do
> not have permission to view them.", "resource"=>"Search", "field"=>"q",
> "code"=>"invalid"}] (GitHub::API::ValidationFailedError)
>   from /opt/homebrew/Library/Homebrew/utils/github/api.rb:234:in 
`open_rest'
>   from /opt/homebrew/Library/Homebrew/utils/github.rb:173:in `search'
>   from /opt/homebrew/Library/Homebrew/utils/github.rb:34:in 
`search_issues'
>   from /opt/homebrew/Library/Homebrew/utils/github.rb:67:in
> `issues_for_formula'
>   from /opt/homebrew/Library/Homebrew/exceptions.rb:486:in 
`fetch_issues'
>   from /opt/homebrew/Library/Homebrew/exceptions.rb:482:in `issues'
>   from /opt/homebrew/Library/Homebrew/exceptions.rb:536:in `dump'
>   from /opt/homebrew/Library/Homebrew/brew.rb:140:in `rescue in 
'
>   from /opt/homebrew/Library/Homebrew/brew.rb:128:in `'
> /opt/homebrew/Library/Homebrew/patch.rb:166:in `rescue in apply': Failed
> executing: patch -g 0 -f -p1 -i
> /private/tmp/kf5-plasma-framework--patch-20220718-58553-1gzz3dq/dff1b034c116
> 2062aa2292099d3d01fc53dafdf6.diff (BuildError)
>   from /opt/homebrew/Library/Homebrew/patch.rb:138:in `apply'
>   from /opt/homebrew/Library/Homebrew/formula.rb:1270:in `each'
>   from /opt/homebrew/Library/Homebrew/formula.rb:1270:in `patch'
>   from /opt/homebrew/Library/Homebrew/build.rb:144:in `block (3 
levels)
> in install'
>   from /opt/homebrew/Library/Homebrew/utils.rb:601:in `with_env'
>   from /opt/homebrew/Library/Homebrew/build.rb:134:in `block (2 
levels)
> in install'
>   from /opt/homebrew/Library/Homebrew/formula.rb:1286:in `block in 
brew'
>   from /opt/homebrew/Library/Homebrew/formula.rb:2462:in `block (2
> levels) in stage'
>   from /opt/homebrew/Library/Homebrew/utils.rb:601:in `with_env'
>   from /opt/homebrew/Library/Homebrew/formula.rb:2461:in `block in 
stage'
>   from /opt/homebrew/Library/Homebrew/resource.rb:130:in `block (2
> levels) in unpack'
>   from /opt/homebrew/Library/Homebrew/download_strategy.rb:115:in 
`chdir'
>   from /opt/homebrew/Library/Homebrew/download_strategy.rb:115:in 
`chdir'
>   from /opt/homebrew/Library/Homebrew/download_strategy.rb:102:in 
`stage'
>   from /opt/homebrew/Library/Homebrew/resource.rb:126:in `block in 
unpack'
>   from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `block in run'
>   from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
>   from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `run'
>   from /opt/homebrew/Library/Homebrew/resource.rb:239:in `mktemp'
>   from /opt/homebrew/Library/Homebrew/resource.rb:125:in `unpack'
>   from /opt/homebrew/Library/Homebrew/resource.rb:99:in `stage'
>   from
> /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fo
> rwardable.rb:230:in `stage'
>   from /opt/homebrew/Library/Homebrew/formula.rb:2441:in `stage'
>   from /opt/homebrew/Library/Homebrew/formula.rb:1279:in `brew'
>   from 

Re: Akademy 2022 Call For Papers has been deleted

[Albert Astals Cid]

El divendres, 10 de juny de 2022, a les 18:14:33 (CEST), Albert Astals Cid va 
escriure:
> I have made a HUGE mistake.
> 
> I have deleted the Akademy 2022 event on conf.kde.org and with it all the 
> submitted talks.
> 
> I am so sorry. I don't know how I ended up deleting the whole event when I 
> just wanted to delete the test talk I had just submitted. I have failed you.
> 
> I have contacted the system administrators in case we are super lucky and we 
> had a backup, but even if we do, some of the talks that had just been 
> submitted are probably lost.
> 
> I have asked for all my rights in conf.kde.org to be removed since clearly I 
> can't be trusted to use it.
> 
> Again I apologize for such a huge mistake.
> 
> Super sad,
>   Albert

Kenny Coyle has fixed it and all should be back to normal, no talk submissions 
have been lost.

Albert

Akademy 2022 Call For Papers has been deleted

[Albert Astals Cid]

I have made a HUGE mistake.

I have deleted the Akademy 2022 event on conf.kde.org and with it all the 
submitted talks.

I am so sorry. I don't know how I ended up deleting the whole event when I just 
wanted to delete the test talk I had just submitted. I have failed you.

I have contacted the system administrators in case we are super lucky and we 
had a backup, but even if we do, some of the talks that had just been submitted 
are probably lost.

I have asked for all my rights in conf.kde.org to be removed since clearly I 
can't be trusted to use it.

Again I apologize for such a huge mistake.

Super sad,
  Albert

Akademy 2022 Call for Participation is open

[Albert Astals Cid]

The Call for Participation for Akademy is officially opened!

...and closes relatively shortly! Sunday the 12th of June 2022 

You can find more information and summit your talk abstract here: 
https://akademy.kde.org/2022/cfp 

If you have any questions or would like to speak to the organizers, please 
contact akademy-t...@kde.org 

Cheers,
  Albert

Re: Extending the license policy to allow certain exceptions

[Albert Astals Cid]

El dijous, 25 de novembre de 2021, a les 16:42:32 (CET), Ingo Klöcker va 
escriure:
> Hi all,
> 
> it's not clear to me whether our licensing policy allows exceptions or not.

As far as I understand we want a "limited" number of licenses because we want 
to be relatively free of copying code around without having to worry [a lot] 
about the license.

As far as I see this means exceptions are OK as "emitters-of-code" since they 
give you "more" rights so you can copy from them to somewhere else without 
issues.

The problem is when files with exceptions are the "receivers-of-code" since 
you're actually breaking the license of the code-you-copied from somewhere else.

So we need to be careful about that. 

My opinion is that if we mark it *very* clearly (with license markers and maybe 
even with a special filename foo_gpl_with_exception.cpp?) and we have a very 
good reason for the exception to be there it should not be a problem.

Though how to write that into policy I am not sure :D

Cheers,
  Albert

> 
> https://community.kde.org/Policies/Licensing_Policy does not mention any 
> exceptions.
> 
> https://community.kde.org/Guidelines_and_HOWTOs/Licensing explains how to use 
> exceptions and gives an example with the Qt-LGPL-exception-1.1.
> 
> I have copied code from GCC's STL to implement a QMutex-compatible 
> replacement 
> for std::unique_lock (because apparently Windows resp. mingw doesn't have 
> std::mutex). GCC's code is "GPL-3.0-or-later WITH GCC-exception-3.1". (Ignore 
> the bogus license id in the .cpp file. I've already fixed it.) Therefore I've 
> put my Qt'ified copy under the same license.
> 
> What now? Did I violate our licensing policy? Should we explicitly add 
> allowed 
> exceptions to our licensing policy? I guess we don't want to allow all 
> exceptions listed at https://spdx.org/licenses/exceptions-index.html.
> 
> Regards,
> Ingo
> 

How do we feel about non 100% KDE job offers being sent here?

[Albert Astals Cid]

Hey,

I know a company that would like to hire people with a skill set that
is relatively common inside the KDE community, the job is not strictly
KDE related, one could call it KDE-adjacent.

How do we feel about such job offers being sent here?

I have conflicting opinions myself.

Pro:
 * We want people of the community to get [potentially better] jobs

Con:
 * The list could filled with job offers that are not really KDE
related since it's hard to define what "KDE-adjacent" really means.

Possible mitigation of the Con: Allow only Supporting Member companies
to send such job offers, but then it also is a potential mitigation of
the Pro :D

I think my opinion at this point would be "Let companies sent job
offers to this list and if it becomes unmanageable we say 'OK, was
worth a try, but it's not working, please don't send anymore'"

What do y'all think?

Cheers,
  Albert

Re: Urgent: we need projects (with mentors) for a gsoc-like project with Canadian universities (CANOSP)

[Albert Astals Cid]

El divendres, 12 de novembre de 2021, a les 11:05:20 (CET), Tomaz Canabrava va 
escriure:
> Hello fellows
> The kde community, represented by me (Tomaz Canabrava) and Aniqa Khokhar,
> had a really nice meeting with CANOSP - a coalition of universities from
> Canada - with the intention of hosting a few projects for the students to
> work on.
> 
> Differently from gsoc, the students will not work alone but in groups of
> theee to four, and they will also not write a project to implement, but
> implement something that the application needs - with the hints of the
> mentor.
> 
> It’s expected that the projects are technically challenging and that it has
> either real world usage or can be interesting on a university context.
> 
> The project will run for a semester within the universities, with one local
> mentor for each team (a uni professor) and a kde mentor.
> 
> This is a great opportunity for us to improve the entry barrier in Canada -
> as, from what I understand we have almost zero developers.
> 
> 
> I’ll wait for projects for two weeks before sending the names to the CANOSP
> organization

What's the estimated running dates for the projects? I need to be aware to 
which dates i'm potentially agreeing to be available in advance.

Cheers,
  Albert

> 
> 
> Best regards,
> Tomaz
> 

Re: 25th Anniversary Fireside Chats

[Albert Astals Cid]

Why is Country a required field to register?

Cheers,
  Albert

El dimecres, 6 d’octubre de 2021, a les 19:00:06 (CEST), Allyson va escriure:
> Hi all!
> 
> To celebrate and commemorate KDE’s 25th anniversary, we have put together 
> some great fireside chats that will occur online in the next couple of weeks.
> 
> Oct. 14th @ 17:00 UTC
> The KDE e.V. Board
> Aleix, Lydia, Eike, Adriaan and Neofytos are the five KDE volunteers that run 
> KDE e.V., the foundation that supports the KDE Community in all 
> organizational, financial and legal matters. In this fireside chat we sit 
> down with the five of them to talk about KDE’s history, achievements and 
> where they think KDE is headed. We will also dive into what it means to 
> support the KDE Community for almost 25 years.
> 
> Oct. 15th @ 18:00 UTC
> Jeri Ellsworth
> Jeri Ellsworth will share stories of working on challenging engineering 
> problems that range from chip design, rockets, robots, toys, video games and 
> augmented reality.
> 
> Oct. 23rd @ 15:00 UTC
> Massimo Stella
> Where Kdenlive project is going and what to aspect from it on a short and 
> medium term.
> 
> Oct. 25th @ 17:00 UTC
> Matthias Ettrich
> 25 years ago Matthias Ettrich started KDE. He sent a famous news group 
> posting asking for developers to join him and build the Kool Desktop 
> Environment, a desktop environment and applications for endusers built on Qt. 
> Now 25 years later we chat with Matthias to talk about how KDE started and 
> what became of his vision from 25 years ago.
> 
> 
> Register Here: https://conf.kde.org/e/KDE25th 
>  
> 
> 

Re: Chat blocking under 16s from KDE

[Albert Astals Cid]

El dilluns, 2 d’agost de 2021, a les 11:58:20 (CEST), Jonathan Riddell va 
escriure:
> I've been notified by a 13 year old who wants to help KDE that he is unable
> to log into our chat setup on Matrix because the privacy policy blocks
> anyone under 16.
> 
> https://kde.modular.im/_matrix/consent?v=1.0
> "You must be at least 16 years old to use this Service (webchat.kde.org) "
> 
> https://webchat.kde.org/privacy_policy/en/privacy_notice.html
> "We never knowingly collect or maintain information in the Service from
> those we know are under 16, and no part of the Service is structured to
> attract anyone under 16. If you are under 16, please do not use the
> Service."
> 
> This is contrary to
> https://webchat.kde.org/privacy_policy/en/code_of_conduct.html
> "Although this list cannot be exhaustive, we explicitly honour diversity in
> age"
> 
> If KDE is restricting who can take part in our activities, against our
> historical practice, without prior discussion and solely because we are
> reliant on a third party service we should move to a different service.

Don't interpet this as "stop discussing this", but this was already discussed 
when we started using Matrix

https://mail.kde.org/pipermail/kde-community/2019q1/005186.html

Cheers,
  Albert

> 
> Jonathan
> 

Re: Welcoming Eliza and Joseph to KDE e.V.

[Albert Astals Cid]

El dilluns, 5 de juliol de 2021, a les 22:54:52 (CEST), Lydia Pintscher va 
escriure:
> Hello everyone,
> 
> Today I'm happy to let you know that KDE e.V. has hired Eliza and
> Joseph, two great people who will support our work around the
> environmental sustainability of our software. This is part of the
> grant we received from the Bundesumweltamt around the Blauer Engel eco
> certificate.
> 
> Eliza Wieske will be taking on the role of project lead and event
> manager for the project. This means that she will be the liaison to
> the Bundesumweltamt and be available as an organizational contact for
> anyone interested in the project and help answer questions about its
> development. Her background is in the social sciences. Before moving
> to Gothenburg (where she lives now) she worked alongside her studies
> as an organizational assistant in a research group focused on the
> internationalization of engineering education in Germany. With the
> start of the project, she will be getting to know the free and open
> software community, which she is looking forward to learning more
> about while working with the team on getting this great digital
> sustainability project running, so we can share it with the whole
> community.
> 
> Joseph P. De Veaugh-Geiss will be taking on the role of project and
> community manager. He has been volunteering in the free software
> community since 2013. Currently, he co-organizes the Berlin Freedombox
> User Group (BeFUG) and works on outreach for the mobilize.berlin event
> management service, for which he and colleagues gave a talk at the
> 37th CCC. Prior to KDE Joseph had worked professionally as a
> researcher in the field of theoretical linguistics at the Universität
> Potsdam. He is now excited to transition into the role of
> community manager for the "Blauer Engel for FOSS" project.
> 
> If you'd like to learn more about the project and want to join the
> work on making this all happen please have a look at Cornelius' email
> here: https://mail.kde.org/pipermail/kde-devel/2021-June/000556.html
> 
> Please join me in welcoming Eliza and Joseph to the KDE Community.

Welcome!

Cheers,
  Albert

> 
> 
> Cheers
> Lydia
> 
> 

Re: MyGNUHealth Personal Health Record 1.0 released!

[Albert Astals Cid]

El dijous, 24 de juny de 2021, a les 22:53:37 (CEST), Luis Falcon va escriure:
> Dear all
> 
> I am proud to announce the first stable release of MyGNUHealth, the GNU
> Health Personal Health Record for desktop and mobile devices.
> 
> From now on, everyone of us will benefit from a Libre Personal Health
> application that respects our privacy, both from our desktops and from
> our libre phones (such as the PinePhone). MyGNUHealth is more than a
> health and activity tracker, since it incorporates state-of-the-art
> technology and resources from medicine, genomics and
> bioinformatics. Thanks to the integration with the GNU Federation, we
> can communicate and share the information we wish with our health
> professionals in real-time.
> 
> You can read the announcement with screenshots from here, as well as
> from GNU.org planet and soon from KDE.org planet.
> 
> https://meanmicio.org/2021/06/24/welcome-to-mygnuhealth-the-libre-personal-health-record/
> 
> Immense gratitude to all of you who, directly or indirectly, have made
> it possible. 
> 
> Let's keep on fighting for freedom, equity and privacy in healthcare
> around the world!

Congrats on the 1.0 release!

Cheers,
  Albert

P.S: For app release announcements we do use 
https://mail.kde.org/mailman/listinfo/kde-announce-apps 

> 
> Happy and healthy hacking
> 
> 

Re: Request for a reviewer to check an article mentioning KDE

[Albert Astals Cid]

El diumenge, 30 de maig de 2021, a les 10:52:11 (CEST), Andy Oram va escriure:
> kde-community@kde.org
> 
> Request for a reviewer to check an article mentioning KDE
> 
> The Linux Professional Institute is going to publish an article on the X
> Window System, and a few paragraphs discuss KDE and GNOME. I'm seeking one
> or two people to check the article for accuracy. The audience for the
> article is students or other people who are interested in free software,
> but who don't have much technical background.
> 
> I could use someone who knows:
> 
> *  The history of KDE itself
> 
> * The much longer history of the X Window System and its technology
> 
> Please reply just to me if this task interests you.

If you don't have any volunteer yet, I can give it a try.

Cheers,
  Albert 

Re: is a BSL licensed service acceptable for sysadminy use cases?

[Albert Astals Cid]

El dimecres, 26 de maig de 2021, a les 16:07:14 (CEST), Harald Sitter va 
escriure:
> Ahoy ahoy
> 
> I do on occasion write behind the scenes micro services for various
> things we need in KDE and usually more specifically neon. It's always
> been a big lament of mine that we don't really have a good way to
> record errors from these services. Gitlab meanwhile has builtin
> support for a piece of software that would allow us to do this: sentry
> [1]. The trouble is that sentry is only kind-of open source [2] and
> consequently there is some concern if we really should use it, even
> though the use case is pretty much exclusively for sysadmin internal
> affairs rather than a service we render to the outside or the wider
> KDE community even. Bhushan and I also looked at similar software but
> found nothing nearly as hot, and of the serviceable stuff I believe
> the best option also had ultimately relied on only kind-of open source
> software (mongodb IIRC).
> 
> What's your thoughts on the subject? Can sysadmins use not-quite-free
> software for internal stuff?

Is this about us writing BSL software or us using BSL software? I think using, 
but want to be sure.

What's the use case of the software? How locked in are we into it?

> 
> Personally I would put forward some arguments pro:
> 
> a) we do already on occasion need to run non-free software to
> facilitate our work. our windows builders for CI and binary factory
> come to mind.

I think this is a bit different "obviously" [*] to create Windows software you 
need to run Windows.

> 
> b) given we want to use this as an extra bit of sugar we'd not rely on
> their service for production or anything. if we decide that we don't
> like it next week we could conceivably just throw it out the window
> again.
> 
> c) I do feel for the developers need to turn a profit so most software
> freedom is better than no freedom in my book

This is a bit of a slippery slope, and makes me a bit sad with it since it 
agrees with the "you can't make money with Free Software" argument.

Cheers,
  Albert

> 
> [1] https://invent.kde.org/help/operations/error_tracking
> [2] 
> https://blog.sentry.io/2019/11/06/relicensing-sentry#enter-the-business-source-license-bsl
> 
> HS

[*] I know mingw, cross compiling i know

Re: On the reappointment of Richard Stallman as a director of the FSF

[Albert Astals Cid]

El dimecres, 31 de març de 2021, a les 22:03:09 CEST, Ingo Klöcker va escriure:
> On Mittwoch, 31. März 2021 21:50:14 CEST Albert Astals Cid wrote:
> > El dijous, 25 de març de 2021, a les 5:33:29 CEST, Alexander Potashev va 
> escriure:
> > > It would be nice to clarify whose opinions this linked message represents.
> > > If this is something that the KDE e.V. Board voted for, then probably a
> > > signature "KDE e.V. Board of Directors" on the bottom of the page would
> > > make sense.
> > 
> > It's in ev.kde.org, who do you think the opinions this linked message
> > represents?
> >
> > Speedy Gonzales?
> 
> No, but it could be the KDE e.V. as a whole (it's not certain it is), it 
> could 
> be the KDE e.V. Board of Directors (as far as I understood, it is), or it 
> could be some other group of KDE e.V. members.

For me, the default assumption if something is in ev.kde.org and has no 
qualification is that the KDE e.V. is saying it.

If it was "some other group of KDE e.V. members" then it would be signed as 
such.

I feel that making a distinction between "KDE e.V. Board of Directors" and "KDE 
e.V." is artificial, the board of directors have been democratically elected to 
talk in name of KDE e.V. 

Cheers,
  Albert

> 
> Regards,
> Ingo
> 

Re: On the reappointment of Richard Stallman as a director of the FSF

[Albert Astals Cid]

El dijous, 25 de març de 2021, a les 5:33:29 CEST, Alexander Potashev va 
escriure:
> Thanks for the effort Aleix!
> 
> It would be nice to clarify whose opinions this linked message represents.
> If this is something that the KDE e.V. Board voted for, then probably a
> signature "KDE e.V. Board of Directors" on the bottom of the page would
> make sense.

It's in ev.kde.org, who do you think the opinions this linked message 
represents? 

Speedy Gonzales?

Cheers,
  Albert

> 
> > Dear community,
> > From the KDE e.V. we followed closely the discussions on the last few
> > days regarding this recent decision within the Free Software
> > Foundation's leadership.
> >
> > We have tried to sum up our thoughts in the following announcement
> > with the hope to foster collectively the Free Software leadership we
> > need.
> > https://ev.kde.org/2021/03/24/on-the-reappointment-of-rms-fsf/
> >
> > Looking forward to a more inclusive discussion that will shape the
> > Free Software movement of tomorrow.
> >
> > Best regards,
> > Aleix Pol with the KDE e.V. Board of Directors
> >
> 

Re: RMS and open letter

[Albert Astals Cid]

El dimarts, 23 de març de 2021, a les 23:11:52 CET, Luis Falcon va escriure:
> On Tue, 23 Mar 2021 19:49:36 +
> Carl Schwan  wrote:
> 
> > Hello all,
> > like you probably heard already RMS was reinstatement to the
> > Board of Directors of the Free Software Foundation. RMS has
> > always been a negative force to the Free Software movement due
> > to his toxic behavior. There is an open letter asking for his
> > and the current board FSF resignation available at
> > https://rms-open-letter.github.io/.
> > 
> 
> This attack against Richard is appalling, and, in my opinion, the
> reflection of the sick society we live in.
> 
> I find disgusting the amount of public mobbing and battering that
> Richard has suffered this past year and a half. Many of the
> brown-nosers who proudly showed pictures with him, now are part of this
> evil campaign.
> 
> You don't have an idea of how much pain these people has inflicted upon
> him. Zero empathy. Not a single case has been filed against him, just
> coward bullying and mobbing. 

Poor guy, he bullied and mobbed and now he is sad because people are fed up of 
his behaviour and rightfully complaining.

> You believe he is guilty, then go to court.

In court? You don't need to do something *criminal* to be considered unfit for 
leading.

> Richard has been a victim of those who could not accept a pure movement
> and philosophy like the Free/Libre Software movement. 

You sound like a conspiracy theorist. This is nothing to do about the 
"pureness" of the Free Software movement, this is about him being of 
questionable character.

> While some of his same-age are now filthy rich by writing proprietary
> code, RMS lives humbly, putting all his time and talent to the benefit
> of the community.

Unless you're women, or trans, or he doesn't like you.

> We can not conceive the Free/Libre Software - and all the benefits that
> brought to society- without Richard. Our projects would not exist today
> without RMS, Founder of the FSF and the GNU project. That is just being
> grateful. 

Hyperbole incoming: If someone invented the cure for all cancers and then went 
and killed 1 million people with his bare hands, he would still be a monster.

Having started Free Software doesn't give you carte blanche to in general being 
a toxic person.

> Finally, I find ironic that the "open letter" to debunk RMS is placed
> on Github, a Microsoft owned company. 
> 
> This puts an end to my discussion on this matter, at least on this
> channel.

Saying "you're wrong, I'm right and i will not discuss this further" has to be 
one of the worst ways ever to try to convince people 

Albert

> 
> 

Re: GCompris and AGPL

[Albert Astals Cid]

El dilluns, 15 de febrer de 2021, a les 20:36:08 CET, Timothée Giet va escriure:
> Hi,
> 
> Last year, in order to create the Analog Electricity activity in
> GCompris, we had to integrate some existing code for the electric
> circuit simulation engine. The code weintegratedis under the AGPLv3
> license...
> 
> First publication of the original code, without any license:
> https://github.com/zupolgec/circuit-simulator/blob/master/js/cktsim.js
> 
> 
> Then it was republished here with the AGPLv3 license:
> https://github.com/edx/edx-platform/blob/master/common/lib/xmodule/xmodule/js/src/capa/schematic.js
> 
> 
> (check https://github.com/zupolgec/circuit-simulator/issues/1
> for the
> licensing history).
> 
> Integration of the code in GCompris:
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/analog_electricity/cktsim.js
> 
> 
> We searched a lot, but this was the only option we found for a JS
> electric simulation engine that would be compatible with QML.
> 
> As the GPLv3 clearly state that combining some AGPLv3 work to it is
> allowed, just the special requirements of the AGPLv3 will apply to the
> resulting package/installer ("the combination as such"), license-wise it
> looks OK.
> 
> This means that now, the binary/package of GCompris has to be released
> under AGPLv3.
> Of course we keep licensing all the rest of our new code under GPLv3+ as
> before, so if at some point we can replace the simulation engine with
> some GPLv3+ code, we can return to releasing our package under this license.
> 
> However, as Albert A. Cid 

Just chiming in to explain how Catalan naming works, my name is

Name: Albert
1st Surname: Astals
2nd Surname: Cid

So I could be abbreviated to Albert, Albert Astals, Albert Astals C., Albert 
A.C., but not Albert A. Cid  

Sorry for the noise :)

Cheers,
  Albert

P.S: It's fine to make honest mistakes, hope y'all not annoyed by my correction

Re: Rebranding the release service

[Albert Astals Cid]

El dilluns, 15 de febrer de 2021, a les 14:01:25 CET, Jonathan Riddell va 
escriure:
> Here at KDE we've always struggled a bit with branding and the announcement
> of formats for the bunch of releases that was originally "KDE" then "KDE
> SC" then "KDE Applications" and at Akademy 2019 we decided to debrand it
> and make it a release service with lots of different stuff in it.  We had
> monthly update announcements that included those releases on the months
> when they happened and otherwise included everything else released over the
> past month.  But the format doesn't seem to have caught on by various
> metrics.  So the promo group had some chat about different formats you can
> read at https://phabricator.kde.org/T14091
> 
> Currently the plan is to reband it probably with the name KDE Gear.

Ouch, y'all ended up liking my silly suggestion ^_^ Sorry about that.

Anyhow, I'm expecting we're not necessarily have to change stuff like branch 
names or RELEASE_SERVICE_VERSION_MAJOR cmake variables to adapt to this promo 
driven change, right?

Cheers,
  Albert

> That
> gets released every 4 months (same as currently) with a big announcement
> for it and everything in it.  It's still a collection of apps and
> supporting libraries with no connection to each other except they happen to
> be KDE projects which don't want to do their own release work.  Then every
> 4 months on the months between times we have an update article highlighting
> all the other stuff that has been released by KDE.  The bugfix releases for
> KDE Gear happen monthly as currently and only have a minimal announcement.
> 
> We hope this format will get some more traction with engagement from
> outside press and social media buzz.  Any comments welcome.
> 
> Jonathan
> 

Re: New Git Hooks Deployed

[Albert Astals Cid]

El diumenge, 17 de gener de 2021, a les 11:07:40 CET, Johnny Jazeix va escriure:
> Hi Ben,
> 
> https://build.kde.org/view/Failing/job/Applications/job/kaccounts-integration/job/kf5-qt5%20SUSEQt5.15/lastFailedBuild/console
> 
> CMake Error at CMakeLists.txt:50 (include):
> include could not find load file:  KDEGitCommitHooks
> 
> Side effect or bad ECM minimal version?

That's kind "a different git hook", what Ben wrote about is something that runs 
on the git server, this error is about something that runs on the developer 
side.

This error is because Nico forgot that kaccounts-integration is not a KDE 
Framework and thus it would be really desirable for it to not depend on an 
unreleased version of extra-cmake-modules for the benefit of all of us that 
don't compile our own KDE Frameworks and just use released versions.

Cheers,
  Albert

> 
> Johnny
> 
> Le dim. 17 janv. 2021 à 05:45, Ben Cooksley  a écrit :
> >
> > Hi Community,
> >
> > This evening we completed the deployment of a significant refactor and 
> > rework of the Git hooks that run on Gitlab (invent.kde.org) each time the 
> > system receives a push.
> >
> > This moves us away from the `update` hook to the `pre-receive` hook, ports 
> > the hooks to Python 3, refactors a number of parts of the hooks to make 
> > them easier to work with and test in the future, and introduces some new 
> > functionality.
> >
> > This new functionality allows for larger changes in certain circumstances 
> > to still be notified in a  summarised manner, ensuring that it is still 
> > possible to monitor changes to code in our repositories even when bulk 
> > imports are taking place from time to time.
> >
> > As the changes were quite invasive, please let us know if you observe any 
> > unusual behaviour.
> >
> > Many thanks,
> > Ben Cooksley
> > KDE Sysadmin
> 

Re: Fundraising in KDE

[Albert Astals Cid]

El diumenge, 27 de setembre de 2020, a les 21:36:46 CEST, Vincent Pinon va 
escriure:
> As KDE eV can't allocate 
> money to a specific project (if I understand correctly)

That's more a "historically has not wanted" than a "legally can't".

It's my hope that with the recent KDE eV board public statements about them 
wanting to help people make out a living out of doing KDE stuff this may change.

Cheers,
  Albert

Re: Fundraising in KDE

[Albert Astals Cid]

El dijous, 24 de setembre de 2020, a les 11:42:16 CEST, Nicolas Fella va 
escriure:
> Hi,
> 
> I would be cautious about creating a system that allows targeted
> donations for specific features/requests. 
> I don't want the e.V. to be in
> a position where work is done/prioritized because it brings in money.

That's one of the reasons why you're part of KDE e.V. To make sure the money is 
spent correctly :)

> Not having this kind of money-driven-development is a great strength of
> community-driven open source projects. 

That's not going away. We already have proof of it. There has always been 
people doing KDE paid development and it has never been a huge issue from my 
almost 20 years of memory collaborating with the project.

> We have a list of possible
> providers for such requests already (disclosure: I work for a company on
> that list).

I disagree, https://ev.kde.org/consultants/ is for "i want to implement X, how 
much it will cost? 20K€? Fine here you have, now do it for me" not for "i have 
100€ a year, please let me pitch in with more people so we can hire a developer 
to work full time on improving Qt for KDE needs".

Cheers,
  Albert

> 
> Cheers
> 
> Nico
> 
> 

Re: Fundraising in KDE

[Albert Astals Cid]

El dimecres, 23 de setembre de 2020, a les 11:10:30 CEST, Boudewijn Rempt va 
escriure:
> KDE probably needs to setup a second legal entity that can fund freelance 
> developers for certain projects or even outright hire them. 

Why do we need a second entity? KDE e.V. is already contracting/hiring people.

Cheers,
  Albert

Re: Fundraising in KDE

[Albert Astals Cid]

El dimecres, 23 de setembre de 2020, a les 0:53:34 CEST, Carl Schwan va 
escriure:
> Hello everyone,
> 
> Nate gave an excellent talk at the Akademy about how we can konquer the world
> and reach new horizons with our software. One of the first steep for Nate is
> for the e.V. to start paying more developers to work on core KDE technologies.

I agree that it would very much be a good idea for KDE to pay developers.

> Many thanks to all these wonderful people donating money to the e.V. but this
> is unfortunately not enough and if we want to start paying developers we will
> need to change our fundraising strategy radically.

Yes, let's not forget that software developers are relatively expensive, I've 
no idea how accurate 
https://www.daxx.com/blog/development-trends/it-salaries-software-developer-trends
 is, but i guess the numbers are not totally wrong from my own experience.

> One of the reasons why we don't raise as many funds as we could is because of
> the failure of our recurring donation system. 

I agree that's one of the reasons, personally i think the lack of clear goals 
is another reason, there's so much money you can get with the "give us money 
because we're nice" message we used in stuff like the end of year campaigns.

I think it's much easier to get people to donate if you give them a more direct 
reason "We're going to hire this person to work on XXX".

> And to achieve this vision, we need to grow, get more people involved, making
> sure that people can make a living by contributing to KDE and also contribute
> to the less fun area of KDE (the thing that nobody cares about but is really
> important like accessibility).

I understand what you were trying to say with this sentence, but please be 
careful when making blanket statements like that, you just insulted everyone 
that cares about accessibility and feels part of KDE by either telling them 
they are not part of KDE or that they don't care enough.

> I believe that if we were to communicate more clearly how by donating, we are
> able to improve our software and moving forward with our vision, it should
> encourage more people to donate.

Agreed.

Cheers,
  Albert

Re: Proposal: Mailing List owner policy

[Albert Astals Cid]

El dimecres, 9 de setembre de 2020, a les 11:00:21 CEST, Ben Cooksley va 
escriure:
> On Wed, Sep 9, 2020 at 7:43 AM Albert Astals Cid  wrote:
> 
> > El dimarts, 25 d’agost de 2020, a les 23:28:28 CEST, Albert Astals Cid va
> > escriure:
> > > So it seems there was some agreement that is something that could
> > improve but we didn't 100% agree on what to do. I've scheduled an Akademy
> > BoF, hopefully we can reach to a conclusion there.
> > >
> > > https://community.kde.org/Akademy/2020/Tuesday#Room_02_-_8th_September
> >
> > Summary of the discussion at https://share.kde.org/s/PeFRH82FmFgDrep
> >
> > I'll start contacting people about doing work for several points probably
> > tomorrow :)
> >
> 
> Thanks for the detailed summary from the BoF Albert, it's appreciated.
> 
> Responding to some of those points with my Sysadmin hat on:
> 
> > Enable archives on all the mailing lists that don't have it enabled
> 
> We should probably look at backfilling the archives for those lists as
> well, given some of them are the older lists that document much of the
> history of the KDE project (and should therefore be as best preserved as
> possible)

Yes we should try backfilling, but what we discussed and agreed is that this 
should not be a blocker.

The more time we go without archives, the more those archives will be 
incomplete.

So if we can't back fill the archives in X time, we just need to accept our 
loses and enable the archives.

> 
> > Where did the archives of the recently disabled/archive mailing lists go?
> Still publicly available?
> 
> These archives should all still be accessible at
> https://mail.kde.org/pipermail/$listname/

Good :)

> 
> > Ask sysadmins if we can have a text file in invent...
> 
> Would it help if we created a team at https://invent.kde.org/teams/ for
> this, to allow you to make use of the snippets/wiki functionality of Gitlab?

This needs more refining, i guess let's create the list of owners first and 
once we have that discuss it there?

Cheers,
  Albert

> 
> 
> > Cheers,
> >   Albert
> >
> 
> Cheers,
> Ben
> 
> 
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > > [1] yes, i know they are not the same, but since one is a subset of
> > the other, let's pretend they are.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> 

Re: Proposal: Mailing List owner policy

[Albert Astals Cid]

El dimarts, 25 d’agost de 2020, a les 23:28:28 CEST, Albert Astals Cid va 
escriure:
> So it seems there was some agreement that is something that could improve but 
> we didn't 100% agree on what to do. I've scheduled an Akademy BoF, hopefully 
> we can reach to a conclusion there.
> 
> https://community.kde.org/Akademy/2020/Tuesday#Room_02_-_8th_September

Summary of the discussion at https://share.kde.org/s/PeFRH82FmFgDrep

I'll start contacting people about doing work for several points probably 
tomorrow :)

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > 
> > Cheers,
> >   Albert
> > 
> > [1] yes, i know they are not the same, but since one is a subset of the 
> > other, let's pretend they are.
> > 
> > 
> > 
> 
> 
> 
> 
> 

Re: Proposal: Mailing List owner policy

[Albert Astals Cid]

El dimecres, 26 d’agost de 2020, a les 3:16:13 CEST, Valorie Zimmerman va 
escriure:
> Unfortunately 9 UTC = 2 am here. But I will submit some notes about it. -v

Then it's a good thing i put it at 17UTC and not 9 UTC ;)

Cheers,
  Albert

> 
> On Tue, Aug 25, 2020 at 2:28 PM Albert Astals Cid  wrote:
> 
> > El dijous, 23 de juliol de 2020, a les 0:31:29 CEST, Albert Astals Cid va
> > escriure:
> > > Dear Community,
> > >
> > > One important part of mailing lists being healthy is
> > owners/moderators[1].
> > >
> > > They moderate the lists, they help users that want to
> > subscribe/unsubscribe but don't know how to, they enact emergency
> > moderation in the very very seldom case that it is needed, etc.
> > >
> > > So to keep our mailing lists healthy we need to be sure to have healthy
> > list owners.
> > >
> > > In plural, more than one, because from time to time, we go on vacation
> > and the list duties still need taking care of.
> > >
> > > For that I'd like to enact this policy:
> > >
> > > Mailing lists should have at least 2 active owners, ideally 3
> > [Obviously exceptions apply, like if we just started a mailing list to
> > coordinate translators for a language that has no translation in KDE yet,
> > we'd probably have no way to get 2 list owners]
> > >
> > > One keyword in that sentence is "active".
> > >
> > > Mailing list ownership/moderation un-activity is hard to detect.
> > >
> > > One way to potentially detect it, is by those summaries that sysadmin
> > sends periodically for lists with lots of mails to moderate, but that
> > doesn't cover all the cases.
> > >
> > > For example, it's possible that a mailing list has 2 owners and only one
> > of them is inactive, since the other one is keeping the list in working
> > condition we don't see it as a problem, but if that person goes on holiday,
> > then it suddenly is.
> > >
> > > For that I'd like to enact this policy sub-point:
> > >
> > > Mailing list owners will be contacted every year asking if they are
> > still active and if they want to continue being list owner or if they'd
> > prefer we find a substitute.
> > >
> > > If they say "please find a substitute" or fail to answer in a given time
> > frame (I'd say a month is fair), they will be removed as owners and in case
> > the "at least 2 active owners, ideally 3" policy is broken we'll find a new
> > person.
> > >
> > > Does that sound something like we could agree on?
> > >
> > > Then the big question is "who will do this work?" Because it seems quite
> > a bit of work (albeit only once a year). I would suggest the Community
> > Working Group does this, as it's a way to keep our community healthy, but i
> > understand it's quite some work, so i volunteer to do it if the CWG doesn't
> > feel this is a task they want to take on.
> > >
> > > Things I'm missing?
> > >
> > > Improvement suggestions?
> >
> > So it seems there was some agreement that is something that could improve
> > but we didn't 100% agree on what to do. I've scheduled an Akademy BoF,
> > hopefully we can reach to a conclusion there.
> >
> > https://community.kde.org/Akademy/2020/Tuesday#Room_02_-_8th_September
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > > [1] yes, i know they are not the same, but since one is a subset of the
> > other, let's pretend they are.
> > >
> > >
> > >
> >
> >
> >
> >
> >
> 
> 

Re: Proposal: Mailing List owner policy

[Albert Astals Cid]

El dijous, 23 de juliol de 2020, a les 0:31:29 CEST, Albert Astals Cid va 
escriure:
> Dear Community,
> 
> One important part of mailing lists being healthy is owners/moderators[1].
> 
> They moderate the lists, they help users that want to subscribe/unsubscribe 
> but don't know how to, they enact emergency moderation in the very very 
> seldom case that it is needed, etc.
> 
> So to keep our mailing lists healthy we need to be sure to have healthy list 
> owners.
> 
> In plural, more than one, because from time to time, we go on vacation and 
> the list duties still need taking care of.
> 
> For that I'd like to enact this policy:
>   
> Mailing lists should have at least 2 active owners, ideally 3 [Obviously 
> exceptions apply, like if we just started a mailing list to coordinate 
> translators for a language that has no translation in KDE yet, we'd probably 
> have no way to get 2 list owners]
> 
> One keyword in that sentence is "active".
> 
> Mailing list ownership/moderation un-activity is hard to detect.
> 
> One way to potentially detect it, is by those summaries that sysadmin sends 
> periodically for lists with lots of mails to moderate, but that doesn't cover 
> all the cases.
> 
> For example, it's possible that a mailing list has 2 owners and only one of 
> them is inactive, since the other one is keeping the list in working 
> condition we don't see it as a problem, but if that person goes on holiday, 
> then it suddenly is.
> 
> For that I'd like to enact this policy sub-point:
> 
> Mailing list owners will be contacted every year asking if they are still 
> active and if they want to continue being list owner or if they'd prefer we 
> find a substitute.
> 
> If they say "please find a substitute" or fail to answer in a given time 
> frame (I'd say a month is fair), they will be removed as owners and in case 
> the "at least 2 active owners, ideally 3" policy is broken we'll find a new 
> person.
> 
> Does that sound something like we could agree on?
> 
> Then the big question is "who will do this work?" Because it seems quite a 
> bit of work (albeit only once a year). I would suggest the Community Working 
> Group does this, as it's a way to keep our community healthy, but i 
> understand it's quite some work, so i volunteer to do it if the CWG doesn't 
> feel this is a task they want to take on. 
> 
> Things I'm missing?
> 
> Improvement suggestions?

So it seems there was some agreement that is something that could improve but 
we didn't 100% agree on what to do. I've scheduled an Akademy BoF, hopefully we 
can reach to a conclusion there.

https://community.kde.org/Akademy/2020/Tuesday#Room_02_-_8th_September

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> [1] yes, i know they are not the same, but since one is a subset of the 
> other, let's pretend they are.
> 
> 
> 

Re: Proposal: Recurring donations - increase flexibility

[Albert Astals Cid]

El dimecres, 29 de juliol de 2020, a les 19:06:34 CEST, XYQuadrat va escriure:
> Hello everyone,
> 
> Let me preface this email that I do not have a lot of background 
> knowledge on the monetary policies of KDE and therefore my proposal 
> might be not sensible at all.
> 
> For individuals who want to support KDE on a regular basis, we have the 
> "Join the game!" initiative (see https://relate.kde.org).
> Currently, there is only the option to pay 100€ on a yearly basis or 
> split those 100€ into 25€ on a quarterly basis.
> In my opinion, this is a rather strict and inflexible concept. Regular 
> donations lead to a more consistent source of donation income since they 
> fluctuate much less than one-time donations.
> I therefore believe that it would be beneficial to allow people to 
> donate less/more on a regular basis.
> 
> One option is to simply allow anyone to donate a customizable amount per 
> year (with some minimal amount of say 10€), instead of the fixed 100€.
> 
> Another option would be to introduce the by now often used concept of 
> tiers - fixed amounts that then grant some small benefit such as being 
> named on a KDE website, receiving a small "Thank You" card or similar.
> These tiers would then cover a wider range of amounts (e.g. 10€ - 50 € - 
> 100 € - 250€ - 500€).
> 
> What do people think about this? (Of course, in the end this requires 
> approval of the board. But I think this shouldn't be all too 
> controversial of a change.)

This was voted and approved by the KDE eV membership assembly a while ago, it's 
just that it is not as easy to implement as we would like and thus it still has 
not happened.

Cheers,
  Albert

> 
> Best regards,
> Julian / xyquadrat
> 
> 

Re: Proposal: Mailing List owner policy

[Albert Astals Cid]

El dijous, 23 de juliol de 2020, a les 23:49:23 CEST, Valorie Zimmerman va 
escriure:
> I had another thought hours after I sent my reply to Albert. What if we
> create a list for KDE listowners to which all listowners and mods are
> subscribed? That way we can approach issues as a team, share resources and
> problems, ask one another for coverage during planned absences, etc.
> 
> We had a list like this at Rootsweb, a free genealogy community, and it
> generally worked well. RW also used Mailman software before closing the
> lists recently. I've moved most of my former lists to Groups.io which is a
> splendid platform. I very much wish it was Free software!
> 
> It seems like a lits would be a more stable way to approach the issue than
> an annual inquiry email.
> 
> Thoughts?

I think a listowners list may be interesting to explore, but i don't see how it 
solves the "3 of the 4 list owners of okular-devel have gone away" problem.

We still need to ping them, don't we?

Cheers,
  Albert

> 
> Valorie
> 
> On Thu, Jul 23, 2020 at 1:38 AM Ben Cooksley  wrote:
> 
> > On Thu, Jul 23, 2020 at 4:55 PM Valorie Zimmerman
> >  wrote:
> > >
> > > On Wed, Jul 22, 2020 at 3:31 PM Albert Astals Cid  wrote:
> > >>
> > >> Dear Community,
> > >>
> > >> One important part of mailing lists being healthy is
> > owners/moderators[1].
> > >>
> > >> They moderate the lists, they help users that want to
> > subscribe/unsubscribe but don't know how to, they enact emergency
> > moderation in the very very seldom case that it is needed, etc.
> > >>
> > >> So to keep our mailing lists healthy we need to be sure to have healthy
> > list owners.
> > >>
> > >> In plural, more than one, because from time to time, we go on vacation
> > and the list duties still need taking care of.
> > >>
> > >> For that I'd like to enact this policy:
> > >>
> > >> Mailing lists should have at least 2 active owners, ideally 3
> > [Obviously exceptions apply, like if we just started a mailing list to
> > coordinate translators for a language that has no translation in KDE yet,
> > we'd probably have no way to get 2 list owners]
> > >>
> > >> One keyword in that sentence is "active".
> > >>
> > >> Mailing list ownership/moderation un-activity is hard to detect.
> > >>
> > >> One way to potentially detect it, is by those summaries that sysadmin
> > sends periodically for lists with lots of mails to moderate, but that
> > doesn't cover all the cases.
> > >>
> > >> For example, it's possible that a mailing list has 2 owners and only
> > one of them is inactive, since the other one is keeping the list in working
> > condition we don't see it as a problem, but if that person goes on holiday,
> > then it suddenly is.
> > >>
> > >> For that I'd like to enact this policy sub-point:
> > >>
> > >> Mailing list owners will be contacted every year asking if they are
> > still active and if they want to continue being list owner or if they'd
> > prefer we find a substitute.
> > >>
> > >> If they say "please find a substitute" or fail to answer in a given
> > time frame (I'd say a month is fair), they will be removed as owners and in
> > case the "at least 2 active owners, ideally 3" policy is broken we'll find
> > a new person.
> > >>
> > >> Does that sound something like we could agree on?
> > >
> > >
> > > I think this is a good idea.
> > >
> > >> Then the big question is "who will do this work?" Because it seems
> > quite a bit of work (albeit only once a year). I would suggest the
> > Community Working Group does this, as it's a way to keep our community
> > healthy, but i understand it's quite some work, so i volunteer to do it if
> > the CWG doesn't feel this is a task they want to take on.
> > >
> > >
> > > As a member of CWG, I think that this is a suitable task for us, and I'm
> > willing to do it. However, surely there is a master list of all the lists
> > and who the stated owners and mods are. If so, can't the sending be done
> > somewhat automatically? With the answers going to the CWG or whoever, to
> > find replacement people.
> > >
> >
> > You'd need a way of catching the exceptions - the people who don't reply
> > though.
> > Not sure how easy that would be to automate, but it's 

Proposal: Mailing List owner policy

[Albert Astals Cid]

Dear Community,

One important part of mailing lists being healthy is owners/moderators[1].

They moderate the lists, they help users that want to subscribe/unsubscribe but 
don't know how to, they enact emergency moderation in the very very seldom case 
that it is needed, etc.

So to keep our mailing lists healthy we need to be sure to have healthy list 
owners.

In plural, more than one, because from time to time, we go on vacation and the 
list duties still need taking care of.

For that I'd like to enact this policy:

Mailing lists should have at least 2 active owners, ideally 3 [Obviously 
exceptions apply, like if we just started a mailing list to coordinate 
translators for a language that has no translation in KDE yet, we'd probably 
have no way to get 2 list owners]

One keyword in that sentence is "active".

Mailing list ownership/moderation un-activity is hard to detect.

One way to potentially detect it, is by those summaries that sysadmin sends 
periodically for lists with lots of mails to moderate, but that doesn't cover 
all the cases.

For example, it's possible that a mailing list has 2 owners and only one of 
them is inactive, since the other one is keeping the list in working condition 
we don't see it as a problem, but if that person goes on holiday, then it 
suddenly is.

For that I'd like to enact this policy sub-point:

Mailing list owners will be contacted every year asking if they are still 
active and if they want to continue being list owner or if they'd prefer we 
find a substitute.

If they say "please find a substitute" or fail to answer in a given time frame 
(I'd say a month is fair), they will be removed as owners and in case the "at 
least 2 active owners, ideally 3" policy is broken we'll find a new person.

Does that sound something like we could agree on?

Then the big question is "who will do this work?" Because it seems quite a bit 
of work (albeit only once a year). I would suggest the Community Working Group 
does this, as it's a way to keep our community healthy, but i understand it's 
quite some work, so i volunteer to do it if the CWG doesn't feel this is a task 
they want to take on. 

Things I'm missing?

Improvement suggestions?

Cheers,
  Albert

[1] yes, i know they are not the same, but since one is a subset of the other, 
let's pretend they are.

Re: Introducing KDE Activity Filter

[Albert Astals Cid]

El diumenge, 12 de juliol de 2020, a les 8:08:11 CEST, Ben Cooksley va escriure:
> Hi all,
> 
> A few years back Sysadmin had to turn off the old Commit Filter
> service due to a number of security issues, with no replacement
> available.
> 
> I'm now happy to announce that a replacement service is now available,

Very much appreciated! Now i can stop using ifttt :)

> with the added functionality of also being able to cover activity on
> Bugzilla and Gitlab (for Tasks and Merge Requests). It is intended
> that Activity Filter will be used to provide Gitlab notifications for
> merge requests and tasks to mailing lists, along with CI notifications
> if desired (once that is moved to Gitlab)
> 
> The new service is configured through YAML format files in the
> sysadmin/activityfilter repository
> (https://invent.kde.org/sysadmin/activityfilter), which is open to
> developers to commit. Please ensure that you read the README contained
> in the repository before doing so.
> 
> Please let us know if you have any questions on the above!

Can i do stuff like this?

- name: "Commits"
  subscribes: "aa...@kde.org"
  to: commits
  where:
project: 'bla'
project: 'bla1'
project: 'bla2'
project: 'bla3'
project: 'bla4'
project: 'bla5'
project: 'bla6'
project: 'bla7'
project: 'bla8'

?

Cheers,
  Albert


> 
> Thanks,
> Ben Cooksley
> KDE Sysadmin
> 

Re: KDE Developer portal

[Albert Astals Cid]

El diumenge, 12 de juliol de 2020, a les 17:39:51 CEST, Albert Astals Cid va 
escriure:
> El diumenge, 12 de juliol de 2020, a les 0:28:58 CEST, Carl Schwan va 
> escriure:
> > Hello everyone,
> > 
> > I experiment with creating such a developer portal for KDE using the static 
> > site generator Hugo and the docsy theme. The result with a few converted 
> > articles can be seen here: http://kde.carlschwan.eu/docs/.
> > 
> > So my question now to the community is the effort worth it? 
> 
> I think having a clean startup page for developers is good and will 
> potentially  

will potentially help us get more developers.

Cheers,
  Albert

P.S: Sorry trying to do too many things at the same time

> 
> The problem with techbase is that it's a wiki, which is great for lots of 
> things, but it will never look "amazing" because it has to provide all the 
> stuff wikis provide, so using a different platform makes some kind of sense 
> to me.
> 
> So +2 from my side for "is the effort worth it" :)
> 
> Cheers,
>   Albert
> 
> 
> 

Re: KDE Developer portal

[Albert Astals Cid]

El diumenge, 12 de juliol de 2020, a les 0:28:58 CEST, Carl Schwan va escriure:
> Hello everyone,
> 
> I experiment with creating such a developer portal for KDE using the static 
> site generator Hugo and the docsy theme. The result with a few converted 
> articles can be seen here: http://kde.carlschwan.eu/docs/.
> 
> So my question now to the community is the effort worth it? 

I think having a clean startup page for developers is good and will potentially 
 

The problem with techbase is that it's a wiki, which is great for lots of 
things, but it will never look "amazing" because it has to provide all the 
stuff wikis provide, so using a different platform makes some kind of sense to 
me.

So +2 from my side for "is the effort worth it" :)

Cheers,
  Albert

Re: KDE Apps name trademarks

[Albert Astals Cid]

El dimecres, 8 de juliol de 2020, a les 20:54:13 CEST, Martin Floeser va 
escriure:
> Am 2020-07-08 20:45, schrieb Jack:
> > On 2020.07.08 14:20, Ben Cooksley wrote:
> >> On Thu, Jul 9, 2020 at 6:09 AM Christoph Cullmann
> >>  wrote:
> >> >
> >> > On 2020-07-08 18:12, Jonathan Riddell wrote:
> >> > > Recently we've noticed some KDE apps ending up on the Microsoft
> >> Store
> >> > > uploaded by unknown third parties.  Maybe to up some credit score
> >> for
> >> > > their developer account.  Maybe to install bitcoin  miners.  We
> >> don't
> >> > > know the motivations.  Since it's all free software the licence
> >> allows
> >> > > it.
> >> >
> >> > Hi,
> >> >
> >> > have you some links to these applications?
> >> 
> >> I believe Jonathan will be referring to
> >> https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab#
> > If I follow that link, and click for the US version, I see KDiff3 for
> > sale at $4.99.  Does the license actually allow charging?  (I wonder
> > how that is split between MS and the uploader.)
> 
> GPLv3 Section 6 d
> "Convey the object code by offering access from a designated place 
> (gratis or for a charge), and offer equivalent access to the 
> Corresponding Source in the same way through the same place at no 
> further charge. "
> 
> So yes, charging is fine, not providing the source code looks to me like 
> a GPL violation. And I think that puts the ball to KDE e.V. board to 
> contact Microsoft.

AFAIU the source code only needs to be provided to those that the binary is 
provided, so someone needs to buy it first to see if they are providing the 
source code or not.

Cheers,
  Albert

> 
> Cheers
> Martin
> 

Re: auto-comment on bugzilla when making an MR?

[Albert Astals Cid]

El dimarts, 16 de juny de 2020, a les 12:54:07 CEST, Harald Sitter va escriure:
> Tech that automatically mentioned MRs on bugs has been rolled out and
> seems to be working nicely. CCBUG: only mentions the MR while BUG:
> also marks the bug ASSIGNED. Enjoy.

Doest it leave the assignee filed unchanged?

Cheers,
  Albert

> 
> HS
> 

Re: The KDEPIM / Akonadi situation

[Albert Astals Cid]

El divendres, 12 de juny de 2020, a les 23:54:19 CEST, Ben Cooksley va escriure:
> On Sat, Jun 13, 2020 at 7:49 AM Andras Mantia  wrote:
> >
> > Hey,
> 
> Hi all,
> 
> >
> >  don't want to add much as I'm not active anymore and have my share of
> fault
> > for not fixing certain bugs, but I'd like to reply to only one thing...
> >
> > On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote:
> > > 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.
> >
> > Sorry if you had bad experience, not sure what happened, but I can assure
> that
> > most (or rather: all) developers I worked with in the PIM area were nice
> and
> > friendly.
> 
> They are however, terrible at reading emails from the CI system. To the
> point I suspect they have filters sending such mail to the trash so it is
> never seen.
> 
> Akonadi has been in a broken state for several days now on FreeBSD. They
> have received multiple notices of this to their mailing list, and yet no
> action has been taken.
> 
> Because other software outside of PIM depends on Akonadi, the dependency
> builds for the CI system are unable to successfully finish (failing in
> Akonadi), meaning the CI system is now effectively unmaintainable on
> FreeBSD.
> 
> Continued builds for software in Extragear and Release Service are
> therefore currently dependent on the Binary Compatibility of the system not
> being broken.
> 
> Should anything happen to affect that then all of those builds will cease
> to work and be unfixable. That is a situation that I find fundamentally
> unacceptable.
> 
> This type of issue has come up numerous times before, and is one that the
> PIM developers have failed to address.
> 
> I'm therefore at a loss for options going forward and think that the only
> reasonable and viable solution in the long run will be to blacklist Akonadi
> from the CI system, and remove CI builds for everything with a hard
> dependency on it, including all of KDE PIM.

On the other hand maybe we just need to accept that we don't have enough people 
that care about FreeBSD and just remove the akonadi+dependants-FreeBSD builds 
and not the all the Akonadi+dependants builds.

Cheers,
  Albert

> 
> >
> > Andras
> >
> >
> 
> Regards,
> Ben
> 

Re: Discontinuing legacy infrastructure

[Albert Astals Cid]

El dijous, 11 de juny de 2020, a les 11:11:48 CEST, Ben Cooksley va escriure:
> Hi all,
> 
> 2) CGit has been discontinued
> 
> The CGit instance previously available at cgit.kde.org has now been
> shutdown and is no longer available. All repository browsing should
> now take place via Gitlab at https://invent.kde.org/

Could we make cgit.kde.org/* redirect to https://invent.kde.org/ (just the 
homepage)

I guess there's a zillion links to cgit.kde.org out there, and i guess it'd be 
good that at least they're not left totally dangling.

Cheers,
  Albert

Re: Information regarding upcoming Gitlab Migration: clarifications

[Albert Astals Cid]

El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> >
> > > We have made a big fuss in the past about having different projects
> > > that do the same thing and now we'll have that but also we'll have
> > > several projects with the same name?
> > > It really feels off to me and I wonder if this is related to the move to
> > > gitlab.
> >
> > +1 to both sentiments - that projects should have different names and that
> > this is a bit off topic for the gitlab migration.
> 
> The projects *DO* have very different names. That *HAS NOT* changed.
> To use the example Bhushan gave above, one is called Plasma Mobile
> Dialer and the other one is called Maui Dialer.
> 
> With the current git.kde.org setup, we have a flat namespace, so all
> repositories if the name appears to be generic (as dialer is) have to
> be namespaced by prefixing of the repository name.
> 
> With Gitlab however we will now namespaces that group repositories,
> making the prefixing unnecessary and as some projects have complained
> about, duplicative.
> 
> Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> path, which just looks silly.

Am I the only person that just has all the repos on the same folder? I thought 
it was the common thing to do :?

Cheers,
  Albert

> 
> >
> > Cheers,
> > Ivan
> >
> >
> 
> Regards,
> Ben
> 
> >
> > --
> > dr Ivan Čukić
> > i...@cukic.co, https://cukic.co/
> > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
> >
> >
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure:
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
> 
> Hello Community members,
> 
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
> 
> We had multiple options,
> 
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> 
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
> 
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
> 
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
> 
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.

Anything that breaks kde:$repo will break the release-tools used for the 
monthly releases done by the release service and the l10n scripty scripts.

If it ends up happening it would be good if such change is as far away as 
possible from a release so the scripts can be adapted timely and hopefully 
without mistakes.

Cheers,
  Albert

> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > >
> > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > replies]
> > > >
> > > > Hello Community members,
> > > >
> > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > the recommended structuring for the repositories on Gitlab.
> > > >
> > > > We had multiple options,
> > > >
> > > > - Flat structure: In this option we would have everything under one
> > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > - Subgroups under top-level group: In this option we would have a groups
> > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > - Groups at top level: In this option we would establish a series of
> > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > We have discussed this with small but representative group of
> > > > contributors or maintainers, and based on their suggestions, we
> > > > recommend that we go with option 3. Having sub-groups at top level will
> > > > allow us to,
> > > >
> > > > - Provides good visibility on all reviews, tasks and other items within
> > > > the groups/modules we define
> > > > - Provides improvements to discoverability of projects
> > > > - Makes it possible for groups of projects to establish a group level
> > > > task board should it fit their needs (for tracking a release for
> > > > instance)
> > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > kde.org.
> > > > - The discoverability of projects is maximised, as there is no need to
> > > > open the top level ‘KDE’ group before going into the subgroup.
> > > >
> > > > I've worked on draft "move" of the current set of the repositories in
> > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > You can browse the directory structure to get idea of how final
> > > > structure on Gitlab would look like.
> > > >
> > > > If we don't have any objections we would like to implement this next
> > > > week and move projects to https://invent.kde.org.
> > > >
> > > > Thanks!
> > > > Bhushan for sysadmin team
> > > >
> > > > [1] 
> > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > >
> > > Does this mean that to clone it we'll have to go "git clone
> > > kde:games/knetwalk" or something along the lines?
> > >
> > > If that's the case I'd much prefer if we didn't do this, at the moment
> > > it's already uncomfortable for me to remember the URL for some of the
> > > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > > problem and I personally don't see the advantage.
> > >
> > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> > > krita graphics or its own thing?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

But they have gitlab search, don't they?

I mean it's the solution you told Aleix to figure out if Okular was inside 
graphics or okular.

Why is search valid for one case and not for the other?

Cheers,
  Albert

> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.
> 
> >
> > Best regards,
> > Olivier
> > > Aleix
> >
> >
> 
> Cheers,
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure:
> In part I am mostly re-iterating what Ben already mentioned in different
> messages.
> 
> On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> > Does this mean that to clone it we'll have to go "git clone
> > kde:games/knetwalk" or something along the lines?
> 
> Yes
> 
> [Rest of message is with sysadmin hat off and as a developer]
> 
> > If that's the case I'd much prefer if we didn't do this, at the moment
> > it's already uncomfortable for me to remember the URL for some of the
> > repos (e.g. is it sysadmin/ or not?), this will only increase the
> > problem and I personally don't see the advantage.
> 
> I do agree that it maybe small inconvience, but let's be honest, most of
> us have been using kdesrc-build or some kind of automated tooling for
> building everything, apart from very rare case we never have to manually
> clone any of KDE repository, at least it is true for me personally. I am
> not sure about others.

Please let's refrain from saying things like "most of us have been using 
kdesrc-build" when you don't have any data to back that up.

Cheers,
  Albert

Re: New planet KDE

[Albert Astals Cid]

El dijous, 12 de març de 2020, a les 15:19:26 CET, Carl Schwan va escriure:
> Hello everyone,
> 
> A new version of planet.kde.org is now available. From a technical point of 
> view,
> this is a migration form the rawdog planet agregator to the pluto engine and 
> also
> reuse the Jekyll theme used in various other KDE website.
> 
> The new Planet offers a bigger selection of language and more languages can 
> be easily
> added if needed. Each language also has a specific atom.xml feed: e.g.
> https://planet.kde.org/ca/atom.xml/, so it's possible to follow only post in 
> one
> specific language.
> 
> Another improvement of the new version is that it's easier to read on a mobile
> phone, since the videos and iframes shouldn't get larger than the screen 
> width anymore.

Two more small things:
 * There's no list of aggregated people, i used that from time to time
 * The "To have your blog added to this aggregator, please read the 
instructions" feels like it has been given a too prominent place, i mean it's 
almost the first thing in there, but it targets 0.01% of the readers of that 
page?

Cheers,
  Albert

P.S: Yes i invented that 0.01% number ;)

> 
> A huge thanks for Ben for his help in deploying the new website and to 
> Stasiek Michalski
> for his work on planet-test.opensuse.org and helping me adapting his work for 
> KDE.
> 
> The repository is now available in invent: 
> https://invent.kde.org/websites/planet-kde-org
> with updated instructions how to add your feed to the Planet and how to setup
> a developement environment.
> 
> 
> Regards,
> Carl
> 
> 
> PS: There are still tons of blog not using https. It's very easy to setup 
> let's encrypt
> nowadays for free, so I really recommand you to spend the 10 minutes to set 
> it up and
> then update your feed url in the planet configuration.
> 

Re: New planet KDE

[Albert Astals Cid]

El dijous, 12 de març de 2020, a les 15:19:26 CET, Carl Schwan va escriure:
> Hello everyone,
> 
> A new version of planet.kde.org is now available. From a technical point of 
> view,
> this is a migration form the rawdog planet agregator to the pluto engine and 
> also
> reuse the Jekyll theme used in various other KDE website.
> 
> The new Planet offers a bigger selection of language and more languages can 
> be easily
> added if needed. Each language also has a specific atom.xml feed: e.g.
> https://planet.kde.org/ca/atom.xml/, so it's possible to follow only post in 
> one
> specific language.

Not being able to see multiple languages at the same time (on the webpage, i 
don't care for RSS) is a severe regression for me, any chance that can be fixed?

Cheers,
  Albert

> 
> Another improvement of the new version is that it's easier to read on a mobile
> phone, since the videos and iframes shouldn't get larger than the screen 
> width anymore.
> 
> A huge thanks for Ben for his help in deploying the new website and to 
> Stasiek Michalski
> for his work on planet-test.opensuse.org and helping me adapting his work for 
> KDE.
> 
> The repository is now available in invent: 
> https://invent.kde.org/websites/planet-kde-org
> with updated instructions how to add your feed to the Planet and how to setup
> a developement environment.
> 
> 
> Regards,
> Carl
> 
> 
> PS: There are still tons of blog not using https. It's very easy to setup 
> let's encrypt
> nowadays for free, so I really recommand you to spend the 10 minutes to set 
> it up and
> then update your feed url in the planet configuration.
> 

Re: Regarding KDE Privacy policy

[Albert Astals Cid]

El dimarts, 25 de febrer de 2020, a les 18:47:16 CET, Nate Graham va escriure:
> I find myself in agreement.
> 
> I have access to the kuserfeedback data and to be honest I'm rather 
> dissatisfied with its actionability. There's nothing detailed like "x 
> percentage of users change the default wallpaper" or "y percentage of 
> users switch to double-click" that we could actually use to inform our 
> UI design--let alone anything that could be used to personally identify 
> anyone. The actual data set is so tame and uninteresting that I agree 
> that we could change our policy and release the stats just to show 
> everyone that we have nothing to hide.

You can log anything you want, if you think knowing users that have non default 
wallpapers or that switch to double click, log that.

Cheers,
  Albert

> 
> Nate
> 
> 
> 
> On 2/25/20 5:44 AM, Veggero Nylo wrote:
> > Hi!
> > Currently, data transmitted by KUserFeedback is available only by 
> > opening a sysadmin ticked explaining why you need access in the 
> > first place. I can see the reasoning behind this, but I do not think 
> > this is a good idea for developers and users. I think that releasing the 
> > aggregated data under CC0 license would be better, as also proposed by 
> > Martin here: 
> > https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I think 
> > this would benefit user trust, as right now they have to trust what the 
> > KUserFeedback KCM without really being able to see what data KDE 
> > developers are actually able to see (as most users won't be able to look 
> > into the code); on the other hand, if the data was publicly released, 
> > they would be able to see the data themselves and know exactly what 
> > developers are going to see. I also think this would benefit developers, 
> > as there might be a significant number of developers who could be 
> > interested in looking to the data, maybe just a single value, without 
> > being able to fully justify access to all the data (the fact that you 
> > have to write a justification becomes a negative factor that makes 
> > looking at the data less interesting); furthermore, even if they get 
> > access to the data, they would be unable to discuss it in KDE 
> > communication channels as those are public, nor on phabricator tasks to 
> > support their patches, effectively making the data much less useful. 
> > Also, the current policy might result in a privacy problem, e.g.: I once 
> > needed data from stats.kde.org  regarding website 
> > views over time. I was granted access to it, and I now can see every 
> > singe website viewer, with their country, OS, browser, etc - much more 
> > than I actually needed. If the aggregated data was to be released 
> > publicly, I would no longer need for stats.kde.org 
> >  access, and I would no longer be able to access 
> > private data that I did not actually need. Finally, I do not fully 
> > understand why the data needs to be kept private in the first place, 
> > since it is supposed to be anonymous and contain no user content.
> > What's your opinion on this?
> > ~ Niccolò Venerandi (aka veggero/niccolove)
> 
> 

Re: KDE e.V. Community Report for 2018 available

[Albert Astals Cid]

El dimecres, 27 de novembre de 2019, a les 20:05:51 CET, Aleix Pol va escriure:
> Dear KDE community,
> Some of you already saw it at Akademy, but we wanted to make sure that
> you were all aware of all the great things we did last year 2018
> 
> https://ev.kde.org/reports/ev-2018/
> 
> Please take a look and share far and wide!

Could you please add a news item to https://ev.kde.org/news.php ?

Cheers,
  Albert

> 
> Best regards,
> Aleix Pol i Gonzalez, KDE e.V. President
> 

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dilluns, 18 de novembre de 2019, a les 13:34:19 CET, Harald Sitter va 
escriure:
> And lastly, fold the i18n data into the yaml. 

So to know which is the stable i18n branch of okular i have to checkout it's 
master branch, read a file and then change to whatever branch it is said there 
to be the stable branch?

Feels a bit weird that the master branch has that kind of knowledge to be 
honest.

Cheers,
  Albert

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dissabte, 16 de novembre de 2019, a les 10:14:15 CET, Ben Cooksley va 
escriure:
> On Sat, Nov 16, 2019 at 3:58 PM Alexander Potashev  
> wrote:
> >
> > пт, 15 нояб. 2019 г. в 22:05, Ben Cooksley :
> > >
> > > On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev  
> > > wrote:
> > > >
> > > > пт, 15 нояб. 2019 г. в 15:46, Harald Sitter :
> > > > >
> > > > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev 
> > > > >  wrote:
> > > > > >
> > > > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley :
> > > > > > > In the category of no longer in use, we have the compatibility
> > > > > > > generator for the kde_projects.xml file. This was introduced when 
> > > > > > > we
> > > > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a 
> > > > > > > way of
> > > > > > > keeping services that needed to discover a list of KDE Projects
> > > > > > > functional.
> > > > > > >
> > > > > > > As we've since migrated to using YAML files within the
> > > > > > > sysadmin/repo-metadata repository for both the CI System and
> > > > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > > > > checkouts) there shouldn't to my knowledge be anything still 
> > > > > > > relying
> > > > > > > on this (aside from perhaps scripty).
> > > > > > >
> > > > > > > I'd therefore like to shut this generator down as well, along 
> > > > > > > with the
> > > > > > > compaibility redirector running at projects.kde.org (given that 
> > > > > > > it has
> > > > > > > been some time since we were using that site, and many projects 
> > > > > > > have
> > > > > > > moved around in the virtual structure since then, making the 
> > > > > > > redirects
> > > > > > > it is able to offer useless)
> > > > > >
> > > > > > Hi Ben,
> > > > > >
> > > > > > I am developing a new version of the "opensrc" plugin for Lokalize 
> > > > > > [1]
> > > > > > and it currently depends on kde_projects.xml. Of course I can add 
> > > > > > new
> > > > > > code to scan the Git repo instead of just fetching kde_projects.xml,
> > > > > > however it would be more complicated.
> > > > >
> > > > > https://projects.kde.org/api/doc/ specifically deals with this problem
> > > > > by abstracting the repo away behind a micro service.
> > > >
> > > > This looks like another view of the data available in
> > > > kde_projects.xml, however the API is very limited. For example I can't
> > > > query repo descriptions using this API. Thus not helpful.
> > > >
> > > > However if we were going to kill kde_projects.xml, are you sure
> > > > projects.kde.org/api/ would be still available and not shut down as
> > > > well?
> > >
> > > The API that Harald mentions is based off the YAML files, and is not
> > > reliant on the legacy kde_projects.xml file.
> >
> > I can implement kde_projects.xml or a modernized version of it as part
> > of projects.kde.org/api/. Does this sound like a good idea?
> >
> > We don't need to support the exact same XML format, so I would prefer
> > a JSON listing all projects with all their properties, at something
> > like GET https://projects.kde.org/api/v1/export or may be return all
> > project properties in GET https://projects.kde.org/api/v1/projects
> 
> I'll leave it to Harald to comment on whether he'd be happy having
> additional capabilities in the Projects Microservice API he maintains.
> (Harald, I assume it's only requirement is a copy of the
> sysadmin/repo-metadata repository locally, and it doesn't require the
> actual Git repositories?)
> 
> We really should avoid continuing to keep legacy endpoints alive
> though (as it is just shifting the maintenance effort of porting away
> from it further down the road), especially for something that is going
> to end up on end user systems.

Wait, are you saying we shouldn't be using that endpoint to solve our 
dependency on kde_projects.xml on scripty either?

I just asked Adrián to have a look at it, since it seemed easier than having to 
worry about downloading and keeping an up to date copy of another repo.

Cheers,
  Albert

> 
> On that note, should you be using QNetworkAccessManager, please ensure
> you forcibly and explicitly enable handling of redirects.
> 
> >
> > --
> > Alexander Potashev
> 
> Cheers,
> Ben
> 

Re: Reducing the load on Sysadmin

[Albert Astals Cid]

El dimecres, 13 de novembre de 2019, a les 23:48:02 CET, Albert Astals Cid va 
escriure:
> El dilluns, 11 de novembre de 2019, a les 10:30:09 CET, Ben Cooksley va 
> escriure:
> > When assessing paste.kde.org, it was noted that we already had a
> > direct replacement for this, in the form of Snippets in Gitlab. As we
> > get this for free as part of running Gitlab, it means that the benefit
> > of running a separate Pastebin service now drops to effectively zero.
> 
> The only use i had for paste.kde.org which was sharing encrypted tests with N 
> people is now gone, but fair enough I guess i was one of the few people using 
> that specific part of the service.

s/tests/text

Sorry LinuxAppSummit organizing is draining my brain

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> 
> 

Re: Reducing the load on Sysadmin

[Albert Astals Cid]

El dilluns, 11 de novembre de 2019, a les 10:30:09 CET, Ben Cooksley va 
escriure:
> When assessing paste.kde.org, it was noted that we already had a
> direct replacement for this, in the form of Snippets in Gitlab. As we
> get this for free as part of running Gitlab, it means that the benefit
> of running a separate Pastebin service now drops to effectively zero.

The only use i had for paste.kde.org which was sharing encrypted tests with N 
people is now gone, but fair enough I guess i was one of the few people using 
that specific part of the service.

Cheers,
  Albert

Re: General Infrastructure Maintainability: API and EBN

[Albert Astals Cid]

El diumenge, 10 de novembre de 2019, a les 1:48:10 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 11:20 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 22:03:37 CET, Ben Cooksley va 
> > escriure:
> > > On Sun, Nov 10, 2019 at 9:29 AM Alexander Potashev  
> > > wrote:
> > > >
> > > > сб, 9 нояб. 2019 г. в 21:50, Ben Cooksley :
> > > > > > > Over the past number of years one of the tasks the Sysadmin team 
> > > > > > > has
> > > > > > > worked on has been improving the overall maintainability of our
> > > > > > > systems, with a significant number of specialised cronjobs, 
> > > > > > > exceptions
> > > > > > > and hidden linkages being eliminated.
> > > > > > >
> > > > > > > That is with one great exception: api.kde.org and ebn.kde.org.
> > > > > > >
> > > > > > > Both of these are suffering from an extreme amount of digital 
> > > > > > > bitrot
> > > > > > > and special casing and in general are now in a condition where I
> > > > > > > cannot say for certain whether it would be possible to replicate 
> > > > > > > the
> > > > > > > setup on a new system without us experiencing some degree of 
> > > > > > > breakage
> > > > > > > (some of which we may not discover until weeks/months afterwards).
> > > > > > >
> > > > > > > In addition, the current setup relies on an old-fashioned 
> > > > > > > overnight
> > > > > > > reprocessing of all repositories, which is inefficient and 
> > > > > > > resource
> > > > > > > expensive. A more modern approach would have the various projects 
> > > > > > > api
> > > > > > > documentation generated on a delayed cycle from relevant branches 
> > > > > > > as
> > > > > > > part of something like a CI job (but not part of the actual CI
> > > > > > > workflow itself).
> > > >
> > > > Hi Ben,
> > > >
> > > > I can't discuss this topic before we understand what exactly is wrong
> > > > with api.kde.org and ebn.kde.org and why they are hard to manage.
> > > > Could you please describe the current situation (where to find source
> > > > code, how many servers, etc) in new Phabricator tasks like you did for
> > > > identity.kde.org in https://phabricator.kde.org/T8449 ?
> > > >
> > > > P.S.  Complicated legacy systems can be easy to replicate once you
> > > > automate their deployment by using Docker containers and/or
> > > > configuration management software like Ansible.
> > >
> > > The problem isn't just the complicated legacy nature of them, but also
> > > how fragile and impossible to maintain they are.
> > >
> > > There are currently to my knowledge the following ways of generating
> > > documentation within the system as it currently stands:
> > > - Legacy KDE 4 era generation tooling, still in use for large parts of
> > > KF5 based applications (which needs periodic fixes, see
> > > https://cgit.kde.org/kdelibs.git/commit/?id=12a8bb503351b98869f722ba932f822e3c495883)
> > > - DoxyQML, which is in part reliant on the above KDE 4 era generation 
> > > tooling
> > > - Specialist handling for 'cmakedocs' and 'mkdocs' based projects
> > > - New era KApiDox tooling
> > >
> > > On top of all of this, the entire process can only be run as one
> > > single monolithic piece, which makes debugging and investigating
> > > faults difficult.
> > >
> > > To use an example of this, back in February 2018 we received a request
> > > (Sysadmin ticket) from someone reporting that their project's API
> > > documentation wasn't being generated.
> > > Despite investigation by Allen and others, we were unable to resolve
> > > the issue, and recommended that the project in question be switched
> > > from the KDE 4 era tooling to the newer KApiDox tooling, as it wasn't
> > > possible to identify the fault.
> > >
> > > Earlier this year there was a fault with API generation in general
> > > which broke a number of projects due to encoding of filenames/folders
> > > (fixed in 
> > > https://cgit.kde

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

El diumenge, 10 de novembre de 2019, a les 3:04:03 CET, Alexander Potashev va 
escriure:
> вс, 10 нояб. 2019 г. в 04:10, Ben Cooksley :
> >
> > On Sun, Nov 10, 2019 at 11:19 AM Albert Astals Cid  wrote:
> > >
> > > El dissabte, 9 de novembre de 2019, a les 21:22:16 CET, Ben Cooksley va 
> > > escriure:
> > > > 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?
> > >
> > > Because we use it in l10n.kde.org to link to po files.
> >
> > Mind detailing what those links are used for?
> 
> A common workflow suggested for translators without SVN account
> (and/or those who find it hard to use SVN) is as folllows:
> 
>  1. Go to https://l10n.kde.org/stats/gui/trunk-kf5/team/ru/ ("ru" for
> Russian) and pick a .po translation file that needs update - e.g.
> incomplete translation or one containing mistakes.
> 
>  2. Click on the .po file at l10n.kde.org to downloaded. WebSVN is
> used for this.
> 
>  3. Edit the downloaded .po file, send for review, etc.
> 
> 
> WebSVN is even mentioned in KDE's primary translation how-to:
> https://l10n.kde.org/docs/translation-howto/gui-translation.html

In addition to that we also use it in check-kde-tp-results to link to the 
particular version the check was run
e.g.
  https://l10n.kde.org/check-kde-tp-results/trunk-kf5/et/messages.html
links to 
  
https://websvn.kde.org/trunk/l10n-kf5/et/messages/kdemultimedia/kwave.po?revision=1555006=markup
in case it was fixed later since the checks only run weekly.

Of course all all of this can be "fixed" by us providing having a "mirror of 
the l10n files" on l10n.kde.org but without having a clue on how websvn works 
it seems it'd be much easier to just keep running that instead of having to 
code our own mirror.

Cheers,
  Albert

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

El diumenge, 10 de novembre de 2019, a les 2:09:19 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 11:19 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 21:22:16 CET, Ben Cooksley va 
> > escriure:
> > > 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?
> >
> > Because we use it in l10n.kde.org to link to po files.
> 
> Mind detailing what those links are used for?
> 
> >
> > > Bear in mind that there is a cost both in terms of infrastructure, and
> > > people time to maintain a service such as WebSVN.
> >
> > We have money, we don't have to shut down things we use because there is a 
> > cost.
> 
> I wasn't referring to monetary cost there, I was referring to the flow
> on effects (such as having to maintain the necessary components on the
> master server to allow for the Subversion repository to be mirrored).
> 
> Note also the "people time" component there.

That can also be solved with money :)

Cheers,
  Albert

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El diumenge, 10 de novembre de 2019, a les 1:04:04 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 11:22 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 21:52:13 CET, Ben Cooksley va 
> > escriure:
> > > On Sun, Nov 10, 2019 at 8:43 AM Albert Astals Cid  wrote:
> > > >
> > > > El dissabte, 9 de novembre de 2019, a les 18:47:57 CET, Ben Cooksley va 
> > > > escriure:
> > > > > On Sun, Nov 10, 2019 at 12:29 AM Luigi Toscano 
> > > > >  wrote:
> > > > > >
> > > > > > Ben Cooksley ha scritto:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > In the category of code related services, Sysadmin currently 
> > > > > > > supports
> > > > > > > a wide-ranging number of services (which makes sense given the 
> > > > > > > nature
> > > > > > > of the community). Some of these however may no longer be in use 
> > > > > > > or
> > > > > > > will be duplicative of other services following the transition to
> > > > > > > Gitlab.
> > > > > > >
> > > > > > > In the category of duplicative, we have our two CGit instances at
> > > > > > > cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these 
> > > > > > > were
> > > > > > > justifiable as there was no other way of browsing scratch/clone
> > > > > > > repositories over the web.
> > > > > > >
> > > > > > > With the migration to Gitlab however all repositories will become
> > > > > > > browsable through it, meaning it no longer makes sense to offer 
> > > > > > > two
> > > > > > > browsers that provide the exact same information (with Gitlab 
> > > > > > > having
> > > > > > > greater capabilities). I'd therefore like to shut both of these 
> > > > > > > down
> > > > > > > once Code Hosting has transitioned to Gitlab.
> > > > > >
> > > > > > Luckily we tried to use commits.kde.org as generic redirect. Will 
> > > > > > the generic
> > > > > > redirect commits.kde.org be updated to point to the proper 
> > > > > > repository? It may
> > > > > > be complicated if the new structure contains the namespaces for each
> > > > > > repository, but we need to keep it working.
> > > > >
> > > > > The commits.kde.org redirector is intended to provide permanent links,
> > > > > so yes it will be updated to redirect people to Gitlab instead once
> > > > > the switch to Gitlab is completed.
> > > > >
> > > > > >
> > > > > > >
> > > > > > > In the category of no longer in use, we have the compatibility
> > > > > > > generator for the kde_projects.xml file. This was introduced when 
> > > > > > > we
> > > > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a 
> > > > > > > way of
> > > > > > > keeping services that needed to discover a list of KDE Projects
> > > > > > > functional.
> > > > > > >
> > > > > > > As we've since migrated to using YAML files within the
> > > > > > > sysadmin/repo-metadata repository for both the CI System and
> > > > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > > > > checkouts) there shouldn't to my knowledge be anything still 
> > > > > > > relying
> > > > > > > on this (aside from perhaps scripty).>
> > > > > > > I'd therefore like to shut this generator down as well, along 
> > > > > > > with the
> > > > > > > compaibility redirector running at projects.kde.org (given that 
> > > > > > > it has
> > > > > > > been some time since we were using that site, and many projects 
> > > > > > > have
> > > > > > > moved around in the virtual structure since then, making the 
> > > > > > > redirects
> > > > > > > it is able to offer useless)
> > > > > >
> > > > > > Two points:
> > > > > > - scripty still uses the XML file and we may need some time to 
> > > > > > migrate.
> > > > >
> > > > > I feared this may have been the case. What sort of timeline are we
> > > > > looking at in terms of switching scripty over?
> > > >
> > > > Over to what?
> > >
> > > To using the YAML files within sysadmin/repo-metadata, which is what
> > > the legacy kde_projects.xml file is generated from currently.
> >
> > Well, someone has to change the code that parses the xml to code that gets 
> > stuff from git and parses yaml, it's not hard, but has to be done.
> 
> *nod*
> 
> I do recall that at one point in our conversations that scripty only
> used the kde_projects.xml file as a check against it's own internal
> data.

Yes and no, we have our i18n branch data hardcoded, but we don't have a list of 
repos, so we need the list of repos from somewhere (and we use the branch data 
from kde_projects.xml to compare it to our hardcoded one to see if there's some 
mismatch).

Cheers,
  Albert

> Has that since been changed?
> 
> >
> > > (Originally the kde_projects.xml file was generated from the
> > > Redmine/Chiliproject database - those YAML files just replaced it)
> >
> > Yes i know :)
> >
> > Cheers,
> >   Albert
> 
> Cheers,
> Ben
> 
> >
> > >
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > >
> > >
> > > Thanks,
> > > Ben
> > >
> >
> >
> >
> >
> 

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 21:52:13 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 8:43 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 18:47:57 CET, Ben Cooksley va 
> > escriure:
> > > On Sun, Nov 10, 2019 at 12:29 AM Luigi Toscano  
> > > wrote:
> > > >
> > > > Ben Cooksley ha scritto:
> > > > > Hi all,
> > > > >
> > > > > In the category of code related services, Sysadmin currently supports
> > > > > a wide-ranging number of services (which makes sense given the nature
> > > > > of the community). Some of these however may no longer be in use or
> > > > > will be duplicative of other services following the transition to
> > > > > Gitlab.
> > > > >
> > > > > In the category of duplicative, we have our two CGit instances at
> > > > > cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these were
> > > > > justifiable as there was no other way of browsing scratch/clone
> > > > > repositories over the web.
> > > > >
> > > > > With the migration to Gitlab however all repositories will become
> > > > > browsable through it, meaning it no longer makes sense to offer two
> > > > > browsers that provide the exact same information (with Gitlab having
> > > > > greater capabilities). I'd therefore like to shut both of these down
> > > > > once Code Hosting has transitioned to Gitlab.
> > > >
> > > > Luckily we tried to use commits.kde.org as generic redirect. Will the 
> > > > generic
> > > > redirect commits.kde.org be updated to point to the proper repository? 
> > > > It may
> > > > be complicated if the new structure contains the namespaces for each
> > > > repository, but we need to keep it working.
> > >
> > > The commits.kde.org redirector is intended to provide permanent links,
> > > so yes it will be updated to redirect people to Gitlab instead once
> > > the switch to Gitlab is completed.
> > >
> > > >
> > > > >
> > > > > In the category of no longer in use, we have the compatibility
> > > > > generator for the kde_projects.xml file. This was introduced when we
> > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > > > keeping services that needed to discover a list of KDE Projects
> > > > > functional.
> > > > >
> > > > > As we've since migrated to using YAML files within the
> > > > > sysadmin/repo-metadata repository for both the CI System and
> > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > > checkouts) there shouldn't to my knowledge be anything still relying
> > > > > on this (aside from perhaps scripty).>
> > > > > I'd therefore like to shut this generator down as well, along with the
> > > > > compaibility redirector running at projects.kde.org (given that it has
> > > > > been some time since we were using that site, and many projects have
> > > > > moved around in the virtual structure since then, making the redirects
> > > > > it is able to offer useless)
> > > >
> > > > Two points:
> > > > - scripty still uses the XML file and we may need some time to migrate.
> > >
> > > I feared this may have been the case. What sort of timeline are we
> > > looking at in terms of switching scripty over?
> >
> > Over to what?
> 
> To using the YAML files within sysadmin/repo-metadata, which is what
> the legacy kde_projects.xml file is generated from currently.

Well, someone has to change the code that parses the xml to code that gets 
stuff from git and parses yaml, it's not hard, but has to be done.

> (Originally the kde_projects.xml file was generated from the
> Redmine/Chiliproject database - those YAML files just replaced it)

Yes i know :)

Cheers,
  Albert

> 
> >
> > Cheers,
> >   Albert
> >
> >
> 
> Thanks,
> Ben
> 

Re: General Infrastructure Maintainability: API and EBN

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 22:03:37 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 9:29 AM Alexander Potashev  
> wrote:
> >
> > сб, 9 нояб. 2019 г. в 21:50, Ben Cooksley :
> > > > > Over the past number of years one of the tasks the Sysadmin team has
> > > > > worked on has been improving the overall maintainability of our
> > > > > systems, with a significant number of specialised cronjobs, exceptions
> > > > > and hidden linkages being eliminated.
> > > > >
> > > > > That is with one great exception: api.kde.org and ebn.kde.org.
> > > > >
> > > > > Both of these are suffering from an extreme amount of digital bitrot
> > > > > and special casing and in general are now in a condition where I
> > > > > cannot say for certain whether it would be possible to replicate the
> > > > > setup on a new system without us experiencing some degree of breakage
> > > > > (some of which we may not discover until weeks/months afterwards).
> > > > >
> > > > > In addition, the current setup relies on an old-fashioned overnight
> > > > > reprocessing of all repositories, which is inefficient and resource
> > > > > expensive. A more modern approach would have the various projects api
> > > > > documentation generated on a delayed cycle from relevant branches as
> > > > > part of something like a CI job (but not part of the actual CI
> > > > > workflow itself).
> >
> > Hi Ben,
> >
> > I can't discuss this topic before we understand what exactly is wrong
> > with api.kde.org and ebn.kde.org and why they are hard to manage.
> > Could you please describe the current situation (where to find source
> > code, how many servers, etc) in new Phabricator tasks like you did for
> > identity.kde.org in https://phabricator.kde.org/T8449 ?
> >
> > P.S.  Complicated legacy systems can be easy to replicate once you
> > automate their deployment by using Docker containers and/or
> > configuration management software like Ansible.
> 
> The problem isn't just the complicated legacy nature of them, but also
> how fragile and impossible to maintain they are.
> 
> There are currently to my knowledge the following ways of generating
> documentation within the system as it currently stands:
> - Legacy KDE 4 era generation tooling, still in use for large parts of
> KF5 based applications (which needs periodic fixes, see
> https://cgit.kde.org/kdelibs.git/commit/?id=12a8bb503351b98869f722ba932f822e3c495883)
> - DoxyQML, which is in part reliant on the above KDE 4 era generation tooling
> - Specialist handling for 'cmakedocs' and 'mkdocs' based projects
> - New era KApiDox tooling
> 
> On top of all of this, the entire process can only be run as one
> single monolithic piece, which makes debugging and investigating
> faults difficult.
> 
> To use an example of this, back in February 2018 we received a request
> (Sysadmin ticket) from someone reporting that their project's API
> documentation wasn't being generated.
> Despite investigation by Allen and others, we were unable to resolve
> the issue, and recommended that the project in question be switched
> from the KDE 4 era tooling to the newer KApiDox tooling, as it wasn't
> possible to identify the fault.
> 
> Earlier this year there was a fault with API generation in general
> which broke a number of projects due to encoding of filenames/folders
> (fixed in 
> https://cgit.kde.org/websites/quality-kde-org.git/commit/?id=f71c68bc80cce68aa3bcc6a51626c8f22b7c73c3).

I volunteer to fix it.

Cheers,
  Albert

> 
> >
> > --
> > Alexander Potashev
> 
> Cheers,
> Ben
> 

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 21:22:16 CET, Ben Cooksley va 
escriure:
> 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?

Because we use it in l10n.kde.org to link to po files.

> Bear in mind that there is a cost both in terms of infrastructure, and
> people time to maintain a service such as WebSVN.

We have money, we don't have to shut down things we use because there is a cost.

Cheers,
  Albert

> This includes having to maintain a mirror of the repository on the
> machine that runs WebSVN, along with the associated infrastructure for
> allowing that mirroring to happen on the master server.
> 
> >
> > Cheers,
> >   Albert
> 
> Regards,
> Ben
> 
> >
> > >
> > > >
> > > > I'm not sure what use case Luigi has in mind, but among Russian l10n
> > > > team we often use WebSVN to refer to specific SVN revisions, for
> > > > example: https://websvn.kde.org/?view=revision=1555342
> > > >
> > > > --
> > > > Alexander Potashev
> > >
> > > Regards,
> > > Ben
> > >
> >
> >
> >
> >
> 

Re: Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 18:47:57 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 12:29 AM Luigi Toscano  
> wrote:
> >
> > Ben Cooksley ha scritto:
> > > Hi all,
> > >
> > > In the category of code related services, Sysadmin currently supports
> > > a wide-ranging number of services (which makes sense given the nature
> > > of the community). Some of these however may no longer be in use or
> > > will be duplicative of other services following the transition to
> > > Gitlab.
> > >
> > > In the category of duplicative, we have our two CGit instances at
> > > cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these were
> > > justifiable as there was no other way of browsing scratch/clone
> > > repositories over the web.
> > >
> > > With the migration to Gitlab however all repositories will become
> > > browsable through it, meaning it no longer makes sense to offer two
> > > browsers that provide the exact same information (with Gitlab having
> > > greater capabilities). I'd therefore like to shut both of these down
> > > once Code Hosting has transitioned to Gitlab.
> >
> > Luckily we tried to use commits.kde.org as generic redirect. Will the 
> > generic
> > redirect commits.kde.org be updated to point to the proper repository? It 
> > may
> > be complicated if the new structure contains the namespaces for each
> > repository, but we need to keep it working.
> 
> The commits.kde.org redirector is intended to provide permanent links,
> so yes it will be updated to redirect people to Gitlab instead once
> the switch to Gitlab is completed.
> 
> >
> > >
> > > In the category of no longer in use, we have the compatibility
> > > generator for the kde_projects.xml file. This was introduced when we
> > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > keeping services that needed to discover a list of KDE Projects
> > > functional.
> > >
> > > As we've since migrated to using YAML files within the
> > > sysadmin/repo-metadata repository for both the CI System and
> > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > checkouts) there shouldn't to my knowledge be anything still relying
> > > on this (aside from perhaps scripty).>
> > > I'd therefore like to shut this generator down as well, along with the
> > > compaibility redirector running at projects.kde.org (given that it has
> > > been some time since we were using that site, and many projects have
> > > moved around in the virtual structure since then, making the redirects
> > > it is able to offer useless)
> >
> > Two points:
> > - scripty still uses the XML file and we may need some time to migrate.
> 
> I feared this may have been the case. What sort of timeline are we
> looking at in terms of switching scripty over?

Over to what?

Cheers,
  Albert

Re: Reducing the load on Sysadmin

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 0:49:49 CET, Ben Cooksley va escriure:
> Hi all,
> 
> One of the things that was prepared as a result of the Sysadmin BoF at
> Akademy was a list of systems and services which we look after and
> provide to the community.
> 
> Whilst individually all of the services seem fairly reasonable and
> maintainable, the cumulative number of them has created a situation
> where they limit our ability to reasonably maintain our services as a
> collective whole.
> 
> I've therefore conducted an analysis of all the various services we
> operate, with the objective of shutting down those services and sites
> that either provide marginal benefit to the community, are historical
> in nature or which could be provided better by others.
> 
> Please note that while individually each item may seem small (and
> therefore "not an issue" to continue running), it is the collective
> number of them that create the problem.
> 
> I'll shortly be sending out a series of emails regarding the services
> in question which have been identified for shutdown.

Honestly i think you took the wrong approach here, removing things we seem to 
be using because there's not enough sysadmins instead of trying to increase the 
sysadmins.

Cheers,
  Albert

P.S: Maybe there has been an attempt to increase the sysadmins, if so I 
apologize

> 
> Cheers,
> Ben
> 

Re: Sysadmin Load Reduction: Legacy Compatibility Redirects

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 19:21:30 CET, Ben Cooksley va 
escriure:
> On Sun, Nov 10, 2019 at 12:38 AM Albert Astals Cid  wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 1:02:01 CET, Ben Cooksley va 
> > escriure:
> > > Any comments?
> >
> > Cool URIs don't change
> > https://www.w3.org/Provider/Style/URI
> 
> While that would be nice, in practice they do end up changing - and
> many of the above mentioned sites are simply redirected straight to
> the wiki so the only page that would have worked for the compatibility
> redirect is the Index page for that project.
> 
> Given many of them are extremely old, and which nobody will be trying
> to access anyway,

Says who?

I just went into google, spent 1 second and there's there's hundreds of links 
to accessibility.kde.org, why would we want to break all those links?

Does it really cost us *anything* maintaining a redirect?

Cheers,
  Albert

> we should go ahead and retire them (and as Volker
> noted in another response to this thread, many of the compatibility
> redirects we put in place are themselves broken because pages have
> moved around both within and between the various wikis we host)
> 
> >
> > Cheers,
> >   Albert
> >
> >
> 
> Regards,
> Ben
> 

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Albert Astals Cid]

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.

Cheers,
  Albert

> 
> >
> > I'm not sure what use case Luigi has in mind, but among Russian l10n
> > team we often use WebSVN to refer to specific SVN revisions, for
> > example: https://websvn.kde.org/?view=revision=1555342
> >
> > --
> > Alexander Potashev
> 
> Regards,
> Ben
> 

Re: Sysadmin Load Reduction: Legacy Compatibility Redirects

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 1:02:01 CET, Ben Cooksley va escriure:
> Any comments?

Cool URIs don't change
https://www.w3.org/Provider/Style/URI

Cheers,
  Albert

Re: Should KDE join the (Digital) Global Climate Strike this friday? - Proposal

[Albert Astals Cid]

El dijous, 19 de setembre de 2019, a les 23:20:29 CEST, Lew Wolfgang va 
escriure:
> On 9/19/19 7:45 AM, Martin Steigerwald wrote:
> > What do we choose? Climate Action. When do we choose it? Now.
> 
> Okay, this is a leap too far.  Politics should not be introduced here, and it 
> is "Politics".
> 
> I'm out of here, Maybe Gnome isn't "woke"?
> 
> Now, how do I unsubscribe from this off-topic list?

You were smart enough to subscribe, you're smart enough to unsubscribe.

Best of luck,
  Albert

> 
> Regards,
> Lew
> 
> 

Re: Invent/gitlab, issues and bugzilla

[Albert Astals Cid]

El dimarts, 2 de juliol de 2019, a les 14:55:41 CEST, Luigi Toscano va escriure:
> Hi,
> 
> one of the main point of the gitlab migration has been so far the replacement
> for phabricator. We didn't discuss about bug tracking.
> 
> Despite this, I've seen a few projects using issues as replacement for 
> bugzilla.
> 
> 
> We can all debate which is better, whether bugzilla or the gitlab issues, but
> please consider that:
> 
> - having to ways to report a bug makes like of everyone more complicated for
> users reporting bug who need to find the proper place, and for bug triager
> 
> - drkonqi still continue to report to bugzilla. Future versions of drkonqi can
> be fixed to support the new system and we would need also a proxy for older
> versions of drkonqi, but until such thing exist, a migration is out of 
> question.
> 
> 
> My suggestion right now is to disable issues completely, or if they need to be
> enable to allow us to replace phabricator tasks, then to reduce their scope to
> this.

+1 either close them or make them be "developer tasks". 

Cheers,
  Albert

> 
> 

Re: Invent/gitlab, issues and bugzilla

[Albert Astals Cid]

El dimarts, 2 de juliol de 2019, a les 15:48:43 CEST, Bhushan Shah va escriure:
> Hello,
> 
> and if it is our stance then we better close incubator
> projects..

That makes no sense, we incubated projects before we were on gitlab, saying "oh 
no, if people can't use gitlab issues the incubation will collapse" is a bit 
alarmist IMGO

Cheers,
  Albert

Re: Bugzilla order of sections when entering a new bug

[Albert Astals Cid]

El dimarts, 18 de juny de 2019, a les 15:05:50 CEST, Boudewijn Rempt va 
escriure:
> I was just entering a bug for Krita when I suddenly realized why I'm getting 
> two, three or more reports a day with no information in the description at 
> all. The duplicates block is so large that it pushes the description field 
> out of sight -- and the result is that people don't see and try to cram their 
> entire report in the summary line.
> 
> Would it be possible to switch the two blocks in the bug report template?

Are you sure that this is what happening?

I mean before you start writing the summary you can clearly see the Description 
field. Sure when you write something into it the duplicates area may push it 
away, but do people forget about the Description so fast?

I don't think it makes sense moving the duplicates block after Description, the 
idea of the duplicates block is that you write the subject, then you get a 
suggestion of duplicates and say "oh yes, this is a duplicate of my bug" and 
thus you don't need to write the whole big text.

Maybe we can explore making the duplicate list smaller/scrollable/collapsible?

Also, if people are submitting the bug, they are scrolling down, seeing the 
Description field and ignoring it anyway.

Cheers,
  Albert

> 
> 

Re: Anonymous contributions

[Albert Astals Cid]

El dimarts, 16 d’abril de 2019, a les 23:25:47 CEST, Boudewijn Rempt va 
escriure:
> On dinsdag 16 april 2019 23:04:02 CEST Friedrich W. H. Kossebau wrote:
> > So this would actually implement what you ask for: no guess work about 
> > valid 
> > names.
> 
> Whether or not we can be sure that a string is a name should not be relevant 
> to us.

Just answering to say that this is actually what we're actually discussing in 
this thread. 

Can/Should we accept anonymous contributions (and thus we should not care about 
a string being a name) or not?

I think the most sensible answer from the whole thread was the one from David 
Edmundson "we should contact a lawyer".

Cheers,
  Albert

> 
> 

Re: Anonymous contributions

[Albert Astals Cid]

El dijous, 11 d’abril de 2019, a les 20:56:03 CEST, Christoph Cullmann va 
escriure:
> On 2019-04-11 20:36, David Edmundson wrote:
> > We would need to ask a lawyer.
> > I only know enough to know that I don't know enough.
> Hi,
> 
> independent of any lawyer, my 2 cents:
> 
> As we did never verify any names nor identities, is the discussion not 
> mood?
> 
> We already accept contributions, by lets make up "Max Schmidt 
> ", if he/her/... sends in a reasonable patch.
> 
> We never check: is that the real name? Is this person existing?
> 
> I actually started to accept "alias" named contributions after asking 
> me:
> I am more happy with a person that tells he/her/... uses an alias or do 
> I want to be lied to with some fake name that sounds ok?
> 
> For re-licensing and similar stuff:
> 
> I tried to re-license parts of KTextEditor in the past.
> Real names help close to nothing if the mail addresses are no longer 
> valid or the people don't respond, even if valid.
> You just can't track them, unfortunately there are more "Max Schmidt"s 
> around on the world then lets say "Christoph Cullmann"s.

Yes, Albert Astals Cid is much easier to track than randomguy, i'm 99.99% 
positive there's only one Albert Astals Cid in the world, there's millions of 
randomguys, so please don't say "you just can't track them" because it's 
obviously not true, sure for more common names it's still not trivial, but it 
is much easier if you have someone's name than if you don't.

Cheers,
  Albert

> 
> If you want to re-license and the last known mail addresses don't work 
> out for you, you are doomed with or without names.
> Actually, from a legal stand-point I am not even sure if some "I am ok 
> with re-licensing" mail from some random mail address would be legally 
> ok,
> I doubt that, you can't do other kind of contracts with plain text mails 
> either, at least e.g. not in Germany.
> 
> But that's something a lawyer knows best, true.
> 
> Greetings
> Christoph
> 

Re: Facebook's KDE Connector integration app

[Albert Astals Cid]

El dilluns, 8 d’abril de 2019, a les 17:34:14 CEST, Martin Klapetek va escriure:
> On Sat, Apr 6, 2019 at 7:07 AM Albert Astals Cid  wrote:
> 
> > El dijous, 4 d’abril de 2019, a les 19:56:40 CEST, Martin Klapetek va
> > escriure:
> > > Hello!
> > >
> > > Back in the days there used to be some level of Facebook integration into
> > > KDE apps and a Facebook app called "KDE Connector" was used to integrate
> > > with it.
> > >
> > > I inherited it from the previous maintainer and it's now tied to my
> > > account; I keep getting alerts for this but I'm not aware of anything
> > using
> > > this Facebook app, the only occurrence I could find is a disabled
> > KAccounts
> > > provider file.
> > >
> > > As I'm no longer involved with any Facebook integration projects - would
> > > anyone like to take over the ownership of this Facebook app? If so
> > > please let me know, otherwise I'll just delete it sometime next week.
> >
> > You mention it's probably not very useful/used anymore, but maybe still
> > makes sense to pass ownership to the kde community user/group/page?
> >
> > Do you know if that's possible?
> >
> 
> Doesn't look like it, when I put "kde" as a username, it says it
> doesn't resolve to valid user id. If our KDE Facebook page has
> fcbid (long number), I can try that one, otherwise it's probably
> not possible.

It's 6344818917 i think?

At least https://www.facebook.com/profile.php?id=6344818917 redirects to 
https://www.facebook.com/kde/

Cheers,
  Albert

> 
> Cheers
> --
> Martin Klapetek
> 

Re: Facebook's KDE Connector integration app

[Albert Astals Cid]

El dijous, 4 d’abril de 2019, a les 19:56:40 CEST, Martin Klapetek va escriure:
> Hello!
> 
> Back in the days there used to be some level of Facebook integration into
> KDE apps and a Facebook app called "KDE Connector" was used to integrate
> with it.
> 
> I inherited it from the previous maintainer and it's now tied to my
> account; I keep getting alerts for this but I'm not aware of anything using
> this Facebook app, the only occurrence I could find is a disabled KAccounts
> provider file.
> 
> As I'm no longer involved with any Facebook integration projects - would
> anyone like to take over the ownership of this Facebook app? If so
> please let me know, otherwise I'll just delete it sometime next week.

You mention it's probably not very useful/used anymore, but maybe still makes 
sense to pass ownership to the kde community user/group/page?

Do you know if that's possible?

Cheers,
  Albert

> 
> Cheers
> --
> Martin Klapetek
> 

Re: KDE now has its own Matrix infrastructure

[Albert Astals Cid]

El dimecres, 20 de febrer de 2019, a les 13:36:37 CET, Paul Brown va escriure:
> Hi all,
>   
> Some aspects of Matrix which make it particularly suitable for KDE are:

Some aspects of IRC which make it particularly suitable are:
 * It actually works

Matrix is right now more than 2 hours behind for #kde-devel making it totally 
useless.

Is there any plan to make sure one can use Matrix reliably? 

Because at this point i need to have the IRC client open to make sure that:
 * What i write in Matrix gets to IRC
 * What i read in Matrix is the latest thing that was on IRC

Cheers,
  Albert

Google Season of Docs

[Albert Astals Cid]

Was announced yesterday/today

https://developers.google.com/season-of-docs/

What is "docs" in this regard 
https://developers.google.com/season-of-docs/docs/project-ideas

Important deadlines
April 2, 2019 at 20:00 UTC  
Mentoring organizations can begin submitting applications to 
Google

April 23, 2019 at 20:00 UTC
Deadline for organization applications

*Important for us* Valorie has mentioned she doesn't have the spare cycles to 
lead this, she can lend a helping hand but if we want to part of this we need 
an admin. 

Volunteers?

Cheers,
  Albert

Re: KDE now has its own Matrix infrastructure

[Albert Astals Cid]

El dijous, 28 de febrer de 2019, a les 16:38:30 CET, Jonathan Riddell va 
escriure:
> 
> I get some unitemised t-shirts from old Akademys which is
> appreciated.

Do I understand it correctly that KDE e.V. gave you t-shirts, you sold them and 
then kept the money?

That sounds quite bad to be honest.

Cheers,
  Albert

Re: KDE now has its own Matrix infrastructure

[Albert Astals Cid]

El dimecres, 20 de febrer de 2019, a les 13:36:37 CET, Paul Brown va escriure:
> Hi all,
>   
> You can try KDE's Matrix service right now by checking out https://
> webchat.kde.org 

What are we going to do with the constant loss of messages?

I posted a message in webchat.kde.org 10 minutes ago and it didn't make it to 
IRC yet (and i guess it'll never happen).

Having lost messages makes this whole thing unusable.

Cheers,
  Albert

Re: Security issue

[Albert Astals Cid]

El divendres, 4 de gener de 2019, a les 14:24:31 CET, Anurag Jain va escriure:
> I have founded a security issue. Kindly let me know correct email address
> to report

https://www.kde.org/info/security/

Re: social-media list

[Albert Astals Cid]

El divendres, 2 de novembre de 2018, a les 16:10:00 CET, Jonathan Riddell va 
escriure:
> On Thu, Nov 01, 2018 at 11:24:26PM +0100, Albert Astals Cid wrote:
> > El dijous, 1 de novembre de 2018, a les 21:48:36 CET, Jonathan Riddell va 
> > escriure:
> > > On Wed, Oct 31, 2018 at 08:34:31PM +, Jonathan Riddell wrote:
> > > > Is anyone using this list or can we shut it down?
> > > > 
> > > > https://mail.kde.org/mailman/listinfo/social-media
> > > 
> > > Guess not, I'll ask for it to be removed.
> > 
> > I'm really puzzled by your email:
> >  A) Why did you ask if that list is used here instead of asking in the list 
> > itself? 
> >  B) Do you realize you just waited for 24 hours and on top of that today is 
> > a holiday in lots of places in the world thus people will be less prone to 
> > answering?
> 
> Shrug, nobody on the promo team is on the list or knows what it is for

What the list is for:
 * https://community.kde.org/Promo/People/social_media says "If you want to 
reach the global list of people with access to various media outlets please 
email https://mail.kde.org/mailman/listinfo/social-media;

> who runs it.  

Who runs it:
 * social-media-ow...@kde.org

Cheers,
  Albert

Re: social-media list

[Albert Astals Cid]

El dijous, 1 de novembre de 2018, a les 21:48:36 CET, Jonathan Riddell va 
escriure:
> On Wed, Oct 31, 2018 at 08:34:31PM +, Jonathan Riddell wrote:
> > Is anyone using this list or can we shut it down?
> > 
> > https://mail.kde.org/mailman/listinfo/social-media
> 
> Guess not, I'll ask for it to be removed.

I'm really puzzled by your email:
 A) Why did you ask if that list is used here instead of asking in the list 
itself? 
 B) Do you realize you just waited for 24 hours and on top of that today is a 
holiday in lots of places in the world thus people will be less prone to 
answering?

Cheers,
  Albert

> 
> Jonathan
> 

Re: papercut keyword for bug.kde.org

[Albert Astals Cid]

El dijous, 20 de setembre de 2018, a les 19:54:16 CEST, Boudewijn Rempt va 
escriure:
> On donderdag 20 september 2018 19:29:11 CEST Albert Astals Cid wrote:
> > El dijous, 20 de setembre de 2018, a les 16:28:48 CEST, Boudewijn Rempt va 
> escriure:
> > > Hi,
> > > 
> > > Would there be any problem with adding the 'papercut' keywoard to the set
> > > of keywoards we can use, like regression, release_blocker and so on?
> > 
> > What would be the difference between papercut and junior-job?
> > 
> 
> A papercut can be really complicated to fix, code-wise, while a junior-job 
> should be straight-forward and easy.

So the paper cut is then a usability improvement? We have an usability keyword 
too.

Cheers,
  Albert 
 

Re: Closing NEEDSINFO bugs after 30 days

[Albert Astals Cid]

El dilluns, 17 de setembre de 2018, a les 20:01:15 CEST, Andrew Crouthamel va 
escriure:
> 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.
> 
> I believe it would be best, if these unactionable bugs are closed after 30 
> days of inactivity. This would become a KDE Bugzilla policy going forward, 
> and one we could even implement as a bot if possible in the future. For 
> example, the Chromium project Sherriffbot does this today. But for now, I'd 
> like it to become a manual Bugsquad action item to check. It cannot be 
> expected to leave a bug open indefinitely, if the reporter cannot be bothered 
> to provide the additional requested information. It's unfair to our 
> developers to be unsure when to close an abandoned bug, and contributes to 
> lessening the signal-to-noise ratio of our issues in Bugzilla.
> 
> This is already a policy at many other projects such as The Document 
> Foundation, Chromium, and Fedora. Additionally, several of our developers 
> within KDE are already doing this.
> 
> Thoughts?

In my expirience people routinely forget to change the status back when they 
provide the information so I don't think it's a good idea.

Unless we can check if there has been no comment after the comment that changed 
the status to NEEDSINFO, it that's possible, seems good to me.

Cheers,
  Albert

> 
> Andrew Crouthamel

Re: Twitter access

[Albert Astals Cid]

El dilluns, 16 de juliol de 2018, a les 11:26:42 CEST, Jonathan Riddell va 
escriure:
> Hi KDE community I'd like to request access to post on the
> @kdecommunity Twitter account.  This is to make announcements of
> Plasma releases, our flagship product.  I already do this on G+ and
> Facebook.  I'm told there are higher powers who have to approve this
> but I've no idea who they are or how to get a message to them, 

I guess the best is to contact those higher powers in their own mailing list
https://community.kde.org/Promo/People/social_media#Global_coordination

Cheers,
  Albert

> they
> seem to have not received my requests so far.  I've been an active
> contributoir to kde-promo for about 15 years after the only
> contributor.
> 
> Jonathan