Re: [kde-community] Retiring applications - was - Re: Applications in KDE Generation 5

[Harald Sitter]

On Thu, Jan 16, 2014 at 1:37 AM, Albert Astals Cid aa...@kde.org wrote:
 El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure:
 Hi,

 * A number of our apps and utilities really have had their day and
 need retiring, e.g. KsCD, Kppp, KFloppy.  There's no point keeping
 low-quality or unmaintained apps around just to try ship a complete
 desktop experience, especially if there are other better apps out
 there (even if not KDE ones).  Being part of the official release
 should be a stamp of quality: make apps work for it.  Lets go through
 the existing apps and agree what needs dropping to Extragear or
 Unmaintained.

 I am not conviced by that, we probably still have some users for that and i'm
 pretty sure some of those apps still get roaming fixes from people, if you
 move them out from the apps we release on each release, you'll end up with
 the K3b situation, an application that has had bugfixes but hasn't had a
 release in ages so noone is beneffiting from those bugfixes because there's
 noone around that has enough power to do a release.

Random ramblings of the day:

Getting the odd fix here and there does not related in any form or
fashion to the quality though. If any of the people doing the k3b
fixes cared enough I am sure they had done a release. It's not like
only someone who got themselves a maintainer badge can do releases
after all.

The problem however is that the applications John mentioned, are hard
to crowd maintain (i.e. put on life support and everyone feels jointly
responsible for the quality of those applications, thus providing
rather sensible releases) because they require hardware and/or special
knowledge. Kppp for example, I'd totally throw random fixes at it
except it is nigh impossible to test this thing accurately because I
have no physical modem and no knowledge of how the ppp stack would or
should work in general.
Same goes for kfloppy. It'd be jolly hard to find anyone who still has
a working floppy drive and can use it on a machine new enough to run
an up-to-date system.

Keeping *actually* unmaintained software in monthly releases creates
the wrong impression. We really are lying to the user and ourselves
here. We create the impression that kppp is actively being maintained
and cared for while in fact it is not [1][2]. Now that fact is easy
enough to ignore for everyone who does not need to use kppp. For
everyone who does it's basically a slap in the face a la 'got ya, we
are not really maintaining this, just wanted to have you spend time on
filing a bug report that will not ever see a reply from a dev'.

It is not nice, and it is not fair. If the people doing fixes to such
half-dead software actually stepped up and took over maintenance, the
software would not be unmaintained and didn't need to get dropped out
of the SC; also the world would be a much better place.

[1] 
http://quickgit.kde.org/?p=kppp.gita=shortlogh=ab56f7593087179ceeef28ae8e70e1cdae8faf3c
[2] 
https://bugs.kde.org/buglist.cgi?product=kpppcomponent=generalresolution=---list_id=909065

HS
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] strawpoll: kde quassel core hosting

[Harald Sitter]

Ahoy ahoy,

It just occured to me that I know rather a lot of people who either
operate their own Quassel Core [1] or are on a shared core with a
bunch of other community members.
So, I was talking to Ben Cooksley about the possibility of offering a
Quassel Core in addition to the already existing IRC Bouncer and he
didn't object. So I'd like to do a quick straw poll to see if there is
interest.

http://strawpoll.me/4475217

[1] http://bugs.quassel-irc.org/projects/quassel-irc/wiki

HS
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Official KDE mirror on github

[Harald Sitter]

On Mon, Aug 17, 2015 at 7:46 AM, Martin Graesslin mgraess...@kde.org wrote:
 I suggest that we:
 * introduce an official mirror for all KDE repositories on github
 * replace all existing (non-official) clones
 * disallow pull-requests on github to not replace our development model by a
 proprietary platform.

 Comments?

+1 on mirroring.

There is an ecosystem around github that I for one find rather useful
for releaseme [1], where I use a bunch of stuff to conduct static
analysis of the code and CI it. This is even more hadny considering
releaseme is written in ruby, so if one wanted to do the same stuff on
jenkins (which one could do) the sysadmins would have to maintain a
ruby stack for one repo which isn't even a product in of itself.

https://github.com/apachelogger/releaseme
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: KDE licence policy update

[Harald Sitter]

On Sat, Feb 11, 2017 at 12:37 AM, Luigi Toscano
 wrote:
> Jonathan Riddell ha scritto:
>
>> The main change is for docs and other non-code files to become
>> CC-BY-SA 4.  This allows it to be converted to code (it's one-way
>> compatible with LGPL 3)
> Do you have more details for this? I see contradicting information, it does
> not seem to be totally future proof (even if I hope that we won't see a GPLv4
> before my retirement, but... that would be too much I guess):
> https://www.fsf.org/blogs/licensing/creative-commons-by-sa-4-0-declared-one-way-compatible-with-gnu-gpl-version-3
> (hint about GPLv3 only)
>
> https://www.gnu.org/licenses/license-compatibility.en.html -> "Unfortunately,
> CC-BY-SA 4.0 does not permit relicensing to future GPL versions. What you
> should do, when you relicense material under CC-BY-SA 4.0 to the GPL, is
> specify yourself as a license version proxy to indicate whether future GPL
> versions have been authorized for that material. If someday there is a GPL
> version 4 and Creative Commons decides to allow relicensing from CC-BY-SA to
> GPL version 4, you as proxy will be able to retroactively authorize use of
> that relicensed material under GPL version 4. (Alternatively, you can ask the
> authors of that material to give permission right away.)"

I think that may fall into FLA/FRP territory.

That being said, this seems to need taking to the e.V. to get a new
FRP revision as currently CC isn't even considered an acceptable
license according to the FRP. The FDL however is. Consequently the FLA
would no longer cover documentation under the suggested changes.

https://ev.kde.org/resources/FRP.pdf

Re: Please move project task tracking to Phabricator

[Harald Sitter]

On Wed, Nov 2, 2016 at 11:33 AM, Martin Graesslin  wrote:
> On Wednesday, November 2, 2016 10:26:28 PM CET Ben Cooksley wrote:
>> Hi all,
>>
>> As some will be aware we currently have two Kanban board style
>> solutions deployed - Kanboard at todo.kde.org and Phabricator at
>> phabricator.kde.org.
>>
>> In the long term we'd like to consolidate everything on Phabricator.
>> It would therefore be appreciated if people could cleanup Kanboard,
>> removing tasks and boards which have already moved over, and porting
>> over items which haven't already been moved over.
>>
>> If you need a Project created to organise your tasks, please file a
>> sysadmin ticket.
>>
>> Once the majority of projects have been cleaned up and migrated over
>> we'll look at scheduling a shutdown date for todo.kde.org.
>
> The last time this was brought up, it was said that sysadmins will do the
> migration and that one should not manually copy tasks?
>
> So what should one do now? Manually recreate all tasks on phab? That seems
> like a huge manual effort which I don't have time for.

not sure if there was a plan. but I have some 20 lines of code
somewhere that I used to migrate all of neon, supposedly one could
just mass move everything through API?

HS

Re: KDE GPG Keyserver

[Harald Sitter]

On Mon, Jul 24, 2017 at 5:11 PM, Sandro Knauß  wrote:
> Hey,
>
>> I recommend using the keyserver (pool) that's recommended by the official
>> GnuPG FAQ [1] or, even better, sticking to the default, unless you have a
>> specific reason for not using those. If you are concerned about your
>> privacy then you should rather look into using a keyserver on the Tor
>> network.
>
>  A specialied keyserver makes sense, if we want to improve the situation with
> GPG Keys. We already use the Kes to sign releases, so we may want to check if
> these keys are available and why not use our own pool?
> * we can improve more rules for keys like >1024 bits no DSA, no unlimited
> keys,...)
> (Debian also has his own keyring, where they have far more rules than a simple
> sks-keyserver)
> * This makes sense in terms of get a more unified way to test on our systems
> that a key is "known"... We had already this discussion of where to get a key
> for a signature on the devel list...

FWIW, the reason for not having a server is what Christoph said about
maintaining stuff we don't technically need. Hosting our own server
adds no tangible value over deferring to the pool. Which goes doubly
so because the way debian's keyring is used is as a moderated frontend
server (IIRC), rather than a public access pool server everyone can
push keys into... apples and oranges.
Whether or not we should have a thing like debian is a discussion we
could have I suppose, though personally, I don't see the paperwork and
knowledge overhead such a setup would entail going well with our
community.

HS

Re: KDE GPG Keyserver

[Harald Sitter]

On Mon, Jul 24, 2017 at 3:04 PM, Boudhayan Gupta  wrote:
> Ingo: I just set up gossip with the SKS pool but it hasn't synced anything
> yet.

https://www.sks-keyservers.net/status/

still not synced I am afraid

Re: github, phabricator: a new threadZ

[Harald Sitter]

Seems to me y'all aren't appreciating that I am telling you my point
of view. I have created some 20 repos on github last year and 0
scratch repos on our infrastructure. I thought you might want to know
why. Feel free to find my reasons silly, that doesn't change them
though.

I am did not mean to argue any side.

On Thu, Aug 10, 2017 at 9:02 AM, Harald Sitter <sit...@kde.org> wrote:
> I for one would pick the alternative which is not using our
> infrastructure and instead click two buttons so I don't have to file
> paperwork manually nor have to wait for said paperwork to get faxed to
> HQ for approval. i.e. not waiting trumps waiting in my world.
>
> On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid <aa...@kde.org> wrote:
>> El dimecres, 9 d’agost de 2017, a les 13:50:46 CEST, Harald Sitter va
>> escriure:
>>> On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt <b...@valdyas.org> wrote:
>>> > On Wed, 9 Aug 2017, Riccardo Iaconelli wrote:
>>> >> This is a new thread entirely, but incidentally also something we
>>> >> should also think about. Why many KDE developers choose github instead
>>> >> of scratch KDE repositories to start new software, where it could
>>> >> happily be hosted within KDE infrastructure?
>>> >
>>> > Our infra doesn't offer scratch repos anymore, does it?
>>>
>>> It does, they were slated for removal with the transition to phab,
>>> since that hasn't happend yet though I assume scratch repos are still
>>> a thing. Albeit, a thing that is meant to be removed with (currently)
>>> no replacement planned
>>
>> That was not the plan, the plan (unless it has changed since last time i
>> asked) is to have a team of "trusted people" that can create repos on
>> phabricator, so basically you'd open a ticket and you'd get a repo created in
>> a matter of minutes, not automagic, but surely you can continue coding for 15
>> minutes while you wait for your repository to be created.
>>
>> Cheers,
>>   Albert
>>
>>> which is why for example I do not create any
>>> new ones and instead use github. Although TBH the UX of creating a
>>> scratch has also left me wanting as it entails me googling how to
>>> setup a scratch every single time.
>>>
>>> HS
>>
>>

Re: github, phabricator: a new threadZ

[Harald Sitter]

On Thu, Aug 10, 2017 at 11:06 AM, Adriaan de Groot  wrote:
> Perhaps we should ask sitter what kinds of scratch repo's those were, and
> whether he would have created them on KDE infra, if there was a similarly
> simple one-click way to create scratch repo's.

- experimental snap build tooling for neon's jenkins
- experimental os-autoinst (openqa) tooling
- experimental jenkins plugins (later migrated to git.kde for rollout)
- experimental api.projects.kde.org (later migrated to git.kde for rollout)
- experimental appstream health to junit converter
- experimental filelight-ming32 build using only cmake
- experimental plasmoid to track packagekit activity (later migtated to git.kde)
- experimental dbus traffic recording and playback system for mocking
services on a dbus level
- various rbot plugins (later migrated to git.kde)
- assistive service for logind session cleanup for racnoss (later
migrated to git.kde)
- sftp-to-http bridging service for neon's jenkins to get access to
pre-release tarballs
- experimental snap bundle running an entire plasma desktop
- experimental apache config example for transparent fallback from
drupal to a static set of pages on 404
- migration script for kanboard to phabricator (which was used to
migrate KDE todos)
- some other experimental helpers mostly to assist with one of the
aforementioned things

Everything denoted experimental was created not knowing if this is
production viable or even worth seeing through to production quality.
Barring a minor problem with git.kde not being able to support https
clones with `go get` I'd probably have created them all as
"throw-away" repos on KDE infrastructure since there is no immediate
benefit to these things being on github.

For good measure in the same time period I've forked or worked on
forks of the following on github:

- aptly (repo server used by neon)
- appstream & appstream-generator
- various jenkins plugins
- the bot service which closes PRs against KDE's github mirror repos
- repology (distro-package-version-tracking website)
- various ruby gems
- snapd & snapcraft
- packagekit

On that note: anecdotal evidence suggests that a lot of jenkins
plugins suffer from the "dead repo" problem often mentioned. 3/3
plugins I submitted PRs against have not gotten a review or only after
months sitting there. They are all under the shared community
jenkinsci organization though.

And on a further note since I write a lot of ruby: I'd have to think
twice or trice about putting "vast/complex/more than a bunch of lines"
ruby software on KDE infrastructure, even if the software was very
related to a KDE project. I'd miss out on easy access to the vast ruby
ecosystem centered around github. That's not necessarily an
infrastructure fault on our side, but I thought I'd mention it. Food
for thought: maybe KDE infra should feel similarly like a want-have
when writing qt software.

HS

Re: Applications Lifecycle Policy

[Harald Sitter]

On Tue, Jul 4, 2017 at 1:43 PM, Kevin Ottens  wrote:
> Hello,
>
> On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>
> Didn't we have cases of applications moving between KDE Applications and
> Extragear?

Probably.

I do wonder if we can, maybe, get rid of Extragear as a thing
altogether. Extragear applications are KDE applications on their own
release schedule. At least for the purposes of the lifecycle I'd think
they are one and the same. Separating them by name only and calling
one "extra" kind of implies that the others are
common/normal/standard/default, when in fact they are simply released
at different points in time but otherwise the same.

Tearing down this artificial wall may well incline extragear apps that
have a particularly irregular release schedule to switch to the bundle
releases to get bugfixes out (i.e. committing to releases seem less of
a daunting thing) or the other way around if the fixed schedule turns
out to not work in an application's favor (I seem to recall Marble
having had some trouble with release prep).

(I do appreciate that this may also blur the line a bit too much given
we refer to the applications release as "The" KDE Applications
releases)

HS

Re: Applications Lifecycle Policy

[Harald Sitter]

On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf
 wrote:
>> This comes again from the diversity in view: for me the review, with all
>> its limits, it's the baseline.
>> As showed in the discussion, releasing from playground is not more
>> complicated than other type of releases.
>
> Yes, I'm fine with that. I just wanted to make sure releasing from
> playground doesn't require any exceptions but is regular procedure.
>
>> It's just when it becomes "too much" that
>> people start asking "why not go for a proper review". It's not different in 
>> my
>> opinion from new contributor submitting patches until someone see that
>> it's "too much" and start asking "why don't you get a proper account".
>
> Essentially managing the system by applying some peer pressure to get
> people out of playground.
> Personally I don't find that necessary but it's a valid approach of
> course.

Releasing from playground ad infinitum seems to have some disagreement.

As was already pointed out, once the cost/benefit ratio becomes
acceptable most devs will probably just go for review anyway.
Playground becomes a disadvantage when you need a stable branch with
l10n for example. Ultimately the cost is more on the review side I
think, more than anything else anyway. If it wasn't for the review
it'd be a matter of filing some paperwork to get the move done.

There are two problems which seem to get ignored with reviews though
and they ultimately play into the projects-arent-moving-to-kdereview .

1. Our manifesto establishes shared ownership of software licensed
under an acceptable free software license and using our established
practices. Yet we do not verify or enforce this up until the project
gets to kdereview. At which point it may well have had 50 distinct
contributors claiming copyright under the GPLv1 making relicensing a
right hassle.
2.  While kdereview certainly establishes a baseline quality, unless
the software dies right after review or gets 0 feature development
(both of which aren't good I'd say) the longer it exists the shittier
it gets as the time since review keeps growing.

I guess the question is really: What is playground?

Is it us, KDE, writing new software?
or is it
Someone else writing new software?

And as a consequence of that: Why do we have this hurdle to get out of
playground?

We do not review the maintenance of the baseline we established during
review. I am guessing we do not re-review because the expectation is
that the authors are able to follow our community policies after the
initial review. Fair assumption for sure. BUT if we, KDE, are to be
trusted to maintain the baseline without re-review, then why are we
not trusted to write new software with that same baseline?

For new stuff that comes in via incubation the review is certainly
sound. If nothing else it asserts our policies on the pre-existing
code base. If the authors continue to implement the community policies
after review, is assumed but not verified, they are now KDE, so they
are trusted to maintain this level.

Food for thought.

(to make this clear: I am not necessarily saying kdereview as a step
needs to go, I am saying we are turning a blind eye to the fact that
we take no measure to maintain review quality rendering the notion of
reviews sem-moot, all the while our new and most vulnerable code sits
there potentially incorrectly licensed)

>From where I am standing we should have a stage before playground.
Scratch repos if you will (although those are slated for deprecation
without replacement). This addresses the code-dumping github-like use
case, no tickets, little overhead. If it doesn't work out you throw it
away. This gives us an actual playground: "I need no translations, no
CI, no nothing, I am prototyping here" (think pre-alpha). From there
it can proceed to playground (alpha stage). This is automatically a
submission for continuous(?) casual review. It is at this point under
joint ownership so we ought to assert our policies hence the casual
review. Once ready (as determined by the authors) it moves to
frameworks/plasma/applications.
I understand this is a bit of a hippie workflow, but think about it
this way: the reason we don't just review playground is that it's
potentially little to no code and/or heavily rotating code, neither of
which makes it easy to do a review. If the software is out of initial
protoyping we have code to review and it's far less rotating already
(the degree of rotation matters little, as the assumption continues to
be that once we assert our policies they will get continuously
implemented by the author). At the same time this removes almost all
the policy overhead of moving from playground to the final
destination. The code is already reviewed, all it takes is a ticket to
become a proper application.

TLDR: instead of making people not get too comfortable in playground
make them more likely to want to move to applications (by making that
super easy)

HS

Re: github, phabricator: a new threadZ

[Harald Sitter]

On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt  wrote:
> On Wed, 9 Aug 2017, Riccardo Iaconelli wrote:
>
>> This is a new thread entirely, but incidentally also something we
>> should also think about. Why many KDE developers choose github instead
>> of scratch KDE repositories to start new software, where it could
>> happily be hosted within KDE infrastructure?
>
> Our infra doesn't offer scratch repos anymore, does it?

It does, they were slated for removal with the transition to phab,
since that hasn't happend yet though I assume scratch repos are still
a thing. Albeit, a thing that is meant to be removed with (currently)
no replacement planned which is why for example I do not create any
new ones and instead use github. Although TBH the UX of creating a
scratch has also left me wanting as it entails me googling how to
setup a scratch every single time.

HS

Re: Splitting Craft, move the recipes to GitHub

[Harald Sitter]

On Wed, Aug 23, 2017 at 4:24 PM, Sebastian Kügler  wrote:
> Could you not merge these things from github somehow, so that we can keep the
> canonical copy on KDE's git, or perhaps also pull recipes from github, *in
> addition to* KDE's git?

2 cents: some people already do that one simply needs to whitelist the
repo from bot autoreply and handle pull requests manually. Git being
what it is, there really is no technical reason against github being
an additional UI on top.

HS

Re: phab reviews

[Harald Sitter]

On Fri, Aug 25, 2017 at 2:00 PM, Ben Cooksley <bcooks...@kde.org> wrote:
> On Fri, Aug 25, 2017 at 8:59 PM, Harald Sitter <sit...@kde.org> wrote:
>> For one it makes it hard to keep on top of reviews across all our software.
>> More importantly though, how exactly do we expect a drive-by
>> contributor to figure this out? I work in the community for years and
>> yet often enough struggle to find a relevant person to set as
>> reviewer.  Not just figuring out their name on phab, but even finding
>
> You can search by someone's actual name in any autocomplete prompt
> where names are accepted I believe, so not knowing their username
> shouldn't be an issue.

Not from `arc` which is a wholly different problem I suppose. But yes,
it's kinda manageable, just not all that convenient. The tricky bit is
really figuring out who to set as reviewer to begin with.

>> out who is relevant in the context of the repo. There are projects who
>> have no real prominent head so looking at the git log basically gives
>> you a bunch of drive-by commits.
>>
>> Can we improve this somehow?
>>
>> Not particularly enjoyable but working solutions I have in mind:
>>
>> a) establish phab team of volunteers to get spammed by all reviews (or
>> more ideally reviews without reviewer set) and then either sort out
>> the best reviewer or review it themself
>>
>> b) perhaps more scalable: no automatic subscription of the team but we
>> change the wiki to tell the submitter to use the aforementioned team
>> as reviewer when he doesn't know any better person
>
> Phabricator has two different tools which can help us here: Herald and Owners.
>
> Owners is a utility which allows someone to say what paths in a given
> repository they are responsible for. These packages can then be either
> used by themselves, or utilised by Herald rules.
>
> Herald is an extremely powerful utility, which has the power to do ...
> way too many things to list here.
>
> One of those things is the ability to automatically subscribe Projects
> or Individuals to reviews, or add them as reviewers or blocking
> reviewers. Depending on how a given Herald rule is setup, it can
> enforce this - escape is impossible.
>
> Please see https://secure.phabricator.com/book/phabricator/article/owners/
> and https://secure.phabricator.com/book/phabricator/article/herald/
> for more detail on what they're capable of.
>
> There is a performance penalty to be paid with Herald however of
> around 1ms per rule we have, which is why access to Herald is
> restricted to Community Admins.
>
> We currently have rules to cover: Okular, Dolphin & Konqueror, All
> Games, Kile, Konsole, Simon, Documentation (all repositories),
> Frameworks, KWin, Plasma, KWayland, Kirigami, Ark, Kate, KProperty,
> KDb, Calligra, Kexi, Plasma, Marble, KDE PIM, All Utils Apps, KDevelop
> and RKWard.
>
> These rules essentially CC the mailing list for those projects, and in
> some instances add the appropriate project as a reviewer. At the very
> least it should ensure it's brought to the attention of involved
> developers.

Thanks for the info.

So, I think there are two problems we need to deal with: the internal
and the external.

Internally developers need to be pro-active in ensuring their products
have a subscriber. Which they can do with Owner packages it seems. In
fact we could perhaps automate this (initially on repo creation?). We
have a members property in our repo-metdata yamls, so we could have a
package for each repo that tracks all files and subscribes the Owners.
That way technically every repo has a reviewer. I am not sure if doing
it automatically is necessarily a good idea, perhaps only for new
repos upon initial creation? What we certainly could do is create a
package for each repo so people just need to add themselves as owners.

Externally we still need a fallback system though as to remove the
"your stuff doesn't get reviewed unless you define a reviewer"
problem. That's where I think a volunteer team of global reviewers
would come in handy. A global Herald rule acting on no-reviewers &&
no-subscribers to then add the Global Reviewers as subscriber would
make sure every diff ends up in someone's inbox. The team's action
could then be to identify the actually responsible person and make
sure they are set as owner (as per above), subscribe a more relevant
team, or do the review themselves.

With this combination, 99% diffs would have some owner(s)
automatically set as a reviewer and the remaining 1% would get handled
by a team to make sure nothing falls through the cracks.

Does that make sense?

HS

phab reviews

[Harald Sitter]

Hola!

Our phabricator guide says that at least one person needs to be set as
reviewer to get any review.
https://community.kde.org/Infrastructure/Phabricator#Posting_a_Patch

This sucks.

For one it makes it hard to keep on top of reviews across all our software.
More importantly though, how exactly do we expect a drive-by
contributor to figure this out? I work in the community for years and
yet often enough struggle to find a relevant person to set as
reviewer.  Not just figuring out their name on phab, but even finding
out who is relevant in the context of the repo. There are projects who
have no real prominent head so looking at the git log basically gives
you a bunch of drive-by commits.

Can we improve this somehow?

Not particularly enjoyable but working solutions I have in mind:

a) establish phab team of volunteers to get spammed by all reviews (or
more ideally reviews without reviewer set) and then either sort out
the best reviewer or review it themself

b) perhaps more scalable: no automatic subscription of the team but we
change the wiki to tell the submitter to use the aforementioned team
as reviewer when he doesn't know any better person

HS

Re: phab reviews

[Harald Sitter]

On Sat, Aug 26, 2017 at 1:06 PM, Ben Cooksley  wrote:
>> fact we could perhaps automate this (initially on repo creation?). We
>> have a members property in our repo-metdata yamls, so we could have a
>> package for each repo that tracks all files and subscribes the Owners.
>> That way technically every repo has a reviewer. I am not sure if doing
>> it automatically is necessarily a good idea, perhaps only for new
>> repos upon initial creation? What we certainly could do is create a
>> package for each repo so people just need to add themselves as owners.
>
> I haven't checked to see if there are any scalability limitations
> within the Owner packages system, so it may be worth keeping that in
> mind.
>
> For repositories which are maintained by a single person (primarily
> Extragear and Playground, and to a lesser extent Applications) this
> should be fine. If there are 2-3 repositories which make up the same
> logical group (such as Atcore and Atelier to use one example) then it
> would probably be better to cover them with the same rule (as they're
> one "package")

Organizationally that would make sense, from an implementation POV it
depends... The question is if we want to automate this or not. If it's
fine for a sysadmin to create the Package line-up manually upon repo
creation that'd be the time to group things, which makes a lot of
sense and is how Ownership is meant to be used anyway. If we want this
to happen automatically by inferring data from repo-metadata we'll
currently not have the "grouping" context information to do that
(which could, of course, be added if need be but generally increases
complexity).

> For large groupings of repositories, where the review is by a group of
> people (like for Frameworks and Plasma for instance) we probably want
> to continue using Herald rules for those, as then we don't have to
> replicate the project to repository mapping.

Given frameworks have dedicated maintainers I think there it would
also make sense to have them always set as reviewers (in addition to
having the ML subscribed I guess). Overall I'd say that's a matter of
individual policy of the teams/individuals though?
The problem with mass subscription is that the better part of ML
subscribers will outright ignore/filter the review mails rendering
them largely moot. I recently had an encounter where someone
complained about me not putting a reviewer on a Plasma diff when in
fact the auto-subscription of Plasma was active (the diff hadn't
gotten a single comment). With ML subscriptions it is really easy to
ignore them, not just technically but also socially aka "someone else
from the ML will deal with this so I don't need to".

I really wonder if diffs with ML subscriber shouldn't also end up in
the no-reviewer bucket via Herald. At the end of the day they still
need someone to make sure the diffs get a review, and from personal
experience, I am not convinced the MLs are necessarily able to take
care of that, whereas a dedicated global reviewer team might.

> I'm not sure if Owner packages have the power to subscribe mailing
> lists or projects to reviews - this is something Herald is certainly
> able to do though.

>From a bit of playing around it seems to me that the same way it is
done for Herald will work for Owners. Any user/project entity can be
owner, if a user has a ML address the ML will get the mail.

>>
>> Externally we still need a fallback system though as to remove the
>> "your stuff doesn't get reviewed unless you define a reviewer"
>> problem. That's where I think a volunteer team of global reviewers
>> would come in handy. A global Herald rule acting on no-reviewers &&
>> no-subscribers to then add the Global Reviewers as subscriber would
>> make sure every diff ends up in someone's inbox. The team's action
>> could then be to identify the actually responsible person and make
>> sure they are set as owner (as per above), subscribe a more relevant
>> team, or do the review themselves.
>
> The only potential issue I see with that is i'm not sure what the
> order of evaluation is here. It is possible that this ends up being
> executed before other rules which would have added reviewers so you
> may end up with false positives here. Is that something the global
> reviewers folks would be happy to handle?

Can we test this? Supposedly phab would be able to figure out that a
rule without repo restriction is more generic and thus ought to be
applied later, whether it does that or not is a different story xD

Ideally, I'd say reviewers should only be added via Owners, and Herald
should only add subscribers. And then my thought from above would
apply that a diff without reviewer is always in need of shepherding
from the team even if it has a ML subscriber. Whether that is
sustainable is something we'll have to try and see I guess.

HS

Re: Reminder: KDE (AT) MeetUp: 27th of October in Vienna

[Harald Sitter]

Ah uh ah, I shall attend!

See you there ^^

On Tue, Oct 24, 2017 at 8:47 PM, Stefan Derkits  wrote:
> Hello fellow (Austrian) KDE People,
>
> this is a short reminder about the upcoming KDE MeetUp in Vienna this
> Friday:
>
> KDE Austria MeetUp:
>
> When: 27th of October, 7 pm
> Where: Point Of Sale, Schleifmühlgasse 12, 1040 Wien
> Reserved under the name KDE
>
> Hope to see many of you there,
> Stefan
>

bugzilla, it's products, how they relate to projects. it's a mess...

[Harald Sitter]

Hola!

Every other month I run my head into the desk over bugzilla products -.-

- 99% of time if I want to file a bug against a new project that
project has no product in bugzilla at all
- unmaintained-ness is not reflected. you can file bugs against
https://bugs.kde.org/enter_bug.cgi?product=blogilo all you want no one
will care as it is unmaintained (which BTW is also a problem
cgit/phab has)
- product spelling inconsistent (upcase-downcase-somecase)
- product name has zero relationship to ANYTHING (can be made up
https://bugs.kde.org/enter_bug.cgi?product=Active or the repo name
https://bugs.kde.org/enter_bug.cgi?product=blinken or have a prefix
https://bugs.kde.org/enter_bug.cgi?product=frameworks-kdewebkit or a
project can also be a component in another product
https://bugs.kde.org/enter_bug.cgi?product=Breeze=Icons)
- sometimes there's multiple products?!?
https://bugs.kde.org/enter_bug.cgi?product=frameworks-kdesu vs.
https://bugs.kde.org/enter_bug.cgi?product=kdesu vs.
https://bugs.kde.org/enter_bug.cgi?product=kde-cli-tools [the latter I
only mention because I happen to know that kdesu is part of it]

I don't like going to our bugzilla.
Not being able to file a bug because I can't find the product is so
very frustrating and sad.

Can we please establish a workflow so that every project we run has a
bugzilla product with suitable name (step for sysadmins when creating
new repos)?

HS

Re: Discourse

[Harald Sitter]

On Tue, Oct 30, 2018 at 8:38 AM Boudewijn Rempt  wrote:
>
> On maandag 29 oktober 2018 19:31:54 CET Jonathan Riddell wrote:
> > Discourse is modern forum and mailing list software.  Examples at
> > https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
> >
> > I went to a talk at the Embedded Linux Summit about how Fedora moved to use
> > Discourse.  Similar to the discussion of moving away from IRC we had last
> > year I see people moving away from mailing lists and new contributors not
> > wanting to get into them.  Our KDE Forums also look quite old school.  In
> > Fedora they moved to Discourse and mailing lists and forums and saw a
> > marked increase in engagement.
> >
> > I think KDE should consider moving away from mailman and onto Discourse and
> > at the same time forum.kde.org could move to this more modern software. It
> > might also help cover Boud's use case of a user support method for people
> > with queries before the report a bug.
>
> I don't think it's really comparable. Discourse might be a good alternative
> for mailing lists and forums, where people have discussions, but it doesn't
> look like a good alternative for a solution where people who have a problem,
> ask about it, and get a (semi-automatic) answer because it's been asked a
> hundred times before. It's the latter we really need :-)

Yeah, I don't think it's really suitable for a help desk. Specifically
since for a help desk you want the software to assist you in seeing
unresolved and unanswered tickets and easily fire canned responses, so
it very much needs special software.

HS

Re: Discourse

[Harald Sitter]

On Tue, Oct 30, 2018 at 7:28 AM Ben Cooksley  wrote:
> thanks to Docker's lack of user namespaces

Docker has user namespacing. At blue systems we've been using it since
September 2016

https://docs.docker.com/engine/security/userns-remap/

HS

Re: Discourse

[Harald Sitter]

On Mon, Oct 29, 2018 at 7:32 PM Jonathan Riddell  wrote:
>
>
> Discourse is modern forum and mailing list software.  Examples at 
> https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
>
> I went to a talk at the Embedded Linux Summit about how Fedora moved to use 
> Discourse.  Similar to the discussion of moving away from IRC we had last 
> year I see people moving away from mailing lists and new contributors not 
> wanting to get into them.  Our KDE Forums also look quite old school.  In 
> Fedora they moved to Discourse and mailing lists and forums and saw a marked 
> increase in engagement.
>
> I think KDE should consider moving away from mailman and onto Discourse and 
> at the same time forum.kde.org could move to this more modern software. It 
> might also help cover Boud's use case of a user support method for people 
> with queries before the report a bug.

I love using discourse and am totally in favor of using it. It has so
much more enjoyable UX than just about any other forum software I've
ever had to use. And the ability to bridge the divide between what
developers use (email) and what users use (forum) is a dream come
true!

HS

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
>
> On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
>
> > - human sets needsinfo
> > - 15 days pass: bot posts reminder
> > - reporter comments
> > - N days pass: bug gets automatically dropped back to whatever the
> > previous state was?
>
> Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.

Cool. Should be easy to do.

Any disagreements from the rest of the community?

TLDR: if the original reporter comments on a needsinfo bug it gets
automatically switched back to whatever the state before needsinfo was

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Fri, Nov 16, 2018 at 2:40 PM Alexander Potashev  wrote:
>
> пт, 16 нояб. 2018 г. в 16:35, Boudewijn Rempt :
> >
> > On vrijdag 16 november 2018 14:31:39 CET Alexander Potashev wrote:
> >
> > > You only considered to case when human sets NEEDSINFO. If NEEDSINFO is
> > > set by a script, we may have the same problem, would you suggest
> > > implementing the same behaviour?
> >
> > We don't have the script setting NEEDSINFO, do we? At least, I didn't see it
> > in Harald's list of options.
>
> Hopefully we don't. I noticed such change in some bug reports, however
> all of them are attributed to Andrew himself, not the "bug janitor"
> account. Sorry for the noise.

Indeed. There is no such script and there are no plans for such a script.

As mentioned in the other thread: if a bug change/comment was not made
by the janitor account it's not an automated change. A human may still
use boilerplate triage text on multiple bugs mind you :)

HS

Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)

[Harald Sitter]

On Fri, Nov 16, 2018 at 10:37 AM Luigi Toscano  wrote:
> Please disable it for now, or just enable it for projects who explicitly wants
> it for now.

As mentioned on IRC: everyone please note that unless a change was
made by bug-jani...@kde.org it was not actually done automatically (or
not that I know of anyway).
To that end please please please do not confuse needsinfo reminders
and closures (which are automated) with changes the bug squad does (a
human doing it). Confusing the two makes it really hard for everyone
to know what we are talking about.

If the janitor does a change that you think is incorrect please poke
me with link as it's possibly a bug in the bot, or may need policy
adjustments.

HS

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

(Pulling this back to the NEEDSINFO thread since it sounds unrelated
to what Luigi was writing about in the Policy on stale bugs thread)

On Fri, Nov 16, 2018 at 12:51 PM Boudewijn Rempt  wrote:
> I know it's well-meant, and it does help to get old bugs resolved -- but it
> really should use a script that checks whether the original reporter has added
> a comment since it was set to needinfo, and in that case just reopen it.
>
> I know that the script that was intended to do that didn't work, and I've
> tried to figure out whether I could fix it, but failed in that. But right now,
> the closing to WORKSFOME plays havoc with my bugzilla routine -- and worse, it
> makes me hesitate to put bugs in the NEEDINFO state.

So... the current behavior is:

- human sets needsinfo
- if no human responds within 15 days since last update the bot posts
a reminder (this can repeat ad infinitum if the status doesn't get
changed away from needsinfo but comments get posted)
- if no human responds within further 15 days the bot closes the bug
(which may also happen if information was provided by the status was
not changed in 30 days)

e.g.

- human set needsinfo
- 15 days pass: bot posts reminder
- reporter comments
- 15 days pass: bot posts reminder
- 15 days pass: bot auto-closes

If I understand your suggestion you'd like it to switch automatically
out of needsinfo upon comment from the original reporter?

e.g.

- human sets needsinfo
- 15 days pass: bot posts reminder
- reporter comments
- N days pass: bug gets automatically dropped back to whatever the
previous state was?

Re: Bugzilla template problems

[Harald Sitter]

Oh btw, just as a random FYI: I think stuff like this is why ubuntu
eventually ended up having a GUI tool (ubuntu-bug) to help file bug
reports with useful metadata. Putting it on the user to figure this
stuff out is unreliable at best and can easily get overwhelming.

Re: Bugzilla template problems

[Harald Sitter]

On Thu, Oct 4, 2018 at 6:14 PM Nate Graham  wrote:
>
> Can the template be overridden on a per-project basis?

Yes.

[% IF product.name == 'foobar' %]
...
[% END %]

I think making the template text more generically applicable is more
reasonable though. Otherwise the about system bit can basically only
be shown for plasma products as everything else may very well have
(more) !plasma based users than plasma based ones. Also, adding
per-project conditionals in the template is probably going to get a
maintenance burden quickly.

Reference of the template language for prosperity:
http://www.template-toolkit.org/docs/manual/index.html

HS

Re: Bugzilla template problems

[Harald Sitter]

I do have a task on my to-do list for improving this using the new API we
can use nowadays. So, it's possible to make this lots better and just needs
coding really. If anyone wants to try I can mentor or give emotional
support :)

On Fri, Oct 5, 2018, 09:16 Kai Uwe Broulik  wrote:

> Am 04.10.2018 um 22:11 schrieb Harald Sitter:
> > Oh btw, just as a random FYI: I think stuff like this is why ubuntu
> > eventually ended up having a GUI tool (ubuntu-bug) to help file bug
> > reports with useful metadata. Putting it on the user to figure this
> > stuff out is unreliable at best and can easily get overwhelming.
> >
>
> +1
> I find it odd that you can write meaningful bugreports using DrKonqi
> that include version information and find the correct component whereas
> the "Report a bug" in "Help" just opens bugzilla webpage.
>
> It does fill out the correct product and version but could surely be
> improved or turned into a proper wizard with some tips and tricks and
> duplicate finder and what not.
>

Re: Discourse

[Harald Sitter]

On Thu, Nov 29, 2018 at 5:41 PM Luca Beltrame  wrote:
> > Can you describe these workflows a bit?
> > There is this https://www.discourse.org/plugins/akismet.html not sure
>
> Is it  Akismet in name, or uses the service?

I am not sure what that means I am afraid.

> > it's sufficient though. One could always opt to write custom plugins
>
> The idea would be, if possible, to prevent the mistake made in the past
> and use custom stuff only if absolutely necessary (that's what got us
> in the current mess in the first place).

I think we can all agree on not wanting anymore unmaintained code :)

HS

Re: Discourse

[Harald Sitter]

On Tue, Dec 4, 2018 at 1:31 PM Luca Beltrame  wrote:
>
> Il giorno Tue, 4 Dec 2018 12:48:48 +0100
> Harald Sitter  ha scritto:
>
> > OTOH I also don't understand how the current spam protection works. Do
> > we maintain a list of blacklisted words? Because from what I
> > understand discourse has that built in. Along with blocking by IP.
>
> Yeah, it works something like that. I don't know if it is connected to
> stopforumspam (nor if stopforumspam actually exists anymore), but it
> does "flag" messages on words, number of posts, etc. Moderators then
> can inspect the flagged messages.
>
> The current nice thing (but that's to workaround a huge deficiency of
> the UI in phpBB - perhaps it has changed in recent versions) is that it
> also offers a one-click ban that bans the user and wipes all the posts
> by the same user in one fell swoop.

If there's nothing additional I think all of what we have currently is
already supported out of the box in discourse:

- filters
- easy nuking; looks like this apparently:
https://meta.discourse.org/t/new-user-deleted-for-spam-posts/53647/2

On top of that I also found something else: limited new user abilities
through a trust level system; I would actually encourage forum staff
to read up on this feature [1] as it sounds like something that could
be super nice in practice. It also plays a part in the spam protection
story.

(also see wiki page for some info on that entire feature set [2])

[1] https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/
[2] https://community.kde.org/Infrastructure/Evaluation/Discourse#Anti-Spam

HS

Re: Discourse

[Harald Sitter]

I've started a wiki page. I encourage people to chip in.

https://community.kde.org/Infrastructure/Evaluation/Discourse

HS

Re: Discourse

[Harald Sitter]

On Tue, Dec 4, 2018 at 12:03 PM Luca Beltrame  wrote:
>
> Il giorno Tue, 4 Dec 2018 11:58:27 +0100
> Harald Sitter  ha scritto:
>
> > > Is it  Akismet in name, or uses the service?
> > I am not sure what that means I am afraid.
>
> Akismet is a (non-Free) antispam service used originally by
> Wordpress.com, optionally self-hosted WP, but now used also by other
> software. It looks, from the name, that this plugin interrogates
> Akismet. IIRC only "personal" usage used to be free (but I haven't been
> checking in years, so this might be all wrong).

Aha!

"Akismet is a well known service that has an algorithm for detecting
spam. Akismet is NOT free for commerical use, but can be for personal
use. To use this plugin you will need an Akismet API key. You can get
a key by starting out here."
https://github.com/discourse/discourse-akismet

So, yeah, no goody.

OTOH I also don't understand how the current spam protection works. Do
we maintain a list of blacklisted words? Because from what I
understand discourse has that built in. Along with blocking by IP.

HS

Re: Discourse

[Harald Sitter]

On Thu, Nov 29, 2018 at 9:03 AM Ben Cooksley  wrote:
>
> On Wed, Nov 28, 2018 at 5:25 AM Lays Rodrigues  wrote:
> >
> > Let's not go in that way.
> > As a ~new person~ on KDE, 3 years only, we need to move to a modern web. At 
> > least in my point of view, I really think that using old stuff doesn't 
> > attract new people. In that I have a few ideas for some KDE websites go 
> > modern, but that is a project for the future.
> > Discourse is a way to do that. I don't have much idea on how is the cost to 
> > maintain such an application, but in the field to setup it, I don't
> > think that is hard since we just need docker and Postgres.
>
> Before we look into deployment, has an initial evaluation been done to
> determine how individual communities around specific applications
> would work with Discourse?

How would one best go about evaluating? Do we know what communities do
with the current forums? Do we have the original evaluation of how we
ended up with phpbb somewhere?

> Usually these communities only want to look at posts for their
> specific application, and in some cases we have customisations to
> support their specific usecases - which our existing forum supports
> (see https://forum.kde.org/viewforum.php?f=276 for instance).

Which customizations are there, what do they do, where is their code
and who maintains them currently?

> Once we're satisfied that's all okay and can accommodate everything we
> need, we then can look into deployment. At this point we'd:
>
> 1) Look into the actual technology stack they use (seems to be Rails
> based in this case) to make sure there aren't any potential snags
> there
> 2) Evaluate what support it has for authentication options (Identity
> requires LDAP at the moment, but will move to OAuth2 at some point
> using a custom API)

I've just had a look... Writing auth plugins is insanely easy. As in:
I probably spent magnitudes more time on our jenkins oauth plugin than
it would take to write any auth plugin for discourse ^^

> 3) Determine what's needed to import existing data we have

A full phpbb database dump from starters. Beyond that I am not sure
what existing data actually entails?

In fact, I am also not sure why everyone seems to consider importing
10 year old forum posts a given requirement here. We migrated away
from reviewboard with zero data migration, and the data that is in
reviewboard is largely much more relevant than posts on why changing
the wallpaper in Plasma 4.0 didn't work IMHO.
Data migration is hugely expensive in both human and computer time;
it's easy to say we want this, it's another thing to actually
practically make it happen. In fact, I know of a semi-recent forum
migration where a company that heavily relied on forums for user
interaction migrated by having users manually replicate threads they
wanted to keep into the new forum and after a couple of months threw
the old forum away. Often times the cost-benefit is just super poor
for data migration in general and most kinds of forums in particular.

That being said, if data can be easily migrated I say hooray. Whether
it deserves to be a requirement I am not so sure about.

> 4) Ascertain how best to structure things to make it easy for
> end-users to work with
> 5) Investigate what anti-spam options are available and how
> maintainable any customisations we need to support KDE specific
> workflows will be

Can you describe these workflows a bit?

There is this https://www.discourse.org/plugins/akismet.html not sure
it's sufficient though. One could always opt to write custom plugins
if necessary, that really depends on what we need though. AFAIK
discourse also has a fairly comprehensive REST API, so one could
possibly also approach it from the other end and have a micro service
hit spammers with a ban hammer after the fact.

> My main one here is the lack of any options for installation other
> than Docker which makes no sense for a Rails application. Looking into
> their Docker image installation script I see that they build both
> Nginx and Imagemagick themselves (and stepping outside of package
> repositories is generally a bad idea). Imagemagick is of grave concern
> as this project has had numerous security advisories in the past and I
> see the version they're using isn't the latest one. I have further
> concerns for Nginx as they include a third party compression module,
> Brotli, whose codebase hasn't been touched in 2 years (plus it's a
> compression method, so you have the risk of CRIME/BREACH attacks)

https://github.com/discourse/discourse/blob/master/docs/SECURITY.md

HS

Re: Discourse

[Harald Sitter]

On Thu, Nov 29, 2018 at 11:54 AM Boudewijn Rempt  wrote:
>
> On donderdag 29 november 2018 11:32:12 CET Harald Sitter wrote:
>
> > In fact, I am also not sure why everyone seems to consider importing
> > 10 year old forum posts a given requirement here. We migrated away
> > from reviewboard with zero data migration, and the data that is in
> > reviewboard is largely much more relevant than posts on why changing
> > the wallpaper in Plasma 4.0 didn't work IMHO.
>
> I would for sure hate losing all those years of history and discussion for the
> Krita forums. Posted artwork, discussions, development suggestions, answers to
> questions.

FWIW an approach I proof-of-concepted for reviewboard and which may
also work for phpbb is to simply crawl a html snapshot and host that
instead. i.e. one would still be able to view the content without
having to maintain the software setup.
Mind you, I fully appreciate that losing history is terrible no matter
the data, my point is that dragging the data along into other software
may not be the most efficient course of action. It's hard to say what,
if any, excess technical requirements we have to migrate our current
database, which is why I asked so many question :). Just migrating
threads and attachments is something discourse can do just fine
apparently, so if we need nothing else it's probably fairly cheap to
pull the data along, if not we'll need to be flexible.

HS

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Mon, Nov 19, 2018 at 1:12 AM Myriam Schweingruber  wrote:
>
>
>
> On Fri, 16 Nov 2018 at 14:22, Harald Sitter  wrote:
>>
>> On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt  wrote:
>> >
>> > On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote:
>> >
>> > > - human sets needsinfo
>> > > - 15 days pass: bot posts reminder
>> > > - reporter comments
>> > > - N days pass: bug gets automatically dropped back to whatever the
>> > > previous state was?
>> >
>> > Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1.
>>
>> Cool. Should be easy to do.
>>
>> Any disagreements from the rest of the community?
>>
>> TLDR: if the original reporter comments on a needsinfo bug it gets
>> automatically switched back to whatever the state before needsinfo was
>
>
> It slightly disturbs my triaging routine, as I routinely check the NEEDSINFO 
> I set within a month (and I have saved searches for this), so could "my" bugs 
> be excluded, please? It is a really short time span, I always consider people 
> to be away for longer than just two weeks (holidays, etc) which is very often 
> the case. Some bug reports do answer on a regular basis, just noth within 2 
> weeks in all cases.

This is about the original NEEDSINFO discussion, not related to the
question I posed, is it?

If the timing seems unsuitable I'd like changing it discussed within
the bug squad. I am just the code monkey, in that capacity I'd like to
avoid a wall of conditions for every person doing bug triage.

HS

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Mon, Sep 17, 2018 at 8:25 PM Nate Graham  wrote:
> +1, in favor, especially if we can close them in an automated fashion. 
> Closing bugs isn't as frustrating for filers as it used to be anyway, since 
> if they ever show up again with new information, they can just re-open them.

Should be easy to program this if we are agreed on the procedure.

What I would suggest is:

- 15 days after the bug has entered NEEDSINFO and not received any
further comments a comment is automatically posted "yada yada this bug
report needs info, please provide it or ask if you don't understand
what's needed, else closure in 15 days of inactivity" (message TBD
obviously)
- 30 days after the bug has entered NEEDSINFO and not received any
further comments it gets closed with a comment "yada yada no data
provided, if you feel you can provide data reopen and provide data"

by throwing in a comment to "warn" 15 days after the status change
it's not too spammy while also acting as a reminder in case the
subscribers meant to provide the info but then forgot.

Personally I would even say the 15 day reminder should be sent every
15 days of inactivity, because of the reminder aspect (might be a bit
too spammy though?)

e.g.
- NEEDSINFO change
- 15 days pass -> reminder comment
- 3 days pass -> comment gets added
- 15 days pass (33 days since status change) -> reminder comment again
(could be different comment "this bug appears to have gone stale,
please provide info or nudge out of needsinfo")

Anywayyy... I can throw together some automation so long as someone
tells me what exactly the process should be :P

HS

Re: Closing NEEDSINFO bugs after 30 days

[Harald Sitter]

On Tue, Sep 18, 2018 at 12:59 PM Boudewijn Rempt  wrote:
>
> Would it also be possible to automatically remove the needinfo status if the
> reporter adds a comment after it's set to needinfo?

Yes.

Re: Shutdown of paste.kde.org

[Harald Sitter]

On Sat, Feb 2, 2019 at 8:46 PM Ben Cooksley  wrote:
> We'll be shutting this service down in approximately one weeks time.
> Should anyone be using it to store content for long term purposes we'd
> advise you to migrate it to either Phabricator, Gitlab or somewhere
> more permanent (like a wiki) before the shutdown.

How does this affect the playground app cutepaste? Or rather: what's
the plan there?

HS

Re: Shutdown of paste.kde.org

[Harald Sitter]

On Sat, Feb 2, 2019 at 8:46 PM Ben Cooksley  wrote:
> Because this makes it functionally equivalent to the pastebin
> functionality included in both Phabricator
> (phabricator.kde.org/paste/) and Gitlab (invent.kde.org/snippets)
> we've decided that it would be best if paste.kde.org were to be
> discontinued.

Using arcanist we can easily paste from a terminal via `arc paste`
(assuming you've set up arc to talk to our phab that is). For gitlab
there's a range of snipping cli tools you can find as well.

HS

Re: Shutdown of paste.kde.org

[Harald Sitter]

On Tue, Feb 5, 2019 at 9:12 AM Ben Cooksley  wrote:
>
> On Tue, Feb 5, 2019 at 1:26 AM David Narvaez  
> wrote:
> >
> > On Mon, Feb 4, 2019 at 6:52 AM Harald Sitter  wrote:
> > > How does this affect the playground app cutepaste? Or rather: what's
> > > the plan there?
> >
> > There is also kpaste, and none of those have seen commits in 4~5 years
> > so nixing them should not be a problem.
>
> Given that Phabricator has Arcanist for it's pastebin, and there are
> other CLI applications for Gitlab, I don't think we need to take any
> action here with regards to cutepaste or kpaste.

Sure my point was that we do need to do something organisational
considering the software will break (or is already broken what with
login). Perhaps mark as unmaintained?

HS

Re: Anonymous contributions

[Harald Sitter]

On Thu, Apr 11, 2019 at 8:04 PM Nate Graham  wrote:
>
>   On Thu, 11 Apr 2019 11:55:42 -0600 David Edmundson <
da...@davidedmundson.co.uk> wrote 
>  > There are legal implications as the copyright is ultimately held by
real people.
>
> Could we require that anonymous contributors relinquish copyright claims
to KDE?

+1 to David when he says this needs a lawyer. Relinquishing claims is not
necessarily a thing. I, as Austrian, cannot relinquish claims. I can grant
exclusive rights to my copyrighted work that takes away my rights, but I
cannot get rid of my copyright. That could be achieved by e.g. require
licensing the software under a super permissive license. But mind you,
every single piece of code I'd contribute needs to be very clearly marked
as contributed under a permissive free software license, every single
commit, there must not be a single commit for which the question could
arise what license the code was originally contributed under.

And copyright in free software has more implications than just being able
to use the code. What do we do if the code's copyright was never held by
the unreachable anonymous contributor? IOW: what if someone gives us
"stolen" code. So, also +1 to what Christoph said. We never had actual
checks to verify if a contributor's name is in fact their real name and we
may well have anonymous contributors without anyone realizing. Even if we
knew the real names were real enough, that'd be of limited help when we
need to look up the contributor for whatever reason. This even goes beyond
finding a person, how do you proof that the person you found is in fact the
person who contributed the code. They could well deny it and we'd not
necessarily have proof as we have no signed papers or anything.

These two points I expect are why contributor agreements are written the
way they are. Which is likely what we need to have to solve all open
concerns. If we need them solved that is. The unverified contributor scheme
worked for 20 years perhaps it is fine, or maybe we have just been lucky
that it has not caused problems so far. We as a community should figure out
what we want here. Future proof legal documentation or informal trust or
something in between. Personally I'd rather have a more legally verifiable
entry procedure.

As for Eike's concerns. I think he has a point, I also think that
ultimately the "community impact" is somewhat limited. If a person works
under a pseudonym John Smith you can still call them John, you can still
refer to them by name, for all intents and purpose that's just their name.

HS

Re: FSF leadership

[Harald Sitter]

On Thu, Sep 19, 2019 at 10:29 AM Jens  wrote:
>
> TBH I worry less about past transgressions or the communicative fallout
> than I do a lack of response from us. (this is me not having a blessed
> clue what exactly went down 2009)
>
> I do agree with you on many points and I think you raise a lot of good
> concerns at the same time, we missed the boat then to comment - what
> we're seeing now is not a boat ten years travelled, but a new one
> launched from shore so to speak.
>
> I think with a bit of finesse we can use it as a voice of support for
> FSF, a hope to ensure a leadership that can better serve the FSF as
> well as weave it into a comment on our commitment for the same - AND do
> so in a way that can include the ideological diversity of KDE.
>
> In practice (FOR EXAMPLE):
> "We support the FSF in its work to find a new President and would urge
> them to find one that represent the Free Software movement as a whole
> and can grow the entirety of the community.
> We all (the KDE community included) have to ensure that past biases do
> not limit our choices of leadership and that access to Free Software,
> the technologies and the communities isn't blocked by those same biases
> and cultures."

+1 to what Jens said in the entire thread.

I will add that I don't think we need to publicly talk to or about the
FSF specifically though, but maybe I am just not grasping the scope of
the incident there. Perhaps we should; after all, while the FSF is a
separate organization it is still the figure head of the free software
movement as a whole. We are part of the movement and so our opinion
matters and we should make it heard. At the same time I am not sure
what wagging a finger in the particular direction of the FSF
accomplishes.

With that in mind I would propose that we make a statement, but not to
the FSF... our statement should be one in support of a healthy,
diverse and inclusive free software community to that very community
at large. This applies to the FSF, to GNOME, to us, we all need to be
aware of our own biases so we can prevent bias-driven decision making
and foster diversity.

KDE's statement ought to encourage and light the way.

HS

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

[Harald Sitter]

This is an awesome idea! I'm all for it.

Finding someone to fiddle with the website at such short notice may be
problematic though. Social media support should be easy peasy.

On Wed, Sep 18, 2019 at 6:01 PM  wrote:
>
> Hello to all members of the KDE community,
>
> this friday (september the 20th) will be a big day in climate protests and 
> hopefully also in human history: People in more than 3500 places worldwide 
> are joining the Global Climate Strike to draw attention to the rising climate 
> crisis.
>
> The question I want to ask you is: Should KDE join this protests and show 
> solidarity with the people engaging for this very important topic?
>
> I created a phabricator task (https://phabricator.kde.org/T11717 
> ) and will be happy about everyone 
> discussing this very important topic.
>
>
> I figured out two ways for us as a community to participate:
>
> 1. create and publish a social media post showing KDE's support for the 
> movement
>
> 2. join the website strike (https://digital.globalclimatestrike.net/ 
>  
> https://github.com/fightforthefuture/digital-climate-strike 
> ) by showing a 
> full-screen banner on KDE's websites to illustrate KDE's participation, raise 
> awareness for this very important topic and mobilise people to join the 
> protests
>
>
> In my opinion, KDE should not only engage in its "main business" (amazing) 
> free software and all its associated topics, but also topics concerning the 
> wider environment KDE's software runs in.
>
> One first step would be joining the Global Climate Strike to ensure future 
> generations can enjoy KDE's software as we did, and ensure KDE still exists 
> in 100s and 1.000s of years.
>
> The most important part in KDE's community are its members, but which people 
> should be part of KDE when humanity disposes itself due to the extreme 
> climate crisis?
>
> Your's sincerely
> cahfofpai
> =
>
> Ways you could participate in the Global Climate Strike on a personal basis:
> - join a local strike (find one at 
> https://fridaysforfuture.org/events/map?c=+All+countries=2019-09-20=all 
>  
> or at https://globalclimatestrike.net/#map 
> )
> - take part in the website strike with your personal websites 
> (https://digital.globalclimatestrike.net/#website-assets 
> )
> - spread the word on the internet, for example on social media
> - organise a climate strike in your hometown 
> (https://globalclimatestrike.net/organise/ 
> ), if there's not already one

Re: Sysadmin Load Reduction: Code Related Services

[Harald Sitter]

On Sat, Nov 16, 2019 at 10:14 AM Ben Cooksley  wrote:
> (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?)

Correct.

Re: Sysadmin Load Reduction: Code Related Services

[Harald Sitter]

On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley  wrote:
>
> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan  wrote:
> >
> > Hi all,
>
> Hi Carl,
>
> >
> > Can the gitlab api be of useful in the future?
> >
> > e.g https://invent.kde.org/api/v4/groups/7
>
> While for many purposes Gitlab's API wil be perfectly fine, it doesn't
> provide us with the i18n branch information which some users will
> require.

Something to perhaps consider at this point is to revise the
repo-metadata format in general and offload data to gitlab?

Notably I'd kick the following yaml properties in favor of their
literal replacements in gitlab: description, icon, members, name. On a
related note I guess there'd be need to figure out how to map from a
"kde project" to a gitlab project. Currently the paths between
repo-metadata and invent do not line up.

Additionally we may able able to remove:

- hasrepo (repopath==null implies this)
- repoactive (totally not sure what this communicates)

And lastly, fold the i18n data into the yaml. Which I think means we
could drop the excessive use of directories and just have one file per
project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even
more ideally projects/sddm-kcm.yaml (because the current dir structure
duplicates information encoded in repopath; so I would think either we
should drop the property or flatten projects/).

HS

Re: Sysadmin Load Reduction: Code Related Services

[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.

Yet another example of the poor service discoverability we noticed at
the sysadmin bof I guess :/

HS

Re: Sysadmin Load Reduction: Code Related Services

[Harald Sitter]

On Mon, Nov 18, 2019 at 7:33 PM Ben Cooksley  wrote:
>
> On Tue, Nov 19, 2019 at 7:27 AM Albert Astals Cid  wrote:
> >
> > 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.
>
> I think Harald was referring to the 'metadata.yaml' files in
> sysadmin/repo-metadata in this case.

Yep.

Re: Sysadmin Load Reduction: Code Related Services

[Harald Sitter]

On Mon, Nov 18, 2019 at 6:29 PM Ben Cooksley  wrote:
> It'll be hard to tell whether a name is unique or not when creating a
> repository unfortunately.
> For the most part I do not expect collisions to occur though and we
> certainly won't aim to create duplicate names.

Wouldn't creating a repo also include creating the repo-metadata file
for it? Through that it should be easy to assert uniqueness via a
server-side hook on repo-metadata.

In point of fact, if we fully flatten out the files I expect uniquness
would be implicit.

e.g.

repo-metadata/projects/blinken.yaml (repopath: kde/blinken)
repo-metadata/projects/kinfocenter.yaml (repopath: kde/kinfocenter
repo-metadata/projects/www-kde-org.yaml (repopath: sysadmin/www-kde-org)

HS

Re: Issues with the issue tracking system

[Harald Sitter]

Hey.

On Mon, Nov 4, 2019 at 2:12 AM Philippe Cloutier  wrote:
>
> Dear community,
> I am facing 2 issues with the ITS which I cannot solve myself currently.
>
> Over the last months, I requested the "severity" (importance) of several
> tickets to be adjusted:
> https://bugs.kde.org/show_bug.cgi?id=149902#c4
> https://bugs.kde.org/show_bug.cgi?id=317656#c17
> https://bugs.kde.org/show_bug.cgi?id=410284#c7
> https://bugs.kde.org/show_bug.cgi?id=206170#c4
> https://bugs.kde.org/show_bug.cgi?id=408981#c4
> https://bugs.kde.org/show_bug.cgi?id=407059#c1

We don't adjust either field because we feel like it, Martin explains
very well why. Since nobody acted on your proposals the conclusion to
draw is that nobody agreed with them enough to take action.

> No adjustment was done yet. Please either:
> 1. Solve https://bugs.kde.org/show_bug.cgi?id=272388
> 2. Allow more developers to modify the field
> 3. Or perform the requested changes
>
> #3 would already be appreciated, but I recommend more as 6/6 over 2
> weeks after the latest request was done visibly signals a systemic issue.

As Christoph, Martin and David explained now, there is nothing to deal
with in that report ...

>
> As for the more delicate issue, many reports I filed recently against
> bugs.kde.org were mishandled. In fact, most of them were, and that is
> all due to one individual's actions. This can be seen below:
> https://bugs.kde.org/show_bug.cgi?id=411285
> https://bugs.kde.org/show_bug.cgi?id=412299
> https://bugs.kde.org/show_bug.cgi?id=412321
> https://bugs.kde.org/show_bug.cgi?id=413343
> https://bugs.kde.org/show_bug.cgi?id=413344
> https://bugs.kde.org/show_activity.cgi?id=413346

... and I see a pattern here. You may find yourself disagreeing with
an action, that doesn't make the action wrong. Further brigading
doesn't necessarily increase the chances of overturning a decision
either.

> This has been going on for more than a month now, and I now hesitate to
> keep contributing, as I feel many of my contributions would go through
> the trash. I believe I made a fair effort at solving this with simple
> communication, as can be seen in #411285 and #412299, but that avenue
> appears to be insufficient.
>
> On the other hand, I saw the same individual contribute positively
> shortly before, and one who looks well will find a few positive
> contributions even in the above. Health is not my profession, and I do
> not know enough about him to make any kind of diagnosis.

Let me be perfectly clear: you are way out of line here. Which is all
the more concerning considering you have been contributing to KDE for
more than a decade [1] so I am sure you've picked up on how we as a
community conduct ourselves and how we solve issues. Talk with the
affected people and teams on IRC or the respective mailing lists. If
all else fails we have an excellent community working group to help us
resolve conflicts. Throwing mud on the community-wide mailing list is
decidedly not part of the conflict resolution recipe.

What I am observing is a huge disconnect that is best summed up by
your comment here:

https://bugs.kde.org/show_bug.cgi?id=412321#c5

You do not seem to realize that Nate is a KDE Developer, an active and
well respected one at that. He is also a super active bug triager. So
you were not only telling a developer that they can't close your
report because they are in the wrong, you then also go on to explain
to a member of a bug triage team how to triage bugs correctly. "It's
not what you say - it's how you say it" and the way *you* communicated
is with a distinct air of superiority, I'll not faulting anyone for
not being super receptive or engaging after encounters like that.

Finally, we find ourselves here with you implying that Nate is of
unsound mind and needs to be dealt with somehow... You are wrong and
this is utterly disrespectful. Nate is well. He's a treasure to this
community. I have read through the reports and couldn't find him in
the wrong.

I very much urge you to take a step back. Look at your conduct and
reflect on it.

[1] https://bugs.kde.org/show_bug.cgi?id=411285#c9
[2] https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

HS

Re: Feedback on new feature: energy performance settings

[Harald Sitter]

On Wed, Aug 12, 2020 at 7:52 PM John Salatas  wrote:
> It would be good to have a confirmation from more users, before deciding
> whether we will expose the governor settings in the GUI or not.

# AMD Ryzen 7 4800H (acpi-cpufreq):

schedutil/ondemand/conservative: idle at minimum configured frequency,
scales up to maximum freq when running `stress -c 16`
performance: strangely seems to behave more or less exactly like the
scaling governors, might well be a bug in my kernel version as the
documentation says it should run at cap.
powersave: always at minimum frequency

since lower frequency also means lower wattage powersave saves power
by keeping the frequency at the lowest configured value (which on this
system is 1.4ghz; maximum is 2.9 with boost at 3.0-3.2 or so).

2.2W with screen on standby but wifi on.

using schedutil and running stress on all cores for about 5 minutes
the discharge rate is at 33W with frequency being at cap + boosted and
the fan running like crazy.

using powersave and the same stress scenario the discharge rate is at
10W with frequency being locked at configured minimum.

# ARM Cortex-A72 on rpi4 (cpufreq-dt):
same as ryzen except performance behaves as expected and keeps the
cores at the maximum frequency (i.e. as would be expected from kernel
docs)

# ARM Cortex-A9 MPCore (cpufreq-dt):
only seeing performance and schedutil as available governors. behave
same as the A72

HTH
HS

auto-comment on bugzilla when making an MR?

[Harald Sitter]

Salut!

Does anyone think it'd be a worthwhile investment to have some piece
of tech automatically comment on bug reports when someone posts an MR
on invent?

I pretty much never bother posting comments with the MR but at the
same time I know that at least the Plasma team decided to actively use
the Assigned state for bugs.
So I was thinking that it'd perhaps make sense to have automatism in
place that makes sure MRs get referenced in their related bug report
and that the bug is switched into assigned state since it is clearly
being worked on.
Should the MR fall by the wayside for whatever reason a future dev who
happens upon the bug report can at least look up the MR and move it
forward. And using the Assigned state in general seems smart to
prevent multiple people from working on the same thing.

Thoughts?

HS

dictionaryrunner license problems

[Harald Sitter]

Hola

Is anybody willing or able to get in touch with Jason A. Donenfeld?
He's being unresponsive to emails
https://markmail.org/message/xupktbituuuojwip and the dictonaryrunner
he wrote is lacking licensing information
https://invent.kde.org/plasma/kdeplasma-addons/-/tree/master/runners/dictionary

HS

Re: dictionaryrunner license problems

[Harald Sitter]

It's been resolved. Nothing to see here :)

On Thu, Aug 6, 2020 at 6:58 PM Harald Sitter  wrote:
>
> Hola
>
> Is anybody willing or able to get in touch with Jason A. Donenfeld?
> He's being unresponsive to emails
> https://markmail.org/message/xupktbituuuojwip and the dictonaryrunner
> he wrote is lacking licensing information
> https://invent.kde.org/plasma/kdeplasma-addons/-/tree/master/runners/dictionary
>
> HS

Re: Feedback on new feature: energy performance settings

[Harald Sitter]

On Sun, Aug 9, 2020 at 2:05 PM John Salatas  wrote:
>
> Hi.
>
> I just committed a  set of patches for powerdevil [1] and
> plasma-workspace [2] in order to expose
> in the GUI some settings related to the cpu's energy performance.
>
> Apparently, these settings seem to make great difference in the
> performance and battery duration in laptops equiped with modern intel
> CPU (using the intel_pstate driver). Unfortunately I am missing some
> hardware to test it and I would appreciate if could provide your
> feedback and suggestions for your non-intel CPUs (ie AMD, ARM). Testing
> and feedback/suggestions in any case would be highly appreciated as
> well.

Cool stuff.

What kind of input are you looking for exactly? Just whether it also
is useful on AMD and ARM?

HS

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

[Harald Sitter]

On Tue, Jun 16, 2020 at 7:08 PM Albert Astals Cid  wrote:
>
> 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?

Yep. Unfortunately mapping users isn't reliably doable since bugzilla
exists in its own little bubble WRT user accounts.

HS

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

[Harald Sitter]

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.

HS

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

[Harald Sitter]

+1

On Wed, Jun 9, 2021 at 9:28 PM Kenny Coyle  wrote:
>
> So with the licensing question aside, I realise that there is a desire here 
> to have log (and/or metric) aggregation services available for KDE services.
>
> With Akademy happening in a few weeks, should we discuss this in a BoF? I 
> think there's a lot of scope to look at various platforms that provide very 
> similar features to Sentry.
>
> Thanks,
> Kenny.
>
> On Wed, Jun 9, 2021 at 4:21 PM Bhushan Shah  wrote:
>>
>> On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote:
>> > So you can use old sentry versions, which are open source.
>>
>> If you are referring to old snapshot of old sentry version then I would say 
>> it
>> is fairly impossible to use it given using old sentry version would also mean
>> that we need to use older API version and it also means older libraries for
>> client side (for sending data). It is basically a dep hell which is 
>> impossible
>> to overcome.
>>
>> With my sysadmin hat on, I would absolutely oppose to having installation of 
>> 3
>> year old unmaintained software (and its equally outdated dependencies) that
>> are guranteed to get no upates whatsover on our servers in productions.
>>
>> Regards.

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

[Harald Sitter]

On Fri, May 28, 2021 at 12:25 PM Harald Sitter  wrote:
>
> On Fri, May 28, 2021 at 11:43 AM Sune Vuorela  wrote:
> >
> > On 2021-05-26, Anna “CyberTailor”  wrote:
> > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion 
> > >> period)
> > >
> > > So you can use old sentry versions, which are open source.
> > >
> >
> > +1. I think we should support free and open source software.
>
> I do too. I'm curious though: How does using the 4 year old software
> support the software more than using the eventually 4 year old
> software?

I'd really like an answer to that.

HS

is a BSL licensed service acceptable for sysadminy use cases?

[Harald Sitter]

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?

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.

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

[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

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

[Harald Sitter]

On Fri, May 28, 2021 at 12:52 PM Ingo Klöcker  wrote:
>
> On Freitag, 28. Mai 2021 12:36:35 CEST Andrius Štikonas wrote:
> > 2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė:
> > > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela  wrote:
> > > > On 2021-05-26, Anna “CyberTailor”  wrote:
> > > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion
> > > > >> period)> > >
> > > > > So you can use old sentry versions, which are open source.
> > > >
> > > > +1. I think we should support free and open source software.
> > >
> > > I do too. I'm curious though: How does using the 4 year old software
> > > support the software more than using the eventually 4 year old
> > > software?
> >
> > By the way, isn't it 3 year old software. That probably doesn't
> > fundamentally change the discussion. Although, if you use Debian stable or
> > Centos, you probably are using a lot of 3 year old software.

(brainfart - the BSL fallback is 4 years, sentry lowered it to 3 ;))

> Sure, but in Debian and Centos security fixes (for officially maintained
> packages) are backported.
>
> Are security fixes backported for the now Apache-2.0 licensed versions of
> Sentry?

Good question. Does not look like it.

It is really just an old release, similar to say KF5.10. The code is
there and you could use it but there's zero engineering or support put
into it. I mean, why would they, their license offers the same
software freedoms (copy, modify, create derivative works,
redistribute, use) with the single restriction being that you cannot
use the software as a competing commercial offering, making the
realistic only benefactors of backport maintenance: competing
commercial offerings ;) because they can't use the current release.

HS

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

[Harald Sitter]

On Fri, May 28, 2021 at 11:43 AM Sune Vuorela  wrote:
>
> On 2021-05-26, Anna “CyberTailor”  wrote:
> >> After 36 months, the code becomes Apache-2.0 licensed (the conversion 
> >> period)
> >
> > So you can use old sentry versions, which are open source.
> >
>
> +1. I think we should support free and open source software.

I do too. I'm curious though: How does using the 4 year old software
support the software more than using the eventually 4 year old
software?

HS

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

[Harald Sitter]

On Wed, May 26, 2021 at 11:52 PM Albert Astals Cid  wrote:
>
> 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.

Yes, just using it.

> What's the use case of the software?

e.g. geoip.kde.org encounters an error, instead of abort() it catches
the error and sends a data blob of metadata of the error to sentry
from where gitlab excavates it. I see the error and might decide to do
something about it.

> How locked in are we into it?

Not at all, worst case we can simply live without this particular
software. Or use something else, but so far the stuff Bhushan and I
tried wasn't terribly convincing.

> > 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.

I appreciate your point but I would like to hope that my thoughts are
a bit more nuanced than that ;) albeit not really what I would like to
focus on here. If there's interest we can certainly discuss the pros
and cons of the many saas freedom models in general in a thread,
because, personally, I am also not sure our stance vis a vis gitlab's
model is particularly advantageous either. I do feel that is the sort
of topic that is best discussed over a beverage at akademy though.

Never the less here's a gist on this particular case: since what they
offer is saas, I struggle to see options how to monetize their project
outside "hosting" and support. The former of those options would be
undermined if a competitor were to run the same product with different
branding at half the price. So I guess perhaps your literal "you can't
make money with Free Software" is indeed the bottom line here. You
can't with the software itself through sales, at least it can be
exceptionally difficult. Sans goodwill and donations maybe, but if
employee's livelihoods depend on making money I'd not exactly stake my
business on monthly goodwill. You can make money surrounding the
software through: consulting, support, commercial licensing,
additional products built on top, selling ad space, selling out data.
Most of these avenues of income aren't available here because of the
nature of the product and the potential customers.
With all that in mind I find it entirely reasonable to have a license
that says that you can't start a competing commercial offer with the
saas product code, unless that code is at least 4 years old and thus
has been made entirely free (this eventual freedom clause is of course
something we have in our corner of the free software world as well
;)). 4 years is a bit on the long side but in the end it doesn't
prevent competition it just means that if you want to innovate a
product from the code base you'll have to start at a 4 year
disadvantage.

There now I've gone off on a ramble. Why I feel their case makes sense
isn't really important anyway here... unless someone needs swaying in
which case I can do some more musings on request :)

To clarify the terms perhaps the literal license is "don't make a
competing commercial offering with this code + this code automatically
becomes apache licensed in 4 years". A just license to my mind. But
also most definitely not a free license until the code is 4 years old.

HS

Re: GCompris and AGPL

[Harald Sitter]

On Mon, Feb 15, 2021 at 8:38 PM Timothée Giet  wrote:
>
> 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 commented, "technically KDE doesn't allow
> non-server AGPL projects, see
> https://community.kde.org/Policies/Licensing_Policy
> ".
> So he suggested that we bring the topic to the community list.
>
>
> As the KDE License Policy pages states, "this licence policy is designed
> to allow maximum code reuse with the community of KDE and beyond while
> making exceptions for the few cases which need it", we would like to ask
> to add a new exception to the list to cover our case.
>
> I propose to add something like this:
>
> "17. If a project under GPLv3(+) really needs to integrate some existing
> code under AGPLv3(+) to add a specific feature, it is tolerated to do
> so. The resulting combined work will then be under AGPLv3(+) as long as
> this code is part of the project. However, all new code created on this
> project should still be under the original GPLv3(+) license."
>
> We hope the community will agree with this.
>
> Note that we also recently tried to contact the copyright holders of
> this piece of code to ask if they would agree to relicense it under
> GPLv3+, but so far we didn't get any reply from them. If someone on this
> list has some contacts with some MIT people who could help on this
> relicensing question, it would be very welcome.

Hej

First off I'm sure we don't need to add yet more text to the policy to
grant an exception, we just need to reach agreement.  ;) If the issue
pops up multiple times we can think about adding it to the policy,
otherwise it just adds to the already weighty list of policy points
making the document yet more intimidating.

The problem at hand is perhaps a bit tricky though.

>From my understanding if anything in gcompris is AGPL that triggers
the over-the-network provision for every networked use case gcompris
might conceivably have. Remote desktop over intertubes, some VM over
intertubes thing, thin clients, thin client KIOSKs, what have you...
I'm not saying that is a bad thing, just clarifying.

Now, I would argue it's actually OK to have AGPL code if we don't read
the policy quite as literally. Notably if we accept that point 6
applies to sources rather than applications (what's an application
anyway) the intent of the source matters not of the application.
Otherwise it'd be a bit wonky since we then also couldn't link a
library that is AGPL as the combined work with AGPL is always AGPL, as
far as I know.

That brings me to the bigger problem though: it is 3.0 exclusively.
This is at odds with the policy's intent as a fixed version license is
severely constraining code reuse. We have absolutely been bitten and
continue to suffer from having sources without some or-later
provision.

At the same time, to pick up the example from above: if I understand
it correctly we use it more like a third party library that lives in
our tree instead of it actually being a "library" of sorts?
If so I would argue that we should treat it as such and allow it even
as AGPL-3.0 exclusively, perhaps with the additional constraint that
it shouldn't get any changes that aren't also upstream. 

Re: Extending the license policy to include ODbL-1.0

[Harald Sitter]

+1

On Wed, Sep 15, 2021 at 5:27 PM Volker Krause  wrote:
>
> Hi,
>
> there's a MR [1] for ki18n containing data tables generated from OSM data,
> which implies the ODbL-1.0 license [2]. We also already have other places
> ([3], [4]) actually doing this.
>
> However that's a license not yet covered by our license policy, so I suggest
> we add it.
>
> ODbL is essentially LGPL-y but for data rather than code, so conceptually
> compatible with our existing licensing.
>
> It's also not like there's any viable alternative to OSM data, so not doing
> this would imply not being able to implement features integrating OSM-derived
> data.
>
> The proposed addition to the policy section of https://community.kde.org/
> Policies/Licensing_Policy would be:
>
>
> # ''Geographic data'', in particular data based on or derived from
> OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/
> ODbL-1.0.html Open Data Commons Open Database License v1.0]'''.
>
>
> What do you think?
>
> Regards,
> Volker
>
> [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19
> [2] https://spdx.org/licenses/ODbL-1.0.html
> [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/
> timezonedb_data.cpp
> [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/
> knowledgedb/linemetadata_data.cpp

Re: Press Release: Okular, world's first eco-certified software product!

[Harald Sitter]

So amazing! Congratulations and big thanks to everyone involved :)

On Wed, Mar 16, 2022 at 10:23 AM Joseph P. De Veaugh-Geiss
 wrote:
>
> Apologies for cross-posting!
>
> [Deutsch unten]
>
> Today KDE is excited to announce that Okular, the multi-platform
> universal document viewer, is the first ever eco-certified computer program!
>
> *First Ever Eco-Certified Computer Program: KDE's Popular PDF Reader Okular*
>
>  > The multi-platform Free and Open-Source Software product is now
> officially recognized for sustainable software design
>
>https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/
>
> /Summary/: Okular, KDE's popular multi-platform PDF reader and universal
> document viewer, has officially been recognized for sustainable software
> design. In February 2022 Okular was awarded the Blue Angel ecolabel, the
> official environmental label awarded by the German government.
> Introduced in 1978, Blue Angel is the world's earliest-established
> environmental label, and Okular is the first software product ever to be
> certified with its seal. What is more, Okular is the first ️ever
> eco-certified computer program within the 30 organizations of the Global
> Ecolabelling Network!
>
> Released under the GPLv2+ license, Okular is Free and Open-Source
> Software, and so it was also already fulfilling many of the user
> autonomy criteria necessary to obtain the Blue Angel seal of approval.
> Further work was carried out to make Okular fully compliant with all of
> the Blue Angel criteria, and become officially recognized as providing
> transparency in energy and resource consumption, extending the potential
> hardware operating life of devices, and enabling user autonomy.
>
> Today we are celebrating the achievement together with the wider Free
> Software community [1], as well as with the computer science department
> at Umwelt Campus Birkenfeld [2], where researchers measured the resource
> and energy-consumption of Okular and other KDE software.
>
> KDE and the Free Software community would like to send a heartfelt thank
> you to the Okular developers for making environmentally-friendly
> software for all of us!
>
> Mastodon toot: https://mastodon.social/web/@BE4FOSS/107965444323062309
>
> Best wishes,
> Joseph P. De Veaugh-Geiss
>
> [1] https://fsfe.org/news/2022/news-20220316-01.en.html
> [2]
> https://www.umwelt-campus.de/en/forschung/projekte/green-software-engineering/news-details/first-blue-angel-for-software
>
>
> == Deutsche Version ==
>
> KDE freut sich, heute ankündigen zu können, dass Okular, der
> plattformübergreifende universelle Dokumenten-Viewer, das erste
> öko-zertifizierte Computerprogramm überhaupt ist!
>
> Pressemitteilung: 16. März 2022
>
> *Erstes öko-zertifiziertes Computerprogramm überhaupt: KDEs beliebter
> PDF-Reader Okular*
>
>  > Das plattformübergreifende Freie- und Open-Source-Software-Produkt
> ist nun offiziell für nachhaltiges Software-Design anerkannt
>
>https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/
>
> /Zusammenfassung/: Okular, KDEs beliebter plattformübergreifender
> PDF-Reader und universeller Dokumenten-Viewer, ist offiziell für
> nachhaltiges Softwaredesign ausgezeichnet worden. Im Februar 2022 wurde
> Okular mit dem Umweltzeichen Blauer Engel ausgezeichnet, dem offiziellen
> Umweltzeichen der deutschen Bundesregierung. Der Blaue Engel wurde 1978
> eingeführt und ist das älteste Umweltzeichen der Welt. Okular ist das
> erste Softwareprodukt, das mit diesem Siegel zertifiziert wurde. Darüber
> hinaus ist Okular das erste jemals öko-zertifizierte Computerprogramm
> innerhalb der 30 Organisationen des Global Ecolabelling Network!
>
> Okular wurde unter der GPLv2+-Lizenz veröffentlicht, ist also eine freie
> und quelloffene Software und erfüllte somit bereits viele der Kriterien
> der Benutzerautonomie, die für die Verleihung des Blauen Engels
> erforderlich sind. Es wurde weiter daran gearbeitet, dass Okular alle
> Kriterien des Blauen Engels erfüllt und offiziell anerkannt wird, da es
> Transparenz beim Energie- und Ressourcenverbrauch bietet, die
> potenzielle Hardware-Lebensdauer von Geräten verlängert und die
> Autonomie der Nutzer*innen ermöglicht.
>
> Heute feiern wir diese Erfolge gemeinsam mit der Free Software
> Foundation Europe [1] sowie mit der Informatikabteilung des
> Umwelt-Campus Birkenfeld [2], wo Forscher*innen den Ressourcen- und
> Energieverbrauch von Okular und anderer KDE-Software gemessen haben.
>
> KDE und die Freie-Software-Community möchten den Okular-Entwicklern ein
> herzliches Dankeschön dafür aussprechen, dass sie umweltfreundliche
> Software für uns alle entwickelt haben!
>
> Mastodon toot: https://mastodon.social/web/@BE4FOSS/107965444323062309
>
> [1] https://fsfe.org/news/2022/news-20220316-01.en.html
> [2]
> https://www.umwelt-campus.de/en/forschung/projekte/green-software-engineering/news-details/first-blue-angel-for-software
>
>
> --
> Joseph P. De Veaugh-Geiss
> BE4FOSS Project and 

A new blogs.kde.org

[Harald Sitter]

https://discuss.kde.org/t/a-new-blogs-kde-org/5011

Re: Gitlab update, 2FA now mandatory

[Harald Sitter]

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  wrote:
>
> On 25/10/22 12:11, 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_authentication.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-2fa-for-all-users-in-a-group
> >
> > We can just require 2fa for developers because with great powers come great
> > responsibilities.
> >
> > Cheers,
> > Carl
> >
>
> Can a first time contributor create a fork, create multiple/100 MR's and spin 
> up CI jobs? if yes,
> then, first time contributors can disrupt the system.
>
> Weren't there some suspicious accounts that were using our gitlab instance 
> for bitcoin mining (I
> could be wrong, I vaguely remember someone from Sysadmin team talking about 
> something like that)?
> were these first time contributors or ones with developer accounts?

I'm sure 2fa doesn't help with that (:

Re: Gitlab update, 2FA now mandatory

[Harald Sitter]

On Tue, Oct 25, 2022 at 1:52 PM Ahmad Samir  wrote:
>
> On 25/10/22 13:29, Harald Sitter wrote:
> > On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  wrote:
> >>
> >> Can a first time contributor create a fork, create multiple/100 MR's and 
> >> spin up CI jobs? if yes,
> >> then, first time contributors can disrupt the system.
> >>
> >> Weren't there some suspicious accounts that were using our gitlab instance 
> >> for bitcoin mining (I
> >> could be wrong, I vaguely remember someone from Sysadmin team talking 
> >> about something like that)?
> >> were these first time contributors or ones with developer accounts?
> >
> > I'm sure 2fa doesn't help with that (:
>
> I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? 
> it's not hard, but it
> takes some extra time.

No. It's neither hard nor does it take time. 2fa is 100% scriptable.

HS

discourse testing

[Harald Sitter]

Hello my dearies,

at last; the day has come! We are testing discourse as new forum
software. I'd like to invite you to give it a bit of testing so we can
figure out problems or annoyances we have with it. This is currently
limited to people with an invent account while we do internal testing
- don't bother creating one if you don't have one, in due time we'll
allow easier to use login options.

https://discuss.kde.org/

It'd be grand if you could maybe do some discussion, try the chat,
whatever else that comes to mind. You can start discussions on
problems you find in the site feedback category:
https://discuss.kde.org/c/site-feedback/2

I've also set you up with three discussions to have, it'd be lovely if
you could vote and throw in a comment or two:

https://discuss.kde.org/t/leave-chat-enabled/21
https://discuss.kde.org/t/import-old-forum/22
https://discuss.kde.org/t/evaluate-discourse-as-replacement-for-mailing-lists/23

Lastly, not all target features are currently enabled:
- mailing list-style use is not yet enabled
- direct registration and login via facebook,github,google accounts is missing

I'll keep you posted as things change.

HS

Re: discourse testing

[Harald Sitter]

I'm actually not sure what that is about. Maybe Carl knows?

On Sat, Dec 31, 2022 at 2:40 PM Grzegorz Szymaszek  wrote:
>
> Hi,
>
> When trying to register, I’ve got the Email, Username and Name filled
> out from (most likely) Invent. The fourth field, Invent Profile, is
> empty. Could you explain what is the purpose of that field, what one is
> expected to type there? Thanks in advance!
>
>
> All the best
>
> --
> Grzegorz

Re: Mailing list for people involved in Linux distributions

[Harald Sitter]

We already have a distro list. Nobody uses it xD
https://lists.freedesktop.org/mailman/listinfo/distributions

On Wed, Feb 1, 2023 at 12:51 PM Paul Brown  wrote:
>
> On Wednesday, 1 February 2023 11:29:41 CET Anna (cybertailor) Vyalkova wrote:
> > Distro people!
> >
> > We're starting a mailing list for coordinating on cross-distro problems,
> > "fire of the week", anything which needs - or would benefit from -
> > distributions speaking to each other.
> >
> > Example topics include:
> >
> > * "new $X is totally broken oh god"
> > * coordination of stuff like time_t migration
> > * discussing how to handle something new (the github unstable-tarballs
> >   incident would be a good example)
> >
> > Please consider subscribing: distributi...@lists.linux.dev (link on
> > lists.linux.dev / https://subspace.kernel.org/lists.linux.dev.html)
> >
> > Do join too if you're an upstream and interested in these topics,
> > especially if you're writing core software. We want a diverse set of
> > opinions and perspectives!
> >
> > Pass it on to other distribution folks / packagers too. Cheers!
>
> This is a great idea, and something that we would want to boost from Promo to
> the outside world.
>
> It would also probably make for a decent pilot discussion forum on the
> Discourse instance we are testing:
>
> https://discuss.kde.org/t/would-this-be-a-good-place-for-the-linux-distro-mailing-list/142/1
>
> I would help us gauge whether the platform is popular and usable by external
> actors, i.e., the folks in charge of distros with KDE implementations.
>
> Cheers
>
> Paul
> --
> Promotion & Communication
>
> www: http://kde.org
> Mastodon: https://floss.social/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
> LinkedIn: https://www.linkedin.com/company/kde
>
>

Re: discourse testing

[Harald Sitter]

Good morning!

Since my last email we've made various improvements as suggestions
came in. If we forgot to action something please give @sitter or @carl
a ping.

We've now also enabled site-local registration as well as login using
google, facebook, and github. Please give this a good testing if you
intend to use one of those options.

So far the reception was quite favorable, so we intend to conclude
testing soon. This is your last call to tell us what you think of the
new forum and what we maybe should be fixing still. As ever, feel free
to use the forum to tell us :)

There's also the not so trivial matter of how to migrate from one
forum to the other and I'd greatly appreciate your input:
https://discuss.kde.org/t/transition-from-old-forum/148

HS

Re: using gitlab ultimate

[Harald Sitter]

On Wed, Aug 2, 2023 at 4:23 PM Ingo Klöcker  wrote:
>
> On Mittwoch, 2. August 2023 15:55:44 CEST Harald Sitter wrote:
> > On Wed, Aug 2, 2023 at 3:48 PM Sune Vuorela  wrote:
> > > On 2023-08-02, Harald Sitter  wrote:
> > > > I don't think so
> > >
> > > As such, I have a hard time seeing that these mentioned features is
> > > important enough to give in on what I feel are our principles of a
> > > organization doing free software.
> > >
> > > I have a hard time finding any featureset where it would be important
> > > enough.
> >
> > It is my understanding that non-trivial amounts of time have been
> > spent on making a CI dashboard that now nobody uses because it is
> > defunct or some such. In essence we've wasted valuable free software
> > time. That seems a pretty compelling reason in my book.
>
> No, it's a pretty compelling reason to convince the GitLab folks to make their
> dashboard available to everyone.

I'll not stop you :)
Until that happens the argument stands.

HS

Re: using gitlab ultimate

[Harald Sitter]

On Wed, Aug 2, 2023 at 4:35 PM  wrote:
>
> On 2023-08-02 16:26, Harald Sitter wrote:
> > On Wed, Aug 2, 2023 at 4:23 PM Ingo Klöcker  wrote:
> >>
> >> On Mittwoch, 2. August 2023 15:55:44 CEST Harald Sitter wrote:
> >> > On Wed, Aug 2, 2023 at 3:48 PM Sune Vuorela  wrote:
> >> > > On 2023-08-02, Harald Sitter  wrote:
> >> > > > I don't think so
> >> > >
> >> > > As such, I have a hard time seeing that these mentioned features is
> >> > > important enough to give in on what I feel are our principles of a
> >> > > organization doing free software.
> >> > >
> >> > > I have a hard time finding any featureset where it would be important
> >> > > enough.
> >> >
> >> > It is my understanding that non-trivial amounts of time have been
> >> > spent on making a CI dashboard that now nobody uses because it is
> >> > defunct or some such. In essence we've wasted valuable free software
> >> > time. That seems a pretty compelling reason in my book.
> >>
> >> No, it's a pretty compelling reason to convince the GitLab folks to
> >> make their
> >> dashboard available to everyone.
> >
> > I'll not stop you :)
> > Until that happens the argument stands.
>
> Hi,
>
> I don't think using commercial non-free solutions as the primary tool
> for our development
> is a good idea.
>
> Beside that, that is billed per user: https://about.gitlab.com/pricing/
>
> e.g. $1188 USD per year per non-guest user
>
> That looks like a lot money to pay given we have more than 10 users,
> even if it
> has less costs if you buy xxx accounts.

It is my understanding that they are giving it away for free to free
software projects.

HS

using gitlab ultimate

[Harald Sitter]

Ahoy!

How about we start using the gitlab ultimate rather than the free version?

It'd give us access to some handy dandy features like

- CI dashboard
- multiple MR assignees
- better issue boards
- epics & roadmaps
- dependency scanning support (for our supporting projects written in
ruby, go, python etc)

and that's just off the top of my head!

What do you reckon?

HS

Re: using gitlab ultimate

[Harald Sitter]

On Wed, Aug 2, 2023 at 3:48 PM Sune Vuorela  wrote:
>
> On 2023-08-02, Harald Sitter  wrote:
> > I don't think so
>
> As such, I have a hard time seeing that these mentioned features is
> important enough to give in on what I feel are our principles of a
> organization doing free software.
>
> I have a hard time finding any featureset where it would be important
> enough.

It is my understanding that non-trivial amounts of time have been
spent on making a CI dashboard that now nobody uses because it is
defunct or some such. In essence we've wasted valuable free software
time. That seems a pretty compelling reason in my book.

HS

Re: using gitlab ultimate

[Harald Sitter]

I don't think so

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
>

planet forwarding to discuss?

[Harald Sitter]

may be of interest
https://discuss.kde.org/t/post-planet-kde-org-blogs-on-discuss-automatically/2287/1

Re: Proposal for using gitlab for kdereview process

[Harald Sitter]

https://community.kde.org/Goals/All_about_the_Apps

On Wed, Feb 7, 2024 at 11:16 PM Friedrich W. H. Kossebau
 wrote:
>
> Long time ago, but perhaps there are still memories...
>
> Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell:
> > I've gone ahead an updated the Sanity checklist
>
> Having come across the checklist items
>
> * Passing KDE neon build
> * App packages in Flatpak, Snap, AppImages and Windows etc as appropriate
>
> I tried to understand the background & motivation, but only found this "I've
> gone ahead an updated" here and the diff from your edit on 4 July 2023:
> https://community.kde.org/index.php?
> title=ReleasingSoftware=next=97120
>
> I assume this was the result of some community discussion. If so I failed to
> witness and now fail to find it. Could you help me to get more insight into
> the previous discussion here?
>
> Cheers
> Friedrich
>
>