Re: Just dumped GNOME for good! Could use some pointers...

[Martin Steigerwald]

Martin Steigerwald - 20.09.23, 09:10:01 CEST:
> Richard Troy - 20.09.23, 05:55:27 CEST:
> > I'd just installed a bunch of packages, trying to find the right
> > scanner software and, while doing that, I stumbled over this thing
> > called Kdenlive, and installed it, too, since I'm both curious and
> > have some video editing to do. ... I suspect it's the Kdenlive that
> > did it, but if anyone can comment, the list I installed was:
> > 
> > gimp   scanlite   sane   gscan2pdf   simple-scan   kdenlive
> 
> Skanpage and Skanlite are both KDE scanning applications.
> 
> Skanlite is more for scanning a single page to a PNG file, Skanpage for
> scanning multiple pages into a PDF file. But I was told newer versions
> of Skanpage support more of the features of Skanlite, so Skanpage may
> be able to replace Skanlite by now. I still have Skanpage 22.12 here,
> so I did not see those new features yet.

A little addition:

For user support type questions like this I recommend a user related KDE 
mailing list like

kde -- General KDE discussion

https://mail.kde.org/mailman/listinfo/kde

Best,
-- 
Martin

Re: Just dumped GNOME for good! Could use some pointers...

[Martin Steigerwald]

Richard Troy - 20.09.23, 05:55:27 CEST:
> I'd just installed a bunch of packages, trying to find the right scanner
> software and, while doing that, I stumbled over this thing called
> Kdenlive, and installed it, too, since I'm both curious and have some
> video editing to do. ... I suspect it's the Kdenlive that did it, but
> if anyone can comment, the list I installed was:
> 
> gimp   scanlite   sane   gscan2pdf   simple-scan   kdenlive

Skanpage and Skanlite are both KDE scanning applications.

Skanlite is more for scanning a single page to a PNG file, Skanpage for 
scanning multiple pages into a PDF file. But I was told newer versions of 
Skanpage support more of the features of Skanlite, so Skanpage may be able 
to replace Skanlite by now. I still have Skanpage 22.12 here, so I did not 
see those new features yet.

Best
-- 
Martin

Re: ACTION REQUIRED - Gitlab and Subversion server migration

[Martin Steigerwald]

Ben Cooksley - 23.07.23, 12:01:04 CEST:
> Please ensure you run the following two commands to clear out any
> existing host keys:
> - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts
> - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts

The second command misses a "-f":

ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts

Thanks for all your work, Ben!

Best,
-- 
Martin

Happy Birthday and Thank You!

[Martin Steigerwald]

Hi!

Happy Birthday KDE!

Thank you for all you did to design, develop, improve, market, test, 
give feedback and whatever to all the software developed under the KDE 
umbrella. Thank you for all you did for, for all you were in this 
wonderful, welcoming community.

In gratitude,
-- 
Martin

Re: This list is now on emergency moderation

[Martin Steigerwald]

Valorie Zimmerman - 25.03.21, 22:03:40 CET:
> Thank you for speaking up. I will do better in the future.

Thank you Valorie for your willingness to reflect on your own behavior.

I think such willingness helps a lot in the current situation in so many 
ways, no matter you how see the situation.

-- 
Martin

Thank you!

[Martin Steigerwald]

Dear KDE infrastructure sysadmins!

Not only cause it is still sysadmin appreciation day!

Thank you. Thank you. Thank you.

Caring for KDE infrastructure is quite a feat. And you all do it 
tirelessly since a long time.

Best,
-- 
Martin

Re: KDE Apps name trademarks

[Martin Steigerwald]

Dear Filipe, dear KDE community,

Filipe Saraiva - 21.07.20, 23:27:52 CEST:
> Em 20/07/2020 07:55, Albert Vaca Cintora escreveu:
> > I think we should be happy there are packagers that distribute our
> > software on Windows, the same way we are happy there are packages
> > distributing our software on Linux distros.
> 
> The problem is not people packing and distributing our software,
> including selling them.
> 
> The problem is people using the original name of our software in an
> environment where we could for ourselves pack and distribute them. If
> I am not wrong, apps stores don't allow a same software using a same
> name but distributed by different "owners".
> 
> If it is the case, we will be in a scenario where we can not use the
> original name of our software to distribute them.
> 
> It is a very different scenario of a Linux distro repository where we
> are not going to pack our software and compete to distro packagers.

Just a question that occurred to me several times as I read new mails in 
this thread:

Has anyone ever tried to talk to the packager of those applications in 
Microsoft Store?

Maybe it can be as easy as telling him "hey, thank you for packaging 
some of our applications, however, we like to do it officially, would you 
consider using a different name, or well even better help us?" or 
something like that?

*Before* setting up any kind of policy as long as there is just one 
person doing this… or are there more?

Being a slight bit ironic here: Could it be that talking to the person 
who creates those packages would actually help to resolve the issues at 
hand? Is this even a possibility?

If it happens repeatedly with other persons as well and on other stores… 
there is still an opportunity to think about an policy… I'd say.

There is a book "Anleitung zum Unglücklichsein" ("how to be unhappy") by 
Paul Watzlawick that I just remembered. In there a person has no hammer. 
But one of the neighbors of him has. But then the one without the hammer 
thinks things like "Oh, he is not going to give it to me anyway"… and 
things like that. Eventually he would go to his neighbor, ring the door, 
and as the neighbor opens tell him "I don't need your frigging hammer!".

Just something to consider.

In case you talked to the person who does those other packages on 
Windows Store already and I missed it… ignore what I wrote as much as 
you like. (Of course you are free to do this in any case.)

Best,
-- 
Martin

Re: The KDEPIM / Akonadi situation

[Martin Steigerwald]

Hi!

As it is important to be fair and open what could have been a effect of 
an unusual combination of software versions in Debian at that time:

Martin Steigerwald - 11.06.20, 11:50:53 CEST:
> Another community goal aside from fixing up the chat software
> situation within KDE could be to either fix Akonadi or replace it by
> something that works…
[…]
> Frustrating to use KMail with Akonadi 5.14.1 (20.04)
> 
> https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html

What was the most frustrating about all of this was a regression with 
Akonadi 20.04 in Debian back then:

[Akonadi] [Bug 422336] kmail: the access and reading of the received
messages is often very slow

https://bugs.kde.org/422336

I still do not know what caused it and how it got fixed. But with Qt 
5.14.2 (instead of the former Qt 5.12 in Debian) and probably other 
updates in Debian this regression is gone.

Synchronizing mail folders is much, much faster again. To the extent 
that despite all the other issues that are still unreleased KMail is 
basically usable again.

Thanks to everyone who may have been involved in the fix. Maybe… it was 
that Akonadi 20.04 did not like Qt 5.12 or maybe it was whatever… I am 
not sure what the Qt minimum version for Akonadi 20.04 is… but I would 
bet that our Debian packagers respected it.

I did not follow up on recent mails on the thread, cause I had the 
impression that my initial mail did not achieve what I intended to 
achieve with it – except for one guy offering to help development of 
KDEPIM and Akonadi! Well which is quite something… if I consider it! 
Also while I still think "akonadictl fsck" is a thing a user should 
never have to deal with… – no Outlook is not a reference for me and 
Evolution, Thunderbird and others do not have anything like that as far 
as I am aware, also Firefox does not have it for its countless SQLite 
databases, … – it is only one aspect of what I brought up and I saw no 
benefit in discussing that out to the end.

The other issues I mentioned remain, but are not as severe now that the 
dire performance regression has disappeared.


I remain with the best wishes for the KDEPIM team and hope that some day 
even those who felt hurt after reading my mail can understand that in no 
way I meant it personal. What I was going for was to find ways to support 
the KDEPIM project, but it appears that the frustration I experienced 
did not really help to achieve that goal.

So if there are any hurt feelings left… I apologize. It was never my 
intention to hurt anyone.

That all written I also stand with my assertion that the other issues I 
mentioned are all still there and the KDEPIM project IMHO can really 
benefit from some community support or setting improving it as a goal on 
the next goal round. I also still assert that no mail of mine in this 
thread has been disrespectful to the KDEPIM developers.

Maybe one day there can be a constructive discussion about how to 
support the KDEPIM project. For now I let it sit as it is.

Best,
-- 
Martin

Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)

[Martin Steigerwald]

Now actually really cc'ing KDEPIM development mailing list. In order to 
do so I waited more than a minute for KMail receiving a response with 
the payload of the mail I just sent as Akonadi maildir resource was 
using 100% of one core while synchronizing the sent folder with about 
34000 mails. Then I lost the patience, did "killall 
akonadi_maildir_resource" to make KMail respond immediately again.


I am, for this time, cc'ing again to KDEPIM development mailing list as 
I did in my initial mail, just to raise the awareness that the 
discussion continued on the community mailing list. I did not add the 
cc'd back on answers by others that did not keep the cc assuming KDEPIM 
developers would likely also be subscribed here, but in the end that is 
just an assumption.


Friedrich W. H. Kossebau - 12.06.20, 15:04:34 CEST:
> Please, let us keep this a community working together, not against
> each other, and one showing respect to each others efforts. All of
> Plasma, KDEPIM, KDevelop etc. pp. have lots of issues. We could be
> bitching about each others products all day long and where their
> developers have not instantly cared

Again, I have lots of respect for KDEPIM developers. For a long time I 
wrote long mails to defend Akonadi and KDEPIM against what in part out 
of frustrations in my eyes often were really quite rude mails.

For me this is not *at all* directed against the KDEPIM developers. I 
cc'd the KDEPIM development list in my initial mail for a reason. I did 
not cc again as I saw answers were mostly not cc'd to it as I thought 
KDEPIM developers are likely to also be subscribed to kde-community 
mailing list. It is by *no way* meant personal. And people who know past 
mails from me can actually *know* that. I wrote lengthy mails to defend 
Akonadi and did what I can, with the talents I had had hand at that 
time, to help to improve the situation.

My call now is to see what can be done to improve the situation. If that 
was not clear from my initial mail, here you have it.

I do not have an answer. But I do believe that this is neither about 
being paid or not paid development work – also AFAIK there has been paid 
KDEPIM work as well for quite some time. Nor, again, it is about the 
skills of the involved developers. KDEPIM developers are all much more 
proficient with C++, Qt and KDE stuff than me. And I *admire* them for 
their dedication.

For me part of the answer meanwhile is: It appears to be pretty damn 
hard to get Akonadi right. Simple as that. Whether that is due to its 
architecture or other reasons I don't really know, but I believe the 
architecture of Akonadi to be a part of the answer.

Cause frankly, when I truly think what a suite of PIM applications mean 
to me with a user hat on, I'd say something like "akonadictl fsck" is a 
bug already. Seriously, fsck my mail program? If I truly think this 
through I have *no* idea how to explain this to someone who just wants 
to use it. Never ever in my whole live I fsck'd a PIM application 
before.

It is by *no way* disrespectful to point that out. If that would be 
considered  disrespectful to me it appears that criticism is not allowed 
here anymore.

Never ever it was my intention to hurt anyone or make it personal. And I 
strongly object any attempt to make some "against each other" out of my 
attempt to raise an issue and see whether there could be some way of 
support for the KDEPIM developers to improve the situation.

I am even in for fundraiser like in Krita. We even had been there 
already, years ago. I still recall the discussions where users offered 
support to fund some of the development. However the answer I got from 
KDEPIM developers back then was that this would not help. Basically I 
got back that KDEPIM developers who understand enough of Akonadi 
*already* have a day job. In that case paying one of them for some time 
would need some agreement by their employer to set them free for that 
time with a guarantee that their day job is still there after that time. 
I am not putting names here, as again, I am not intending to make any of 
this personal.

For the current regression in maildir resource I am meanwhile even 
willing to step up to make a good attempt to find what is causing it, but 
I know I would need help and support for doing so. And I know fixing the 
regression would not fix all the other serious stability, reliability and 
performance issues.

I am open to any good answers, how this situation can be improved and 
ideally I would like to see KDEPIM developers speak out about it as 
well:

What would help you? What does it take to considerably improve the 
situation within a time frame that could end the frustration for users 
and through the frustration of users also for developers soon at least 
to a great degree?

I believe raising this to a broader audience may invite answers that 
within the KDEPIM project no one did think of.

PS: I may stop to respond in case I see my attempt to raise this 

Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)

[Martin Steigerwald]

I am, for this time, cc'ing again to KDEPIM development mailing list as 
I did in my initial mail, just to raise the awareness that the 
discussion continued on the community mailing list. I did not add the 
cc'd back on answers by others that did not keep the cc assuming KDEPIM 
developers would likely also be subscribed here, but in the end that is 
just an assumption.


Friedrich W. H. Kossebau - 12.06.20, 15:04:34 CEST:
> Please, let us keep this a community working together, not against
> each other, and one showing respect to each others efforts. All of
> Plasma, KDEPIM, KDevelop etc. pp. have lots of issues. We could be
> bitching about each others products all day long and where their
> developers have not instantly cared

Again, I have lots of respect for KDEPIM developers. For a long time I 
wrote long mails to defend Akonadi and KDEPIM against what in part out 
of frustrations in my eyes often were really quite rude mails.

For me this is not *at all* directed against the KDEPIM developers. I 
cc'd the KDEPIM development list in my initial mail for a reason. I did 
not cc again as I saw answers were mostly not cc'd to it as I thought 
KDEPIM developers are likely to also be subscribed to kde-community 
mailing list. It is by *no way* meant personal. And people who know past 
mails from me can actually *know* that. I wrote lengthy mails to defend 
Akonadi and did what I can, with the talents I had had hand at that 
time, to help to improve the situation.

My call now is to see what can be done to improve the situation. If that 
was not clear from my initial mail, here you have it.

I do not have an answer. But I do believe that this is neither about 
being paid or not paid development work – also AFAIK there has been paid 
KDEPIM work as well for quite some time. Nor, again, it is about the 
skills of the involved developers. KDEPIM developers are all much more 
proficient with C++, Qt and KDE stuff than me. And I *admire* them for 
their dedication.

For me part of the answer meanwhile is: It appears to be pretty damn 
hard to get Akonadi right. Simple as that. Whether that is due to its 
architecture or other reasons I don't really know, but I believe the 
architecture of Akonadi to be a part of the answer.

Cause frankly, when I truly think what a suite of PIM applications mean 
to me with a user hat on, I'd say something like "akonadictl fsck" is a 
bug already. Seriously, fsck my mail program? If I truly think this 
through I have *no* idea how to explain this to someone who just wants 
to use it. Never ever in my whole live I fsck'd a PIM application 
before.

It is by *no way* disrespectful to point that out. If that would be 
considered  disrespectful to me it appears that criticism is not allowed 
here anymore.

Never ever it was my intention to hurt anyone or make it personal. And I 
strongly object any attempt to make some "against each other" out of my 
attempt to raise an issue and see whether there could be some way of 
support for the KDEPIM developers to improve the situation.

I am even in for fundraiser like in Krita. We even had been there 
already, years ago. I still recall the discussions where users offered 
support to fund some of the development. However the answer I got from 
KDEPIM developers back then was that this would not help. Basically I 
got back that KDEPIM developers who understand enough of Akonadi 
*already* have a day job. In that case paying one of them for some time 
would need some agreement by their employer to set them free for that 
time with a guarantee that their day job is still there after that time. 
I am not putting names here, as again, I am not intending to make any of 
this personal.

For the current regression in maildir resource I am meanwhile even 
willing to step up to make a good attempt to find what is causing it, but 
I know I would need help and support for doing so. And I know fixing the 
regression would not fix all the other serious stability, reliability and 
performance issues.

I am open to any good answers, how this situation can be improved and 
ideally I would like to see KDEPIM developers speak out about it as 
well:

What would help you? What does it take to considerably improve the 
situation within a time frame that could end the frustration for users 
and through the frustration of users also for developers soon at least 
to a great degree?

I believe raising this to a broader audience may invite answers that 
within the KDEPIM project no one did think of.

PS: I may stop to respond in case I see my attempt to raise this issue 
to a wider audience in order to find ways to improve upon it is not 
moving in a beneficial direction. I did my best to make my intention 
clear, if people do not pick it up and instead try to make an "against 
KDEPIM developers" out of it… it may be better to end the discussion 
already. I cannot control how others react to what I write. So if 
despite my best efforts to word it as clearly as I 

Re: The KDEPIM / Akonadi situation

[Martin Steigerwald]

Nate Graham - 12.06.20, 05:11:31 CEST:
> software. I'm currently using Thunderbird as my email client and it is
> boringly reliable. Everything works 100%, 100% of the time. There is
> no drama whatsoever, and no maintenance required. That's the goal

Seriously +1 on that.

This exactly matches my experience with Evolution and Evolution EWS for 
accessing work mail (stored on Office 365). I switched to Evolution there 
cause with Akonadi EWS sending mails often failed.

No crash, no maintenance, no drama, no nothing. This thing *just works*.

And I'd say the scope of Evolution has similar complexity than the scope 
of KDEPIM. At least the feature sets are somewhat similar. I bet KDEPIM 
and Akonadi may be a bit more flexible and have a feature more here and 
there, but IMAP, POP3, locally stored mail, EWS, calender, address book, 
GPG support and a lot of other features are all there.

And again: This is no offense meant. I am grateful for all the work 
KDEPIM developers did. All the free time they volunteered! I expressed 
that gratitude several times and I am happy to express it again. I 
helped with bug triage, user support, I defended Akonadi, tried to help 
to bring people together. With considerable help of KDE developers I 
helped to fix a serious past performance issue with maildir resource 
(needless sorting of filenames during folder sync)…

However being grateful does not somehow disallow to raise an issue that 
exists since a long time. The issue, that Akonadi based KDEPIM fails to 
provide the reliability and speed that users expect to experience when 
they use a PIM application suite.

"akonadictl fsck", "item without RID", database administration, 
duplicated mail, stuck Akonadi resources, waiting for one or several 
minutes before being able to reply to a mail in KMail and things like 
that – no user should ever have to deal with *any of that* just so use 
PIM applications, no matter how good they otherwise are.

Being grateful does not somehow exclude raising the issue that all of 
this is still there with KDEPIM and Akonadi 20.04. And that all of this 
has been here for years.

Quite the contrary. I think it is a disservice to the KDEPIM project to 
pretend that this is not there. At least I can imagine that developers 
like to have happy users.

I see people invested a lot of time. And I am truly grateful for that.

It is just that the investment of time did somehow not lead to a result 
where the stability, reliability and speed of KDEPIM matches that of 
Evolution or Thunderbird. And by stating that I do not mean to diminish 
the progress KDEPIM developers achieved in any way.

I do think it is important to see this. And accept it. And then it can 
be possible to move beyond… Not seeing it seems to keep KDEPIM stuck 
where it currently is, *despite* all the effort.

Best,
-- 
Martin

Re: The chat situation

[Martin Steigerwald]

XYQuadrat - 11.06.20, 16:15:04 CEST:
> First off, let me say that I personally have been increasingly
> satisfied with Matrix and am of the opinion that once an alternative
> homeserver implementation (Dendrite or conduit.rs come to mind, both
> of them have top-notch performance) is ready for production, it will
> be the optimal solution for KDE. Additionally, as a young developer
> (< 20 years old), I very much appreciate how similar Matrix is to
> other chat services and would likely be less active if I had to
> participate via IRC.
> 
> What I am asking myself right now is how to lead this discussion into
> the most productive way possible. I have gathered from the current
> mails in this thread that there is a wide variety of opinions,
> preferences and approaches to this problem. There has already been a
> community-wide poll
> (https://sessellift.wordpress.com/2017/09/05/results-of-the-requireme
> nts-survey-for-a-kde-wide-chat-solution/) back in 2017 - are the
> requirements based on this survey still accurate? Additionally, how
> can we most efficiently reach a decision on what to do? I suspect
> that simply talking about the pros and cons of Matrix and IRC will
> not get us anywhere.

I am not really opposed to Matrix… I just didn't use it so far, cause I… 
meanwhile hate Google Recaptcha with a passion. As far as I read it is a 
privacy nightmare in that if it can it gather all kinds of data from the 
client browser, it provides free machine learning data for Google… and 
it just does not fit in how I think the internet should work.

I understand why it is so often used… however I have also seen 
alternatives, like for example on the register page of dismail.de – but 
there is also some open source self host-able alternative I have come 
across once. I do not recall the name currently. I am also pretty sure I 
did not need to answer a Recaptcha for registering with disroot.org

Also for chat I do prefer to use a real desktop client. No website. And 
also no website in a desktop client, although I put up with Rocket.Chat 
electron client so far even if it mainly is just that as far as I 
understand. Mobile phone app would be optional for me but I bet it is 
important for many people.

Anyway, yeah… good would be to get an idea how to continue?

Is there any short-term things that can be done about the Matrix 
situation so that the currently felt pain can be relieved a bit? This 
would give more time to focus on a longer term approach.

I still recall it, it was quite a discussion about chat systems before 
Matrix was chosen and I do believe there have been good reasons for the 
choice.

-- 
Martin

Re: The chat situation

[Martin Steigerwald]

Ilmari Lauhakangas - 11.06.20, 15:18:33 CEST:
> Christian Loosli kirjoitti 11.6.2020 klo 15.25:
> > And while IRC is improving  (and you are very welcome to participate
> > e.g. in #ircv3 or #freenode-dev on freenode) two of the main pain
> > points people mention   (lack of an endless scrollback / offline
> > history, uploading media directly) are unlikely to fully happen on
> > freenode / IRC, due to both technical and privacy / legal reasons.
> > There is very likely to be (offline) backlog, but it will be
> > time-limited due to the above constraints. Not having these
> > constraints means someone else (neither freenode nor probably KDE)
> > has both the storage and the legal willingness to store that data,
> > with all implications this brings (DSVGO, security and privacy,
> > ...)
> > These are usually profit oriented companies, and having to rely on
> > these brings up some new issues.
> 
> I'm not sure an endless scrollback is a dealbreaker. I've noticed
> folks in Telegram talking about cleanup bots that regularly delete
> the history due to whatever privacy concerns. But in general, sure,
> people want hosting & backups & everything for free and top notch
> customer support :)

/me looks at a certain 703 MiB large Quasselcore SQLite database and… 
hides… Really need to check for a script to clean it up at some point. 
But would like to it clean out public chats and keep private ones for 
example. For some reasons Quassel IRC still runs quite fast despite this 
database size.

-- 
Martin

Re: The chat situation

[Martin Steigerwald]

Carl Schwan - 11.06.20, 15:15:36 CEST:
> Maybe it is the time to consider other open-source alternatives like
> Mattermost or Rocket Chat... GNOME did it, Blender did it, we even
> have a Rocket Chat client in KDE now!

We do have Rocket.Chat at work and I can say I am quite happy with it. 
It is not perfect, but good enough, for me at least. Although especially 
threads are cumbersome UI wise. Sharing images or other files works quite 
well.

I am using the official Electron client still, but there is a KDE/Qt based 
one, called Ruqola? Never tried it out so far.

-- 
Martin

The KDEPIM / Akonadi situation

[Martin Steigerwald]

Hi!

Another community goal aside from fixing up the chat software situation 
within KDE could be to either fix Akonadi or replace it by something that 
works…

Plasma and KDE Frameworks got a huge ton better in the last releases. 
But other parts of the KDE ecosystem appear to be mostly abandoned – 
like Kopete or KDE Telepathy – or in case they receive continuous 
development like with KDEPIM/Akonadi that continuous development does 
not seem to have achieved a stable, reliable and well performing 
solution for users in the recent years. Quite the contrary, with KDEPIM 
/ Akonadi 20.04 it got worse.

Just look at kdepim-users mailing list, on bugs.kde.org or on the 
internet. Since years many users are quite unhappy with the situation. 
Quite some abandoned KDEPIM after a lot of frustration with it. And I 
considered myself to abandon it way more than once as well, currently 
considering to switch to something else again.

I was putting up with all the deficiencies, but recently it became quite 
unbearable for me as well as the situation for local maildir resources 
worsened considerably – Debian unstable / testing users are hit by this 
currently, I wonder why it wasn't reported before:

Frustrating to use KMail with Akonadi 5.14.1 (20.04)

https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html


Thing is, while this regression is new, unreliability and performance 
issues regarding Akonadi are *known* for years. And capable developers 
spent a lot of effort to fix them. Yet… it still does not work.

Some people even started over with the Kube project, but while the 
architecture of Sink that powers it appears to be more efficient and lean, 
Kube and Sink only provides a limited subset of the functionality users 
of KDEPIM use so far.


The pity in there is: KMail and other KDEPIM applications are actually 
quite good. But especially KMail suffers a lot cause it waits for Akonadi 
to complete a request more often than not. It is a "wait for Akonadi 
game".

The bug reports that describe why this is the case are open since years. 
I mentioned some of them in above post.


I really mean no accusation here for anybody. I know KDEPIM and Akonadi 
developers are working hard. They are doing their best, I am sure of 
that.

But while the situation intermittently improved some, it is still not 
really good. Also requiring users to be database administrators to make 
things work again in case of trouble… is simply a no go to me.


Currently I have no idea how to fix the situation. I lack the C++ skills 
for it and while I can learn C++, in the situations I tried to 
understand how Akonadi works and where I find what in the code… where I 
would even start looking about fixing a certain issues… I failed. I know 
some of how it works, but I never brought it all together. I may be able 
to learn all of this, but given that even seasoned KDEPIM developers 
have not been able to really stabilize Akonadi… I feel that the bar is 
quite high.

The bugs that cause the trouble are all reported on bugs.kde.org – many 
for years already. Again no offense meant. The KDEPIM developers do what 
they can.

At the same time more and more new cool features are developed for 
Akonadi and KDEPIM like KDE Itinerary or Etesync this. But the 
foundation still is not as solid as it would need to be for users to 
have a more pleasant experience with it than many users currently have.

It works for some, sure… but just look at the mailing list, the bug 
tracker and on the internet… many users struggle with it. Including 
myself… and I defended Akonadi before quite a bit before, despite all 
the trouble I had with it. I am not defending it now. It is still not 
working reliably, it still does not perform well for a considerable 
amount of users.


Anyone having any idea how to improve this situation?

Could it help to make fixing this up one of the next community goals? I 
know it is some time till the current 3-year period for goal achievement 
is completed.

What else could help?

Best,
-- 
Martin

Re: The chat situation

[Martin Steigerwald]

Hi Nate, hi.

Nate Graham - 11.06.20, 01:16:55 CEST:
> The current Matrix solution does not seem not optimal to me. I have
> really tried my best to be a good citizen and use Matrix as much as
> possible over the last year but I find myself gravitating back towards
> Telegram because of how much better the overall UX is, especially for
> fast-moving discussions and those involving images.
[…]
> This situation really needs to be fixed, somehow. I'm not
> knowledgeable enough regarding chat software to be able to propose
> solution, but I don't feel like the status quo is something we should
> live with. Can we fix Matrix? Or should we migrate to something that
> offers a better UX?

I am still using IRC. Last time I tried to register for Matrix it put up 
some Google Recaptcha and is where I lost my interest already.

But aside from that, I believe part of the thing is:

I am not using *any* chat client from KDE at the moment. Why?

There are not up to par with what would be needed:

Kopete currently is not even in Debian unstable… and last it was, it 
wasn't working all that well. And no OMEMO with XMPP either. Also it 
claims to support many more chat protocols than make sense.

KDE Telepathy appears to be abandoned completely.

Even Konversation does not seem to receive a lot of attention, or am I 
missing something? It however still appears to be quite usable.

But I am using Quassel IRC anyway…

Kaidan.im – I hope it will get there, without OMEMO no option for me.

I think this could be one of the next community goals after the 
currently running 3 years period… fix up the chat software situation in 
KDE. However for now that won't help.

So for now there may be the option to find a suitable combination of 
*some* chat client, even outside of KDE project, with chat server that 
satisfies people.

I'd keep IRC however until there would be something that could convince 
all those IRC users to switch over.

Thanks,
-- 
Martin

Re: Help with KDE PIM and Google Privacy Policies needed

[Martin Steigerwald]

Adam Szopa - 06.03.20, 16:23:43 CET:
> Dnia piątek, 6 marca 2020 16:11:48 CET Martin Steigerwald pisze:
> > Nicolás Alvarez - 06.03.20, 16:07:09 CET:
> > > > On 6 Mar 2020, at 11:26, Martin Steigerwald
> > > > 
> > > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > Martin Flöser - 06.03.20, 13:14:36 CET:
> > > >> Am 2020-03-06 08:20, schrieb Nicolás Alvarez:
> > > >>> Apple can give its million appstore apps access to Google
> > > >>> calendar
> > > >>> data, and Mozilla can let addons access email data, but we
> > > >>> can't?
> > > >>> What do they do differently?
> > > >> 
> > > >> The only thing they do differently is that they have a
> > > >> permission
> > > >> system in place. Doesn't apply for Thunderbird of course which
> > > >> means
> > > >> we should look at their privacy policy. Though we should never
> > > >> ask
> > > >> Google "Why is Thunderbird allowed?" as we don't want that
> > > >> Thunderbird gets access revoked.
> > > > 
> > > > I ask a different question:
> > > > 
> > > > Why – at all – rely on a provider who dictates on who gets
> > > > access to
> > > > it and who does not? Why – at all – rely on a provider who by
> > > > doing
> > > > so creates a walled garden?
> > > 
> > > That's something you should go ask the thousands of users
> > > complaining
> > > that they can't connect to GMail using KMail. They're the ones
> > > relying on the provider. Go to the bug report and tell them the
> > > solution to their KMail errors is to stop using Google services.
> > > That
> > > should go well 
> > 
> > See?
> 
> I think the first step of moving users from a service such as gmail
> into more decentrlized services, is to provide them a good tool that
> can support both.
> 
> It's already a challange to convince someone to move from their
> current software to a different one, combine it with the need to
> change their service provider as well and it becomed that much
> harder.

See the other mail I just said:

I am not strictly against supporting GMail, but I do not like the 
complaining attitude displayed by at least some GMail users.

If they rely on GMail as a walled garden then what happens now can 
happen anytime again. Do others appear to have less issues? Yeah, 
probably, but what can Daniel do if Google does not even bother to 
respond to him?

Petition Google if you like KDEPIM to be supported again!

-- 
Martin

Re: Help with KDE PIM and Google Privacy Policies needed

[Martin Steigerwald]

Nicolás Alvarez - 06.03.20, 16:07:09 CET:
> > On 6 Mar 2020, at 11:26, Martin Steigerwald 
> > wrote:
> > 
> > Hi,
> > 
> > Martin Flöser - 06.03.20, 13:14:36 CET:
> >> Am 2020-03-06 08:20, schrieb Nicolás Alvarez:
> >>> Apple can give its million appstore apps access to Google calendar
> >>> data, and Mozilla can let addons access email data, but we can't?
> >>> What do they do differently?
> >> 
> >> The only thing they do differently is that they have a permission
> >> system in place. Doesn't apply for Thunderbird of course which
> >> means
> >> we should look at their privacy policy. Though we should never ask
> >> Google "Why is Thunderbird allowed?" as we don't want that
> >> Thunderbird gets access revoked.
> > 
> > I ask a different question:
> > 
> > Why – at all – rely on a provider who dictates on who gets access to
> > it and who does not? Why – at all – rely on a provider who by doing
> > so creates a walled garden?
> 
> That's something you should go ask the thousands of users complaining
> that they can't connect to GMail using KMail. They're the ones
> relying on the provider. Go to the bug report and tell them the
> solution to their KMail errors is to stop using Google services. That
> should go well :)

See?

-- 
Martin

Re: Help with KDE PIM and Google Privacy Policies needed

[Martin Steigerwald]

Hi,

Martin Flöser - 06.03.20, 13:14:36 CET:
> Am 2020-03-06 08:20, schrieb Nicolás Alvarez:
> > Apple can give its million appstore apps access to Google calendar
> > data, and Mozilla can let addons access email data, but we can't?
> > What do they do differently?
> 
> The only thing they do differently is that they have a permission
> system in place. Doesn't apply for Thunderbird of course which means
> we should look at their privacy policy. Though we should never ask
> Google "Why is Thunderbird allowed?" as we don't want that
> Thunderbird gets access revoked.

I ask a different question:

Why – at all – rely on a provider who dictates on who gets access to it 
and who does not? Why – at all – rely on a provider who by doing so 
creates a walled garden?

This whole thing KDEPIM / KMail not being permitted due to its privacy 
policy – by a company which collects more data than probably anyone else 
in the world, except other large companies like Facebook, Microsoft and 
co probably – seems utterly ridiculous to me.

Sure, by all means, give a good, concise, clear privacy policy for 
KDEPIM, yet, already as it is I trust KDE + KDEPIM 10% more than 
Google, Facebook, Microsoft and Co with my data. Cause I have seen KDE 
project people value privacy *a lot*. That to the extent that I 
basically stopped writing mails with anything personal to Google mail 
accounts and accounts of some other very large providers whom I do not 
trust with privacy. You don't scan through my mail to find out what 
advertisement to sent my way for example. You do not generate profiles on 
me by urging webmasters to include your stuff into about every large 
website out there. You do not do all the nasty things.

Sure, I get it. App developers for Android do all kinds of privacy 
violations all the time. And Google probably wants to protect users from 
the worst of that. But if its data they have about users I feel they 
practice a different standard. They want to protect data they store from 
being accessed by others, but, what would be way more important, not 
from themselves. KDE for sure is a lot more caring and proactive about 
privacy and it is one reason I am using Plasma and KDEPIM.

So… I wonder… whether it would make sense for KDE to step up more for 
those decentralized alternatives that really care about privacy¹. And 
yeah, I know KDE, GNOME and a lot of other free software projects and 
communities benefit a lot from money given by Google – mostly given to 
Google for advertising. It is totally okay to be grateful for that… but 
does it mean someone who works for free and in his spare time on KDEPIM 
has to take care of satisfying Google's requirement for a privacy 
policy? If I would be Daniel and would see myself having to deal with 
that kind of stuff, I would be highly highly frustrated about it by now.

Probably quite some are not going to agree with this. But for me Google 
just again disqualifies itself and I am happy to have closed down my 
gmail account a long time ago. It is not free of cost. Not at all. Users 
of it pay with their data. I feel maybe it is time to make a stand about 
that. And not just run whenever Google feels like changing something 
regarding their service.

Seriously I feel it is important to ask different questions. 

[1] I am not listing them here to avoid any impression of doing 
advertisement.

Best,
-- 
Martin

Re: Thank you! (was: Re: Reducing the load on Sysadmin)

[Martin Steigerwald]

Martin Steigerwald - 10.11.19, 12:27:47 CET:
> Your work often is a lot less visible than the next shiny feature
> inside of Plasma or an application. It often happens in the
> background and may not be always thanked for at all, just cause no
> one notices to what extent it is your work that keeps all the
> services we take for granted running so smoothly as I do. I know how

they do

> it can feel as I did quite some of similar work myself for some time.

-- 
Martin

Thank you! (was: Re: Reducing the load on Sysadmin)

[Martin Steigerwald]

Dear Ben, dear admins for KDE infrastructure,

Ben Cooksley - 09.11.19, 00:49:49 CET:
> One of the things that was prepared as a result of the Sysadmin BoF at
> Akademy was a list of systems and services which we look after and
> provide to the community.
> 
> Whilst individually all of the services seem fairly reasonable and
> maintainable, the cumulative number of them has created a situation
> where they limit our ability to reasonably maintain our services as a
> collective whole.

I followed the discussion followed by this and your other mails about 
that topic. And I am completely missing a very important thing in there:

*Thank you*!

*Thank you big time* to you and the other admins for all the work you do 
to keep KDE infrastructure running smoothly.

Your work often is a lot less visible than the next shiny feature inside 
of Plasma or an application. It often happens in the background and may 
not be always thanked for at all, just cause no one notices to what 
extent it is your work that keeps all the services we take for granted 
running so smoothly as I do. I know how it can feel as I did quite some 
of similar work myself for some time.

On top of that you and other admins responded to some requests of mine 
often quite quickly and even when it was just about re-open and fill a 
mailing list archive for kdepim / kdepim-users on own KDE's own 
infrastructure or some spam here and there. You did that on top of all 
the other work you have.

So again, so that it really sinks in:

*Thank you*


In addition to that I ask everyone who responds to the more detailed 
mails to consider whether your answer will mostly mean even more work 
for the admins or whether it would actually help to reduce some of the 
workload. Please think a moment or two how you can make is easier for 
the admins to ease reduce their workload instead of adding even more 
work on top of it.

I considered to offer some of my time to KDE admin work some times ago, 
but so far did not do that step out of the fear that I would easily be 
swamped by work then while leading an already very busy life and 
struggling to achieve some of my most important goals. And knowing how 
challenging it can be for me to say "no"… I rather did not offer help, 
even tough I would consider myself qualified enough for this kind of 
work, beyond a little collecting of some mails into an archive so far or 
so.

I see your mail as a call for help, a call to have your workload eased a 
bit, Ben. I thought you would only be writing this in case you struggle 
with the current workload. And I can easily imagine that you do.

All I ask everyone for is some respect for that, some respect for the 
often unseen work you admins do.

So again:

*Thank you!*

I appreciate your work. Big time.

Best,
-- 
Martin

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Martin Steigerwald]

Albert Astals Cid - 10.11.19, 11:51:00 CET:
> > I wasn't referring to monetary cost there, I was referring to the
> > flow on effects (such as having to maintain the necessary
> > components on the master server to allow for the Subversion
> > repository to be mirrored).
> > 
> > Note also the "people time" component there.
> 
> That can also be solved with money 

Not necessarily or not necessarily easily. I see it in the company I 
work for and I read about it that at least in Europe IT many companies 
currently do not find the amount of skilled people they would like to.

-- 
Martin

Re: Climate Impact and KDE

[Martin Steigerwald]

Jens - 20.09.19, 11:02:44 CEST:
> So recent discussions about Climate Strike raised some very good
> points about what KDE as a community can do to decrease its
> footprint. I want to thank Friedrich for raising them.
> 
> Personally I think this is a rather fun focus for design, community
> work and development (and I should probably have thought about it
> faster so it could have been squished into the goals voting/suggesting
> - but such is life) and just want to toss some ideas around if others
> are interested
> 
> Community ideas:
> Making a clear statement that carbon footprint in travel will be a
> factor in travel support from the eV. Basically we know that there is
> zero possibility for some to choose, say trains (train from India or
> across the Atlantic is not feasible), but adding that as a part of the
> application process; "choose best transport with ecology and
> environment in mind" can go a long way and for larger events asking
> organizers to look up alternatives and present them as part of the
> "how to get to X" page (much of this is already done of course but
> formalizing it would be awesome).

Given enough fund raising for KDE events for necessary flights KDE could 
at least do some compensation via Atmosfair. I recently backwardly 
compensated for some flights I did years ago. As I support KDE with money 
I'd be totally okay with some money allocated to that. Of course 
reduction is better than compensation, so compensation should not be an 
excuse to fly more.

> Technical Ideas:
> Look at Plasma and applications energy consumption - and I know it is
> a piss in the ocean but its several pisses in the ocean - and how to
> either improve that further or create systems to minimize energy
> consumption or creating something to more clearly and accessibly show
> energy consumption and suggestions to improve it.

I'd love to see that, I just wonder how much can still be optimized 
there.

> Publish our own energy consumption and carbon footprint in regards to
> servers etc (Ben Cooksley posted a link and perhaps a clear write up
> on the subject would be cool?), and mention/formalize our own
> commitment to it.

That would definitely be cool to have. There are some web hosting 
providers who care about that.

> A closer relationship with Fairphone and Postmarket OS. So, from what
> I can gather have a pretty good relationship with Postmarket OS (via
> Plasma Mobile), perhaps explore that with regards to Fairphone
> together with them? Explore hardware vendors who try to minize their
> ecological impact and see if we can either do things with them - OR
> do things aimed at their hardware?

Wasn't there some contacts with Fairphone?

Plasma / KDE could also work together with people who refurbish old 
computers. For many use cases it is not necessary to buy a new machine 
these days as even computers from 5 years ago are fast enough to do a 
lot of tasks. I know this as I still use a ThinkPad T520. It fast enough 
for all desktop related tasks. Especially as in the last years Plasma 
was optimized heavily for good performance.

Thanks,
-- 
Martin

Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)

[Martin Steigerwald]

Christoph Cullmann - 20.09.19, 22:35:26 CEST:
> Some people in the thread said they had this strike marked since
> months thought it seems nobody thought about communicating it to our 
> community here a bit earlier that "let's do this this week".

I indeed did not think of it as for me the "computer and free software 
stuff" was not connected to the global climate strike / protests. But it 
is.

I also did not know that others here were concerned about climate as 
well. In hindsight… that is a bit naive, since many people care, but I 
did not make the connection and that is what it was.

So kudos to Jens for bringing this up here.

I am grateful for the support on Mastodon, Twitter and kde.org.

Here in Nuremberg as well as in a lot of other cities the number of 
participating people by far exceeded the expectations.

We can learn from it and next time such an announcement could be in 
other places as well.

-- 
Martin

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

[Martin Steigerwald]

Lew Wolfgang - 19.09.19, 23:20:29 CEST:
> On 9/19/19 7:45 AM, Martin Steigerwald wrote:
> > What do we choose? Climate Action. When do we choose it? Now.
> 
> Okay, this is a leap too far.  Politics should not be introduced here,
> and it is "Politics".

This was just a little reference to the protests around here and likely 
elsewhere , and I did not ask to include it in anything official related 
to the KDE project.

As written I am fine with the proposal Thomas shared.

However I am off to the protests now.

-- 
Martin

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

[Martin Steigerwald]

Hi Thomas.

Thomas Pfeiffer - 19.09.19, 15:35:27 CEST:
> Here is a concrete proposal which I've just brought up on the promo
> channel and which seems to gain support there:
> 
> - Add a banner on our website _today_ informing about the Global
> Climate Strike which starts tomorrow and telling that we support it
> (not covering the whole website, just big enough that people notice
> it)
> - Post on social media _today_, telling people that we think the
> strike is important
> - Do _not_ use the JavaScript which does the "blackout" tomorrow.
> 
> Reasoning:
[…]
> Would anybody have serious concerns about that?

I fully support this beautiful proposal!

Many thanks, Thomas.

What do we choose? Climate Action. When do we choose it? Now.

(I know it is a slight, but I feel important variation of what I heard 
and also sung on the demonstrations.)

:)

Best,
-- 
Martin

Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)

[Martin Steigerwald]

Hi!

Thomas Pfeiffer - 19.09.19, 15:04:41 CEST: 
> On 19.09.19 13:52, Friedrich W. H. Kossebau wrote:
> > Am Mittwoch, 18. September 2019, 18:01:18 CEST schrieb 
cahfof...@tuta.io:
> >> Hello to all members of the KDE community,
> >> 
> >> this friday (september the 20th) will be a big day in climate
> >> protests and hopefully also in human history: People in more than
> >> 3500 places worldwide are joining the Global Climate Strike to
> >> draw attention to the rising climate crisis.
> >> 
> >> The question I want to ask you is: Should KDE join this protests
> >> and show solidarity with the people engaging for this very
> >> important topic?> 
> > If KDE (as organization) found this topic important, it should
> > rather have it on its agenda every day, instead of just signaling
> > one day the year "oh yes, so important topic, we also agree
> > someone(tm) should fix this!!1!" , and the rest of the year
> > continue using flights also for KDE activities ("it's quicker &
> > less expensive, sorry") or buy that new device because it is more
> > powerful ("I could not stand the old one, sorry").
> > 
> > I would find it ridiculous and would be embarrassed to see someone
> > doing this in my name (as active contributor to KDE software
> > projects), when it's not backed by official applied policies. You
> > are actually harming the strike, and shadowing those people who are
> > not just signaling, but serious by what they do.
> 
> As a very active member of the climate movement in several
> organizations, my time spent there being the main reason why I didn't
> run for another board term, I disagree.
> 
> Of course KDE needs to care about our own environmental impact, which
> is why we have the ongoing discussion about an environmental policy
> (it's currently happening on the KDE e.V. members list because we
> first thought about a KDE e.V. policy), and yes, we should do even
> more.
> 
> However, that should not keep us from participating in this campaign.
> Promoting the Global Climate Strike today through our channels (it has
> to be today, since the strike is tomorrow!) could in itself have an
> effect. This is not about a grand gesture, this is about informing
> our audience about the strike.
>
> Since I am deep in the "climate bubble", Friday the 20th of September
> has been red in my calendar for months and I've been hearing about it
> every day since then.
> Outside of that bubble, however, apparently it's by far not well known
> enough.

I believe both approaches do not contradict each other.

KDE community can promote the climate strike through their channels on a 
rather short term and still work a on long term approach or commitment.

I'd love to see us do both. KDE is already a truly awesome community. 
And one can argue not to engage into "political" stuff as a free software 
community, but this is much more than "political" stuff. This is a topic 
that affects all living beings on Earth. For me it would be a remarkable 
step for a free software based community to stand up for sustainability.

20th is marked in my calendar since a long time.  I certainly will go to 
the local demonstration. And it will not be the first demonstration I 
have been to. For me it is not fair to leave all the necessary work to 
facilitate necessary, long overdue changes to our youngest generation. 
Those young people deserve our support and commitment. They deserve the 
action that is needed. And I believe there are quite some of that 
generation with KDE already anyway, for example due to the various 
student programs.

Strong action to reduce the human influence on the climate, ideally back 
to zero, and to remember a more loving relationship with mother earth 
and all the living beings on her will also decide about the future of 
KDE, both as a community and as a collection of wonderful software which 
can be used for all kinds of good causes.

So I am committed to do the best I can, even when it can be overwhelming 
at times. I know I will be there and contribute as best I can to this 
good cause. No matter how the community decision turns out to be.

Thank you all for bringing this up here.

Best,
-- 
Martin

Re: Improving Bugzilla Status Names

[Martin Steigerwald]

Christian Loosli - 05.09.18, 10:36:
> > WONTFIX -> ASDESIGNED
> > INVALID -> NOTABUG
> 
> which make it, in my opinion, less clear.
> 
> WONTFIX is not only used when something is "as per design", but also
> in cases such as product no longer supported, a third party thing
> used (e.g. an interface) doesn't allow it etc.
> So "ASDESIGNED" is less clear / sometimes just wrong. I also don't
> think that the language needs softening up, because the end result
> will be the same: the user who reported the bug or wish does not get
> what they wanted, so it should be clear and match what the user will
> get.

Isn´t there RESOLVED / UNMAINTAINED, when product is no longer 
supported?

Thanks,
-- 
Martin

Re: Input on privacy goal

[Martin Steigerwald]

Hello Eike.

Eike Hein - 22.01.18, 13:49:
> I'm planning to continue my work to modernize the user interface of
> Konversation and adding Matrix support.
[…]
> It's my opinion that a Kirigami-based Konversation with Matrix
> support is currently the most viable path toward to meeting our
> needs and bringing privacy and security back to our communication.

I appreciate Matrix support! :)

Does that mean that KDE Telepathy is on its way out? I had the impression it 
did not receive much love since quite some time.

If its basically not maintained anymore, it may make sense to deprecate it 
once the modernized Konversation is out, as using an unmaintained  chatting 
stack is a privacy risk in it self.

Thanks.
-- 
Martin

Re: Telemetry Policy

[Martin Steigerwald]

Hello Volker.

Volker Krause - 13.08.17, 11:47:
> during the KUserFeedback BoF at Akademy there was quite some interest in 
> collecting telemetry data in KDE applications. But before actually 
> implementing that we agreed to define the rules under which we would want
> to  do that. I've tried to put the input we collected during Akademy into
> proper wording below. What do you think? Did I miss anything?

I just want to applaud you people at the KUserFeedback BoF.

I think I have never seen an approach that is so cautionary about privacy as 
this one. Its really refreshing to see such utmost care. It shows the 
excellence of this community.

Actually… with an approach like this even I might agree to have some data 
collected. :)

I have only one idea left:

How about an option to store transmitted data locally as well, at least for a 
certain amount of time so the user can actually review what data has been 
send? And a log on when it was send. This way an user can actually audit the 
data if she so desires. This would improve the accountability on the promises 
you give in the Telemetry Policy Draft. Maybe the user would never look at the 
data, but knowing that it is there, just in case, can help to build his trust.

Thanks,
-- 
Martin

Re: How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)

[Martin Steigerwald]

Martin Klapetek - 10.08.17, 12:34:
> On Thu, Aug 10, 2017 at 3:24 AM, Martin Steigerwald <mar...@lichtvoll.de>
> wrote:
> > Martin Klapetek - 09.08.17, 16:12:
> > > > But KDE is not a tech startup. As people correctly wrote, KDE has a
> > > > very
> > > > long
> > > > history and contributors of all age. I'd rather be that than one of
> > > > the
> > > > many
> > > > tech startups with a bunch of little to no experience but fancy new
> > > > chat
> > > > systems, to be honest.  Do we really want and need to cater these 
> > > >mystical
> > > > tweens so much?
> > > 
> > > Yes. Old contributors will slowly fade away for various
> > > reasons, be it life, be it lack of energy, be it other commitments.
> > > Who's going to pick all those projects up after them? I'd like
> > > to think that young enthusiasts with lots of energy and potential,
> > > exactly what those heroes starting the original KDE were.
> > > And I think we should strive to attract younger talent that can
> > > be in it for the long run.
> > 
> > Well, I wonder since reading several posts here about one thing:
> > 
> > To from reading this post and other posts I got the impression that is
> > absolutely needs to be black or white:
> > 
> > *Either* IRC and nothing else *or* something new and nothing else.
> > 
> > Seriously?
> > 
> > I mean: Seriously?
> > 
> > 
> > There has been almost completely unnoticed posts mentioning bridges. Is
> > none
> > of this bridges capable to work well enough for KDE community use cases?
> > 
> > Why do you see the need to exclude either one of the groups?
> 
> As you're quoting my email - where are you reading this?
> That's not what I wrote at. all. I merely stated that we should
> cater to younger engineers. Not once I suggested and will not
> suggest to disregard the old timers. That was twisted in replies
> following my email.

Martin, I noted a general impression I got from the thread.

You are right, you didn´t write that.

This either/or approach is what in my perception was in this thread since 
quite a while… probably not (always) explicitely written out… but between the 
lines.

It might have been wiser to choose a different post – or even just don´t quote 
any post at all –  to reply to with this.

Sorry.

Martin
-- 
Martin

Re: Please participate in the requirements Etherpad

[Martin Steigerwald]

Thomas Pfeiffer - 10.08.17, 00:15:
> Just in case my other email linking to the Etherpad was overlooked by some
> of you because it was buried too deep in the thread:
> 
> Let's make this discussion productive by collecting the requirements KDE has
> for a chat / IM system to become our standard in this document:
> 
> https://notes.kde.org/p/KDE_IM_requirements
> 
> This is supposed to be the basis for our evaluation and ultimately decision,
> so if you don't contribute, you don't get to complain later ;)

I added aspects of inclusion to that (make both IRC and new chat system users 
happy instead of triggering energy wasting fights between those two groups, 
have a GUI for people with disabilities).

Thanks,
-- 
Martin

Re: Collecting requirements for a KDE-wide instant messaging solution (was: Re: radical proposal: move IRC to Rocket.Chat)

[Martin Steigerwald]

Christian Loosli - 09.08.17, 22:26:
> > Who's going to pick all those projects up after them? I'd like
> > to think that young enthusiasts with lots of energy and potential,
> > exactly what those heroes starting the original KDE were.
> 
> Who is going to be there for these new talents that lack experience? 
> 
> You need both, thus catering for one group specifically is, in my opinion, 
> stupid. 

*thank you*

I just wrote a post about making this very clear.

Please stop fighting "either / or". It won´t work. It easily visible from the 
structure of this thread already. How can some new chat system lovers and IRC 
users be happy?

Thanks,
-- 
Martin

How about an inclusive "and" approach instead of fighting IRC versus something new? (was: Re: Collecting requirements for a KDE-wide instant messaging solution)

[Martin Steigerwald]

Martin Klapetek - 09.08.17, 16:12:
> > But KDE is not a tech startup. As people correctly wrote, KDE has a very
> > long
> > history and contributors of all age. I'd rather be that than one of the
> > many
> > tech startups with a bunch of little to no experience but fancy new chat
> > systems, to be honest.  Do we really want and need to cater these mystical
> > tweens so much?
> 
> Yes. Old contributors will slowly fade away for various
> reasons, be it life, be it lack of energy, be it other commitments.
> Who's going to pick all those projects up after them? I'd like
> to think that young enthusiasts with lots of energy and potential,
> exactly what those heroes starting the original KDE were.
> And I think we should strive to attract younger talent that can
> be in it for the long run.

Well, I wonder since reading several posts here about one thing:

To from reading this post and other posts I got the impression that is 
absolutely needs to be black or white:

*Either* IRC and nothing else *or* something new and nothing else.

Seriously?

I mean: Seriously?


There has been almost completely unnoticed posts mentioning bridges. Is none 
of this bridges capable to work well enough for KDE community use cases?

Why do you see the need to exclude either one of the groups?

I know for me personally: Its either IRC or something that feels like it, is 
as lightwight as it, as standardized as it and as free software as it (i.e. 
offers free software server and client). I use Quassel IRC and I am perfectly 
fine with following IRC channels using it. Heck even most other communities I 
communicate with like for games are on IRC. Basically it is all there.

But… I wouldn´t like to exclude anyone who does not want to use IRC either… so 
can´t there be one chat system with IRC + something new?

Also I think for a community like KDE there needs to be balance between:

- How much does KDE community adapts to its potential new members.

- How much potential new members adapt to the KDE community.

There needs to be a balance between what works already – and I get the 
impression that both mailing lists and IRC do work for KDE community, just 
look at the accomplishments, just look at the achievements and you can know 
that beyond any trace of doubt – and something new that could work for new 
people. Also do we really know who these potential new people are and what 
their preferences would be without a survey?

I have been in Spain lately, and I learnt a little bit of the language. 
Seriously I wouldn´t expect anyone to speak german just cause I happen to have 
my holidays there. However if someone there can speak some english or even a 
few words of german whenever I got stuck I appreciated it as well.

I follow developements regarding new chat systems myself, I see that IRC is 
dated… yet I also see that it works. For me it is no "either / or"… and I 
kindly ask you to consider that there can be an "and" that is more inclusive 
than any of the "either / or" options. Requirement for this "and" would be 
bridging, i.e. no matter which chat system out of the supported ones one uses… 
she will always see all the messages from people who use other supported chat 
systems.

From previously just reading this thread I am almost completely certain that 
there won´t be an agreement on one of the "either / or" options. Without 
recycling this further it can be pretty much clear that here are people who 
favor IRC and people who favor something new. So rather than wasting any more 
energy fighting against one another over which option will win… I think the way 
forward would be to find a way to make both groups happy.

Thank you for considering my plea to bring some sanity to this discussion 
again.

Thanks,
-- 
Martin

Re: Bugzilla Update Staged: Testing Requested

[Martin Steigerwald]

Am Sonntag, 23. Oktober 2016, 16:34:39 CEST schrieb Ben Cooksley:
> Hi all,

Hello Ben!

Thank for your taking care to update Bugzilla.

> I've prepared an update for bugs.kde.org, from the current version
> it's running to the latest version of Bugzilla. Due to the nature of
> changes made by upstream to the HTML it's been necessary to drop the
> Neverland theme for Bugzilla.
> 
> As dropping this theme may have resulted in unintentional breakage of
> templates, and the upgrade is quite significant (from the 4.x to 5.x
> series) it would be appreciated if folks could please quickly test the
> instance, located at https://bugstest.kde.org/
> 
> If you find any issues it would be appreciated if you could let us know.

I had a quick glance at bugs I reported and all seems fine. Actually I prefer 
the fixed fonts the default themes uses as it makes pasted console output so 
much more readable.

However I do not think any of the bugs I reported use a non text based 
template… but I am not sure… what I saw so far, just looks okay.


I do hope that the new version can help to implement measures to make bugzilla 
spam less likely, but if as you and Nicolás say this is really done by people 
who are paid to do it – I still have a hard time believing this… – … they 
basically would be able to circumvent any improvements with captcha´s and 
whatnot :(

What could work is a trainable spam filter within bugzilla. Or at least 
something that greps out phonenumbers together with certain key words (as all 
the spam I saw was just this).

I did some research on bugzilla and spam and… mostly the results are about 
preventing spam sent to users of bugzilla by not exposing their mail 
addresses… but not about spam in bug reports. I had no single hit on a spam 
filter *for* Bugzilla, which surprises me. Also the documentation for Bugzilla 
5.11 does not seem to mention anything about spam filtering.

I saw similar spam bugs with bugzilla.kernel.org and also Eclipse seems to 
have issues with it:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=502814

An idea here would be allowing others to clean this bugs too. Or modified: A 
button to mark that a bug report contains spam as an easier way to report it. 
Debian uses this approach for their own bug tracker, but as its email based in 
addition to a sophisticated spam filtering mail setup which seems to do pretty 
well.

Thank you,
-- 
Martin

Re: [kde-community] Results from the Mission Survey

[Martin Steigerwald]

Am Freitag, 29. Juli 2016, 01:04:58 CEST schrieb Thomas Pfeiffer:
> Hi everyone,

Hi Thomas.

> I'm sorry for taking so long with the survey analysis (analysis and
> documentation of survey results always end up taking longer than expected),
> but now finally I've prepared a presentation of the results of the first
> round of analysis of the survey I did for input on KDE's Mission statement.
> This is just plain results, no interpretation.
> I said "first round" because I'm ready to do perform further analyses if
> these results leave important questions open (if they can be answered from
> the data, of course).
> If you'd like me to dig deeper somewhere, feel free to tell me!
> 
> If anybody would like to get the raw data to do their own analyses, that's
> of course possible as well.
> 
> With this, I leave you to the graphs and numbers, hoping that the results
> will help us make confident decisions about our Mission statement (I think
> they do).

Thank you for doing this.

I am baffled by the extreme coherence between answers of contributors and of 
users. Seems like a perfect match.

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Reputation of Digital Ocean (was: Re: DigitalOcean is now a sponsor!)

[Martin Steigerwald]

Hello.

I may offend someone by writing this, but I think this is important to know 
for the project. Also please now that I am heavily fed up by receiving these 
spams from Digital Ocean networks, but I still tried to be considerate in this 
mail. If I failed, please forgive me. In the end I am just the messenger, so 
please don´t shoot me.

Am Mittwoch, 6. Juli 2016, 10:47:58 CEST schrieb Helio Chissini de Castro:
> I'm happy because the good reputation of Digital Ocean.

I have mixed feelings about this.

On one side I am happy you got a new sponsor, but on the other side up to now 
I only knew Digital Ocean networks as source for repeated spam mails from new 
TLDs like .xyz, .site, .faith and so on. I sent about five abuse reports to 
them already, but only got automated replies. And yes, there was some pause in 
spams, but now I received one again, again from a network from Digital Ocean.¹

So they seem to have trouble making sure that their customers are serious in 
that they do not use VMs for spamming or capable of securing their server VMs 
to make sure no one else abuses them for this.

I am now close to the point of completely blocking *complete* networks / AS's 
from Digital Ocean. But then I might block serious users, such as the admins 
of the KDE project. Still, as these spams currently escape my Spamassassin and 
policyd-weight network, I may still do it, no matter whether there are serious 
users as I am not willing at all to tolerate these spam mails and I am not 
willing to continue to add domain after domain and IP address after IP address 
whenever a new VM from Digital Ocean throws spam at my server. I would block 
with a REJECT like suggested by Ronny on postfixbuch-users mailing list², 
which specially mentions to contact ab...@digitalocean.com about this, as 
otherwise there will be ne pressure for Digital Ocean to improve the 
situation.

So that much about good reputation from my side. I really hope Digital Ocean 
people get their act together and reliably prevent that VMs from their network 
send spam.

Until they do, I suggest not to put any of the KDE project´s  mail 
infrastructure onto their servers to avoid the risk of being blocked by users 
like me. If you still do, please tell me the IPs, so I can make sure I do not 
block them.



[1] this is my current configuration in Postfix and no, this is *no* joke, as 
far as I looked, these all oriented from Digital Ocean networks – I didn´t 
even bother to include all the IPs:

/klicken.*\.xyz/ DISCARD S2016-06: Spam discarded.
/klicken.*\.accountant/ DISCARD S2016-06: Spam discarded.

/mailing.*\.xyz/ DISCARD S2016-06: Spam discarded.
/mailing.*\.site/ DISCARD S2016-06: Spam discarded.

/server.*\.xyz/ DISCARD S2016-06: Spam discarded.

/weiter.*\.top/ DISCARD S2016-06: Spam discarded.

/aufmachen.*\.party/ DISCARD S2016-06: Spam discarded.

/95\.85\.8\.87/ DISCARD S2016-06: Spam discarded.

/178\.62\.235\.237/ DISCARD S2016-06: Spam discarded.

/46\.101\.111\.79/ DISCARD S2016-06: Spam discarded.

/versand.*\.faith/ DISCARD S2016-07: Spam discarded.


[2]  AW: Spam-Mails mit neuen TLDs und von Digital Ocean Cloud-Systemen 
blocken
https://listi.jpberlin.de/pipermail/postfixbuch-users/2016-July/064314.html

As you can see there I am not the only one affected.

Thank you,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:53:22 CEST schrieb Vishesh Handa:
> > So, if _you_ accept pull requests to a repo in the KDE official mirror,
> > you
> > are making decisions for others, and are making other people do things.
> 
> No I'm not.
> 
> Boud, you're shipping Krita on Windows. You're uploading them on the
> KDE official website, you're thereby making me pay for Windows if I
> want to test it and contribute to the project, you are making
> decisions for others.
> 
> Does this argument really hold?

I was not aware that I am forced to use the windows version of Krita. I just 
apt installed it and its just working fine.

Also it doesn´t lock in any development resources to a specific proprietary 
platform. At least I don´t see how it can do so.

So you can argue for github.com: But its opt-in and only for some repos? How 
do you make sure it doesn´t create pressure and expectancy that this will be 
switched on for all the other repos if pull requests are enabled in parts of 
the *official* KDE github.com mirror?

I do not see the Windows version of Krita creating any pressure for people to 
switch to Windows. I certainly do not feel any pressure to do so.

Thus I think its important to compare apples to apples and pears to pears.

Pull requests and probably bug reports on github.com affect the development 
process. Providing a Windows version of Krita does not, despite adding some 
portability to the codebase.

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 02:22:44 CEST schrieb Riccardo Iaconelli:
> On Friday, September 18, 2015 11:43:34 PM Vishesh Handa wrote:
> > It depends on our end goal: creating free software or creating free
> > software with only free tools? If it is the latter then I fear we have
> > already failed since many of us use additional tools to aid
> > development which are not free.
> 
> I couldn't say it better!
> 
> Bitkeeper was not free, when support ended, git was made! Some video drivers
> were not free, but we continued to use them, until better alternatives
> emerged. Sourceforge was not free, yet many KDE projects used it.
> 
> ...heck, even Qt was not free, back in the days!
> 
> I wouldn't rely entirely on a non-free platform, but I wouldn't miss the
> opportunity to market projects who wish so to a larger developer base. It is
> important for our coummunity to share and communicate our open values, and
> that usually means with people who are not yet convinced. :-)

Right now the larger developer base is just an hypothesis, or are there any 
numbers on that? (I am aware that numbers on that would require that one KDE 
project already uses pull requests github.com.)

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:20:32 CEST schrieb Vishesh Handa:
> * Reporting Bugs in 2 places - The default place should still
> bugs.kde.org for now.

For bug triaging KDEPIM I will ignore anything but the official KDE 
infrastructure.

I know bugzilla is not the most friendly to use bug tracker around, but I 
start getting on terms with it and I certainly to not want to look in more 
than one place for bug reports.

Having a second infrastructure beneath the official one will split energy.

So for the work I currently do I vote for having only *one* officially 
endorsed infrastructure. And for anything that is an exception I suggest to 
treat it as such: Create your personal clone on github.com. So if its, as you 
also wrote is not officially endorsed, I think it any exception shall stay 
outside of the officially endorsed infrastructure and as such the officially 
github.com presence of the KDE project would just be a mirror. Otherwise if 
you allow it for some KDE projects within the official KDE github.com 
presence, how is this different from an official endorsement?

(And I write this even tough at my employer we do use github.com.)

Thank yo,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 11:53:22 CEST schrieb Vishesh Handa:
> > If _you_ want to use an official KDE thing to promote the use of non-free
> > software, you're not just "selling your own soul", you're compromising
> > KDE's message.
> 
> I'm not promoting its usage. I'm advocating for utilizing its
> resources in addition to our own. Just as we utilize other proprietary
> platforms (windows, and mac) to improve KDE. No one is advocating
> GitHub.

How is "I'm advocating for utilizing its resources in addition to our own" not 
advocating GitHub?

My logical thought process does not get that.

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

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 13:09:31 CEST schrieb Vishesh Handa:
> On Sat, Sep 19, 2015 at 1:04 PM, Martin Steigerwald <mar...@lichtvoll.de> 
wrote:
[…]
> > So you can argue for github.com: But its opt-in and only for some repos?
> > How do you make sure it doesn´t create pressure and expectancy that this
> > will be switched on for all the other repos if pull requests are enabled
> > in parts of the *official* KDE github.com mirror?
> > 
> > I do not see the Windows version of Krita creating any pressure for people
> > to switch to Windows. I certainly do not feel any pressure to do so.
> 
> How do you then feel pressured to use Github if most development happens on
> kde?

For bug triaging I answer: People report issues for the project I am helping 
to bug triage in. And while I certainly can ignore those, it creates bad 
reputation for the project, if no one else tends to the bug reports.

I think similar it goes for pull requests.

> > Thus I think its important to compare apples to apples and pears to pears.
> > 
> > Pull requests and probably bug reports on github.com affect the
> > development
> > process. Providing a Windows version of Krita does not, despite adding
> > some
> > portability to the codebase.
> 
> Testing and QA are important parts of creating a product. They most
> certainly are part of the "development process". Providing a Windows
> version of Krita does force me to install these tools if I wish to
> contribute to that part of Krita.

Vishesh, please: If you *wish* to contribute to that part of Krita, how can 
you be *forced* to use Windows?

If you are not interesting in the Windows version, you just ignore it.

I see only one kind of pressure that comes from a Windows version of Krita and 
that is some pressure to provide for portability. From a development point of 
view I see this as an advantage. It can even prevent platform lock-in.

Well okay, I know get your argument: If a user reports a bug on Windows, one 
can feel pressured to do something about it. Similar like with an issue 
provided on github.com. That said, I likely won´t feel pressured. Cause if 
there is a Windows team for Krita, I expect this team to handle Windows 
specific bug reports and likely would ignore them otherwise.

But still… there is *some* comparability. Yet, I still providing a Windows 
version of Krita is not the same as (partly) allowing pull requests on 
Github.com. I do  not have words for it at the moment, but I feel lot more 
reluctance about the latter than the former.

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

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 21:15:41 CEST schrieb Boudhayan Gupta:
> On 19 September 2015 at 20:52, Vishesh Handa  wrote:
[…]
> > I think we're talking about different things. The read-only mirror is
> > done, and shipped. I was talking about projects being able to also use
> > github, and the rest of the community respecting that decision.
> 
> Precisely. Martin's original suggestion, which we have shipped, was to
> provide a read only mirror on GitHub for the drive-by folks who only
> check GitHub for open source code. It is important to note that the
> developers have no control over this organization on GitHub (only the
> sysadmins do - even I was removed after I finished all my scripting),
> nor should they (just like they don't have write access to the anongit
> servers). I re-iterate - GitHub, at the moment, is nothing more than a
> (smart) anongit server. And we (the sysadmins) are not inclined to
> treat it any better than that because it's not under our control and
> we will not be able to guarantee that it'll work two weeks from now.
> 
> If you want to "use github", whatever that means, by all means
> maintain a repo under your personal account, and continue to use it as
> you were using it. No one's stopping you.

If its mainly about providing search for sourcecode, how about

https://codesearch.debian.net/

https://codesearch.debian.net/about


Ironically Michael Stapelberg hosts the source code with github.com:

https://github.com/Debian/dcs

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 16:44:54 CEST schrieb Martin Graesslin:
> On Saturday, September 19, 2015 3:28:56 PM CEST Luigi Toscano wrote:
> > Kevin Krammer ha scritto:
> > > On Saturday, 2015-09-19, 14:43:37, Bhushan Shah wrote:
> > >> On Sat, Sep 19, 2015 at 2:06 PM, Sune Vuorela  
wrote:
> > >>> I personally feel a bit fucked over right now. All this started with a
> > >>> KDE github mirror and *just a mirror*. No pull requests. No
> > >>> bugtracker.
> > >>> No nothing else. Just a mirror. And it was repeatedly said in the
> > >>> thread
> > >>> that it would be just a mirror. Just a mirror.
> > >> 
> > >> And when we say mirror and if we start to accept pull request there it
> > >> will also complicate the sysadmin work if I know correctly
> > >> 
> > >> How would git.kde.org will stay up-to-date if you merged pull request
> > >> on github? This is one of the reason currently sysadmin allows pushes
> > >> on just git.kde.org and not on anongit.kde.org
> > > 
> > > I have to say I don't have any experience with pull requests, whatever
> > > those are, but since Jaroslaw put the into the context of patches by
> > > email I would assume that the workflow still has all patches go through
> > > proper review, these pull request would just be a form of patch
> > > submission.
> > > 
> > > Lets consider an example, say Okular.
> > > 
> > > If Okular has the policy that nothing is merged without review, then all
> > > patches for Okular need to go through KDE's review tool
> > > (reviewboard/gerrit/phabricator/whatever).
> > > 
> > > If contributors to Okular feel they want to accept submission per email,
> > > bugzilla attachment or github pull request, then they will still have to
> > > submit these patches for review, no?
> > 
> > About this specific example, the normal answer to Okular patches on
> > bugzilla is "please send it through reviewboard".
> > 
> > Isn't it possible to automated this step on github? A bot/jenkins job that
> > checks for pull requests and writes this message whenever a pull request
> > is
> > opened on github, if it's not possible to disable them?
> 
> yes it is and David already pointed to it quite in the beginning of the
> discussion: http://nopullrequests.com/

Just to clarify:

I think if this way is chosen, the bot should be hosted by and be in control 
of KDE infrastructure. Which appears to be possible, as the source is provided 
under the Apache license:

https://github.com/imjasonh/nopullrequests

Otherwise it would be using one cloud service to fix a (intended?) flaw in 
other one.

Don´t know whether it works without a Google account tough as the "Let´s get 
started" link redirects to Google account login page.

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Martin Steigerwald]

Am Samstag, 19. September 2015, 17:22:03 CEST schrieb Vishesh Handa:
> > It is important to note that we're talking about infrastructural
> > consistency here, not code consistency. There is a distinction. 
> 
> My point over here was to illustrate that there are many parts to
> building a project, the code, development, handling contributions,
> handling bugs, infrastructure, etc. None of these *have* to be
> consistent. The manifesto does not actually dictate terms of
> "infrastructure".
> 
> Relevant part - "Online services associated with the project are
> either hosted on KDE infrastructure or have an action plan that
> ensures continuity which is approved by the KDE system administration
> team"

There is no guaranteed continuity with anything that is *written* to the 
github.com presence. Unless the KDE system admin team provides one by backup 
up the github.com presence and be prepared to host it in case of service 
outage or termination.

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

Re: [kde-community] Have repo maintainers opt-in for github mirroring (was: Re: Official KDE mirror on github)

[Martin Steigerwald]

Hello Friedrich,

Am Freitag, 18. September 2015, 23:22:41 CEST schrieb Friedrich W. H. 
Kossebau:
> For the first, my answer is not: mirror on github, but rather: make this
> info  better accessable (heck, perhaps simply put in the About dialog, in a
> new tab "Developers").

I think its even possible to just mentioning that in any github.com/kde page.

"You are looking for our code on github.com?

We don´t use github.com due to …, but you can find out code on … and we also 
have a nice way to provide reviews in … and our task and project management is 
at …

We look forward to your contributions."

So I see no need to provide an actual mirror of the source code in order to 
point to KDE infrastructure.


I was a bit confused as first there was talk about disabling pull requests. 
Yet now the github.com/kde mirror is up, but I also read its not possible to 
disable pull requests. I´d expected that someone would check this before the 
move.


Anyway, for bug triaging I will just look at bugzilla for now. And since I 
didn´t write more than a few lines of code so far, except for this idea I 
leave this discussion to those who contributed more code.

Thanks,
-- 
Martin
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community