Advance Downtime Notification

[Ben Cooksley]

Hi all,

Over the past 24 hours we have received initial warning notifications
that a disk in our bulk storage server has begun to show signs of
failure. We have now begun the process of having this disk replaced,
following which we will need to rebuild the RAID array.

As a consequence of this at some point in the next week the following
services will be unavailable for a period of up to an hour.
Additionally, the performance of these services from now until the
disk is replaced and the rebuild is completed may be impacted.

The affected services include:
- All Jenkins instances (build.kde.org and binary-factory.kde.org)
- files.kde.org and download.kde.org redirectors and master tree.
- maps.kde.org (Marble Maps)
- cdn.kde.org (website assets for all Neverland themed websites)
- distribute.kde.org (Flatpak repository)
- archive.neon.kde.org (Neon APT repositories)
- Akademy support sites
- KDE e.V Reimbursements portal

During this time sites which are fronted by either Incapsula or CDN77
(maps and cdn) may continue to be available to a certain extent
subject to their caching.

It is strongly advised that any maintainers intending to make a
release within this timeframe take into account potential system
unavailability, and where possible reschedule the release outside of
the window.

Should anyone have any concerns please contact us.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Advance Downtime Notification

[Ben Cooksley]

On Wed, Nov 29, 2017 at 8:11 PM, Ben Cooksley  wrote:
> Hi all,

Hi everyone,

>
> Over the past 24 hours we have received initial warning notifications
> that a disk in our bulk storage server has begun to show signs of
> failure. We have now begun the process of having this disk replaced,
> following which we will need to rebuild the RAID array.
>
> As a consequence of this at some point in the next week the following
> services will be unavailable for a period of up to an hour.
> Additionally, the performance of these services from now until the
> disk is replaced and the rebuild is completed may be impacted.
>
> The affected services include:
> - All Jenkins instances (build.kde.org and binary-factory.kde.org)
> - files.kde.org and download.kde.org redirectors and master tree.
> - maps.kde.org (Marble Maps)
> - cdn.kde.org (website assets for all Neverland themed websites)
> - distribute.kde.org (Flatpak repository)
> - archive.neon.kde.org (Neon APT repositories)
> - Akademy support sites
> - KDE e.V Reimbursements portal

As an update to the above, the disk has now been exchanged and an
array rebuild is currently in progress.
While the rebuild is underway system performance may be impaired.

If there are any issues please let us know.

>
> During this time sites which are fronted by either Incapsula or CDN77
> (maps and cdn) may continue to be available to a certain extent
> subject to their caching.
>
> It is strongly advised that any maintainers intending to make a
> release within this timeframe take into account potential system
> unavailability, and where possible reschedule the release outside of
> the window.
>
> Should anyone have any concerns please contact us.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Cheers,
Ben

Re: SoK 2018 Project - 'New Season of KDE Website'

[Ben Cooksley]

On Sun, Dec 24, 2017 at 2:57 AM, Mayank Gupta  wrote:
> Hello everyone,

Hi Mayank,

> I'm Mayank Gupta, I successfully completed a project under CCExtractor
> organisation in Google Summer of Code 2017, I am interested in developing
> "New Season of KDE webste" under Season of KDE 2018. From @baloneyGeek I got
> to know KDE Identity uses standard LDAP userdb and also that I'd need to
> setup dummy server for the same to test KDE identity integration for
> developed website.
>
> So about the implementation of idea 'New SoK website', when integrating KDE
> Identity (which uses LDAP db), do the 'Org Admins' belong to different
> `OrganisationalUnit` on the server? or do they have some different set of
> attribute(s) which could enable business logic to identify their 'KDE
> Identity' as 'admin' and different from that of mentors and students?

All users, whether students, developers, sysadmins or other members of
the community are stored in the same organisational unit.
Our directory has a 'groupMember' attribute which can be used to
determine the groups a user is part of, so i'd suggest referring to
that.

When creating this I would advise structuring it in such a way that
LDAP could be replaced by another protocol, such as a HTTP API
(authenticated using OAuth) in the future.

>
> Also, if possible, could anyone provide with a crude schema of db so that it
> gets easy to write LDAP queries  in website and also setting up the dummy
> database, which would indeed ease the process of unplugging the dummy LDAP
> db and plugging in the real one.

You can find the schemas we have loaded in our directory at
https://cgit.kde.org/websites/identity-kde-org.git/tree/protected/data/
This is in addition to the standard LDAP objectClasses of course.

Please let me know if you have any questions about the specific data
which might be stored for a user.

>
> Thanks,
> Mayank Gupta

Cheers,
Ben Cooksley
KDE Sysadmin

Mirror of Qt being discontinued

[Ben Cooksley]

Hi all,

As part of a recent review of our systems it has been determined that
the Qt mirror we were hosting was not being used significantly. This
is likely due to the switch by developers to distribution Qt packages,
with fewer developers building Qt now.

To reduce the maintenance burden for us, along with the periodic sync
load on the servers which accompanied our regular syncs we've now
discontinued and have removed the mirror.

Those who were still using the mirror should be able to switch to the
public mirror operated by Qt at code.qt.io.

Should anyone have any questions please let us know.

Cheers,
Ben Cooksley
KDE Sysadmin

Re: UI tests on build.kde.org

[Ben Cooksley]

On Fri, Jan 5, 2018 at 11:15 PM, Christian David  wrote:
> Hi,

Hi Christian,

>
> is it possible to have UI tests on build.kde.org? If not what is the best
> practice to prevent them from being executed?

Yes, the system provides a full graphical environment by default.
We use Xvfb to provide an X server, along with Openbox as the window manager.

(For those curious,
https://phabricator.kde.org/source/sysadmin-ci-tooling/browse/master/helpers/run-tests.py
is the script used to prepare the environment and run the tests)

>
> The reason I asking is the error
> https://build.kde.org/job/Extragear%20kmymoney%20kf5-qt5%20SUSEQt5.9/239/
> testReport/junit/(root)/TestSuite/reports_chart_test/
> more details in
> https://build.kde.org/job/Extragear%20kmymoney%20kf5-qt5%20SUSEQt5.9/239/
> console

Looks like the test has some focus related issues, does it rely on any
plugins which could be popping up a message box or anything along
those lines?

>
> The tests was reported to work on other computers by two developers.
>
> Best
> Christian
>

Regards,
Ben Cooksley
KDE Sysadmin

>
>

Re: Looking for mentor for new KDE developer

[Ben Cooksley]

Hi all,

Just following up on this - is there anyone who is looking into
helping Christian here?

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Looking for mentor for new KDE developer

[Ben Cooksley]

On Mon, Jan 8, 2018 at 12:07 PM, Albert Astals Cid  wrote:
> El dilluns, 8 de gener de 2018, a les 8:15:54 CET, Ben Cooksley va escriure:
>> Hi all,
>>
>> Just following up on this - is there anyone who is looking into
>> helping Christian here?

Hi Albert,

>
> I don't understand why we're forcing this "he needs a mentor". As Dominik
> says, he seems to know stuff since he actually ported the code.
>
> If he needs help with "kde bureaucracy stuff" it means that we actually need
> to improve our onboarding documentation, so instead of giving him someone he
> can ask things in private, we should try to improve that documentation, or at
> least answer the questions in this list so they are public and can be
> referenced in the future.

It's mostly a case of bureaucracy stuff yes.
Translations, Documentation, Release processes, etc.

It's basically the same sort of stuff as projects that go through incubation.

Yes, our documentation probably does need improving, and no
documentation is perfect (there will always be edgecases).

>
> I will be happy to answer any question he may have related to that (and
> hopèfully I know the question)

Awesome. I'll process his account shortly.

>
> Regarding the "In addition, translations would need to be imported into our
> infrastructure, or recovered from our SVN history. That needs intervention by
> our i18n experts, possibly before the code is imported." that Nicolás
> mentioned, yes, that needs the i18n team helping, but that's what the kde-
> i18n-doc mailing list is for, unless the mentor was part of the i18n team that
> wouldn't get solved anyway.
>
> Cheers,
>   Albert

Thanks,
Ben

>
>>
>> Thanks,
>> Ben Cooksley
>> KDE Sysadmin
>
>

Re: Kamoso in KDE Applications

[Ben Cooksley]

On Tue, Jan 16, 2018 at 10:49 AM, Albert Astals Cid  wrote:
> El dilluns, 15 de gener de 2018, a les 4:05:05 CET, Aleix Pol va escriure:
>> On Sun, Jan 14, 2018 at 11:31 PM, Albert Astals Cid  wrote:
>> > El divendres, 12 de gener de 2018, a les 3:51:03 CET, Aleix Pol va
> escriure:
>> >> On Thu, Jan 11, 2018 at 7:44 PM, Albert Astals Cid  wrote:
>> >> > El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va
> escriure:
>> >> >> Hey,
>> >> >> I'd like to move it there. It's in extragear/multimedia now and I keep
>> >> >> forgetting to release as often as I should.
>> >> >>
>> >> >> But the application is working, maintained and developed.
>> >> >>
>> >> >> Thoughts?
>> >> >
>> >> > I'm not vey happy about the copied code of QtGStreamer.
>> >> >
>> >> > Why did you decide to copy it?
>> >>
>> >> It's unmaintained, I had sent several fixes that went in but never got
>> >> released. So if you used it with master Kamoso worked but stable
>> >> didn't.
>> >
>> > Ok so you decided to fork it instead of becoming the upstream maintainer,
>> > fair enough i guess.
>> >
>> > But maybe you should rename
>> >
>> >./src/elements/gstqtvideosink/CMakeLists.txt:66:install(TARGETS gst$
>> >
>> > {QTVIDEOSINK_NAME} DESTINATION ${CMAKE_INSTALL_LIBDIR}/gstreamer-$
>> > {GSTREAMER_ABI_VERSION})
>> > so that it does not conflict with what other distros may be shipping from
>> > the "real" QtGStreamer ?
>>
>> I did, the code looks a bit weird but I didn't want to change it too
>> much from upstream.
>> We have this:
>> set(QTVIDEOSINK_NAME kamoso-qt5videosink)
>
> Ah, i see.
>
> Ok, personally i don't have any objection to adding yet another app to KDE
> Applications, anyone else has something to comment?

I can't see any issues with this, shall we proceed with the move in
say 24 hours?

>
> Cheers,
>   Albert

Cheers,
Ben

>
>>
>> > Also can you please get a build on https://build.kde.org/ going ?
>>
>> Yes, just requested it.
>>
>> Thanks!
>> Aleix
>
>

Re: [kdesrc-build] qca build failed

[Ben Cooksley]

On Sun, Jan 21, 2018 at 3:33 PM, Christoph Feck  wrote:
> On 20.01.2018 17:33, Mathieu Tarral wrote:
>>
>> I'm trying to build KDE from source using kdesrc-build script.
>> However, each time i have tried these last days, it failed on the QCA
>> module.
>
>
> This might have to do with incompatible changes in openssl. Try to switch
> between 1.0.2 and 1.1.0 version.
>
> But I think you can skip QCA for now, because it is only needed for a few
> KDE applications such as Okular, Konversation, and KTorrent (and even there
> might be optional).
>
> Neither KDE Frameworks, nor the Plasma workspaces require QCA.
>

Unfortunately i'm afraid Purpose, a recent addition to Frameworks,
does require QCA.
It only has a couple of users though so you can probably skip building
it if QCA is causing you issues.

Cheers,
Ben

Re: git repo issues

[Ben Cooksley]

On Sun, Jan 28, 2018 at 4:54 AM, Nate Graham  wrote:
> Hello Ben (et al),

Hi Nate,

> I've noticed that in the last hour, git commits don't seem to show up in the
> web interface. Examples:
>
> https://phabricator.kde.org/D10143 -> commit shows up in git history, but
> does not appear on https://cgit.kde.org/baloo-widgets.git
>
> https://phabricator.kde.org/D10131 -> commit shows up in git history, but
> does not appear on https://cgit.kde.org/discover.git
>
> Mind taking a look?

Some changes I made to the post-update hook (which trigger the anongit
propagation process) unfortunately had a typo, leading to the hook
failing.
I've now corrected that and are triggering the hook for all
repositories - this should get the system back in sync again.

Jenkins will be doing builds as it normally would as this triggering
takes place.

>
> Thanks!
>
>
> Nate Graham
>

Cheers,
Ben

Re: Baloo is not dead, it just smells a little funny

[Ben Cooksley]

On Thu, Feb 1, 2018 at 5:43 AM, Michael Heidelbach  wrote:
> Hi!

Hi Michael,

>
> Let me introduce myself first. When I started contributing to KDE with the
> beginning of this year this was the status:
>
> No experience in C++ at all
> Wtr coding: No experience in collaboration and the technologies involved
> No experience in many other things
> Good javascript knowledge
> Hobby developer
>
> since then:
>
> arcanist hater (that's reciprocal)
>
> That did not keep me from being active: 14 commits this month.
>
> To the point. Baloo:
> I think baloo is fantastic! I'm a heavy user of metadata to organize my
> media (audio, video, ebooks) and I love how it integrates into the desktop.
> As a result I know many of the kinks of the packages involved and want to
> improve them. Baloo is in the centre of it.
> The "low hanging fruit"-phase will soon be over for me. Very soon I'm going
> to really tackle the bear (why is baloo called baloo anyway?). That is
> challenging. Time to roll-up my sleeves. BUT! Neither can I nor do I want to
> do this alone. Currently there are only 2 (two) regular committers to baloo,
> James Smith and me.
>
>
> Sadly baloo has no maintainer. I would take on that task if were more
> experienced, but for now that wouldn't be reasonable and also would issue a
> wrong message. I intend do it when I feel ready for it and it still is a
> necessity.
>
> "The bear must live". This is a non-exhaustive list of things I need in the
> meantime:
>
> Reviewers. Many of my submits for baloo have been lingering on for days
> without reaction. (OK, I'm impatient. But please don't make poking on
> #kde-devel a regular element of my workflow.)
> Critique! I want you to look at my code and be harsh with it.
> Guidance. Old code, new code, styles, dependencies ... KDE code is like a
> jungle to me. In coding I usually learn best by looking how others have done
> it, analyze and adapt or adopt. With KDE code that often times doesn't work
> out for me.  E.g. I haven't been able to derive rules for string handling
> "otto", 'otto', QStringWhatEver("otto") or what? Or CMakeFiles: a horror!
> Also testing strategies, very diverse...
>
> There is no critique inherent to this list, not at all. You are helpful!
>
> The list of what I want is not really a list:
>
> @Community Admins: Baloo project page?

I've now created #baloo on Phabricator.
If you would like to use the wiki for more indepth content other than
just a description we can also look into that.

>
>
> So here's my plea:
>
> If you are an experienced C++-programmer and know the KDE code-base well,
> please watch the things the two of us doing for baloo, criticize me, and
> first of all: become a reviewer for the requests targeted at baloo or
> baloo-widgets, please! Help me keep the pace!
>
>
> Thank you for reading all this,
>
> Michael
>
>

Cheers,
Ben Cooksley
KDE Sysadmin

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Sun, Feb 11, 2018 at 4:06 PM, Nate Graham  wrote:
> + kde-devel to widen the conversation

Hi Nate,

>
>
> On 02/10/2018 05:48 PM, Nicolás Alvarez wrote:
>>
>> Meanwhile... maybe you can do some loud blog posts calling for triagers?
>> :)
>
>
> Sounds good. Before then, we need to clean up the wiki page for this:
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
>
> It's thorough and mostly up to date, but huge and intimidating. I've been
> working to improve it, but assistance would be appreciated
>
>
> Problem #2: the fact that you need to ask permission before gaining write
> access to other people's hugs is a gigantic blockade to getting more
> community bug triaging. A LibreOffice bug triager came by recently and
> explained that they got an enormous amount more community bug triaging by
> moving away from this policy and only locking down a few things (like the
> priority and assignee, I think) and leaving the rest open. He said that in
> particular it was a big boost to the number of bugs (correctly) marked as
> duplicates and closed as fixed.

Interesting. If the broader community is okay with this I see no
reason why we couldn't rearrange the permissions and how they're
currently setup.
I would prefer to restrict the bulk change tools to developers still
(as undoing the damage they do is much harder) but one-by-one changes
should be fine to release I think.

We basically operate in this manner for Phabricator already and
haven't had issues to my knowledge (and if people are silly we always
have the option of closing their accounts)

>
> Thoughts?
>
> Nate
>

Cheers,
Ben

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Mon, Feb 12, 2018 at 8:52 AM, Nate Graham  wrote:
> All right, so let's give it a shot. How about we make it so that normal
> users have full privilages except the following:
>
> - Can't bulk change
> - Can't change Importance field
> - Can't re-open bugs in the CLOSED state

Sounds reasonable. I'll leave this open for another 24-48 hours or so
to allow those who haven't yet commented the chance to do so, then we
can look into actioning this.

Nate, would you mind opening a ticket around that time to remind us to
action this?

Cheers,
Ben

>
> Nate
>
>
>
>
> On 02/11/2018 09:17 AM, David Edmundson wrote:
>>
>>
>> Interesting. If the broader community is okay with this I see no
>> reason why we couldn't rearrange the permissions and how they're
>> currently setup.
>> I would prefer to restrict the bulk change tools to developers still
>> (as undoing the damage they do is much harder) but one-by-one changes
>> should be fine to release I think.
>>
>> Totally fine with it, I think it'll really help. I've ended up filing
>> quite a few sysadmin requests requesting editbugs be granted to various
>> people.
>>
>> I'd like it to keep it so that even if normal users can reopen bugs from
>> resolved, they can't from closed.
>>
>> David
>
>

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

Hi all,

I've now put together the necessary changes and have deployed them on
the Bugzilla Testbed, at bugstest.kde.org.
If people could please login and verify things are working correctly
for them still that would be appreciated.

I've given anyone with editbugs membership currently membership of the
new 'contributors' group which has the power to perform the three
actions we decided to restrict.
My testing indicates that everything is working correctly.

Please note that bugstest.kde.org's email capability is disabled, so
you won't be able to create an account or reset your password if you
are unable to login.
(This does mean that nobody will see email relating to changes you
make there though)

Thanks,
Ben

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Wed, Feb 21, 2018 at 9:34 AM, pointedstick  wrote:
> I have editbugs power on bugs.kde.org, but cannot edit the Importance field
> or mark a bug as CLOSED on bugstest.kde.org. I appear to have the new normal
> permissions.

Thanks for confirming my testing Nate.

I've now gone ahead and rolled this out on bugs.kde.org.
Everyone who had editbugs rights already (all 3,221 of us) have been
made members of the new (fully empowered) contributors group.

If someone would like to announce this via a blog post please feel
free to do so as I likely won't have time in the next few days to do
so.

Cheers,
Ben

>
> Nate
>
>
>  On Sat, 17 Feb 2018 23:51:42 -0800 Ben Cooksley
> wrote 
>
> Hi all,
>
> I've now put together the necessary changes and have deployed them on
> the Bugzilla Testbed, at bugstest.kde.org.
> If people could please login and verify things are working correctly
> for them still that would be appreciated.
>
> I've given anyone with editbugs membership currently membership of the
> new 'contributors' group which has the power to perform the three
> actions we decided to restrict.
> My testing indicates that everything is working correctly.
>
> Please note that bugstest.kde.org's email capability is disabled, so
> you won't be able to create an account or reset your password if you
> are unable to login.
> (This does mean that nobody will see email relating to changes you
> make there though)
>
> Thanks,
> Ben
>
>
>
>

Global Dependency and Release Freeze

[Ben Cooksley]

Hi all,

Due to a snowball of various dependency bumps and other tickets which
have been submitted over the past few days, i'm imposing a global
dependency freeze upon all KDE projects.

In addition to this, due to the workload these also create, I am also
imposing a total release freeze on all Extragear projects. Requests
for tarballs to be released will not be actioned while the freeze is
imposed. It would be appreciated if people could please hold off on
filing those.

Sysadmin needs time to catch up and get the CI system back into a
settled state following changes to Windows and FreeBSD images, in
addition to sorting out the other tickets we have received over the
past few days some of which will require some time to deal with.

Requests for exceptions to these freezes are not available, however we
will endeavour to lift them as soon as is practicable.

Regards,
Ben Cooksley
KDE Sysadmin

Re: CI fails to build my last commit in a file I did not change

[Ben Cooksley]

On Fri, Mar 2, 2018 at 10:08 AM, Albert Astals Cid  wrote:
> El dijous, 1 de març de 2018, a les 10:25:51 CET, Michael Heidelbach va 
> escriure:
>> Hi!
>>
>> Applications baloo-widgets kf5-qt5 FreeBSDQt5.9/
>> > kf5-qt5%20FreeBSDQt5.9/>
>>
>> What to do now?
>
> I think that is because
> https://build.kde.org/view/CI%20Management/job/Dependency%20Build%20Applications%20kf5-qt5%20FreeBSDQt5.9/
> failed, i've triggered a new build.

The Dependency Build failed due to other breakage as part of FreeBSD
upgrades which have recently been done.
I've asked the FreeBSD KDE folks to take a look.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> Cheers,
>>
>> Michael
>
>
>
>

Re: Global Dependency and Release Freeze

[Ben Cooksley]

Hi all,

We've now finished catching up on everything and getting the CI system
settled down again so we're now able to lift the freeze.
I'll start sorting out the releases which have been requested shortly.

There is still some lingering breakage impacting Akonadi and KIO
however those can be fixed in isolation and do not affect other
builds.

The only significant breakage remaining is a crash within
update-mime-database which means tests reliant on XDG mimetypes may
fail or behave unusually on Windows.
Compilation is not affected by this.

Cheers,
Ben

Phabricator Notification Mails

[Ben Cooksley]

Hi all,

It has been brought to my attention that some find that they are
receiving too much mail or other notifications from Phabricator. For
those who are unaware there are numerous options available within
Phabricator to allow you to control how much it notifies you of
changes.

To customise the notices you receive, open your account settings
(available from the dropdown menu beside your avatar in the top
menubar, or at https://phabricator.kde.org/settings/) and select the
"Email Preferences" section.

You can choose to receive email, just receive an in-Phabricator
notification, or receive nothing at all for the various categories
provided there.

In the case of mailing lists, Sysadmin also has the option of
customising these for the list itself as well. Should people wish to
have this changed please bring it up on the list itself then file a
ticket once a consensus has been reached. Unfortunately Community
Admins do not have the ability to change these settings.

If you are receiving duplicate email for a project (because you are
also subscribed to it's mailing list) then Phabricator also allows you
to disable this by opening the Project, browsing to Members and
selecting the "Disable Mail" option.

If a large number of people find themselves needing to use the
"Disable Mail" option then we may need to reconsider how we are
currently setting up Herald rules (currently we subscribe the Project
and rely on the mailing list being a member of the Project to send
mail to the list - this also has the added benefit of looping the list
in on changes to tasks without needing an additional Herald rule).

Cheers,
Ben

Phabricator mail disruption

[Ben Cooksley]

Hi all,

Some of you may have noticed that the delivery of Phabricator mail has
been disrupted over the past few hours. This is due to Spamcop
blacklisting the relays used by Mailgun to send our Phabricator email.

List moderators, i'm afraid you will need to approve any mail which
has been automatically held for your approval.

I have now resolved this issue by terminating our use of Spamcop. The
decision on their part to blacklist a major transactional email
processor is considered completely unacceptable and I can no longer
place any faith in the reliability of their blacklist.

Such decisions demonstrate, in my opinion, a complete and reckless
disregard for the impacts of their actions on others and a lack of
consideration for those who don't want to be used to force others to
take action against a third party.

I will also be filing a complaint with Mailgun concerning this as
their inability to resolve this in a speedy manner is not acceptable
either. It is likely our use of their service will also be terminated.

For those wondering why we were using Mailgun in the first place, this
is because Phabricator's handlers mail sending using SMTP are only
able to generate either HTML or Plain-Text email. When using Mailgun,
you can send both in the same email.

As some members of our community have an intense hatred of HTML based
email it is necessary for this compatibility option to be provided, as
the HTML formatted email is much nicer to work with for those who
don't mind HTML based email.

My apologies for the disruption.

Regards,
Ben Cooksley
KDE Sysadmin

Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.

[Ben Cooksley]

On Tue, Apr 10, 2018 at 6:43 AM, Nate Graham  wrote:
>
>
>  On Mon, 09 Apr 2018 11:35:49 -0700 Elvis 
> Angelaccio wrote 
>  > Yes.
>  >
>  > Note that this is not kio-specific: every library in kdelibs that used to
>  > have its own bugzilla product should be "merged" with the new
>  > frameworks-xxx product (actual bugs still open should be moved, everything
>  > else should be closed). As you can guess, it requires a lot of work.
>
> Right, I was just bringing up KIO because it's a pretty high-profile example.
>
>
>  > >and then eventually remove kio and kfile?
>  >
>  > What about old bugs? They should still belong to those products because
>  > that's where the bug used to be. So we cannot just delete them.
>
> Old bugs should be triaged and closed or moved. I've already started doing 
> that. Can we at least hide the old products from view once they're empty?

We can hide old products yes. I did this for a KMyMoney product which
was no longer in use following their shift from KDE 4 to KF5.

>
> Who has permission to create new components and mark existing products as not 
> accepting new bugs? I'd like to gain those permissions myself, given my bug 
> triaging activities (I'm #2 in closed bugs over the past 365 days: 
> https://bugs.kde.org/weekly-bug-summary.cgi?tops=20&days=365).

Like many things, this is held by Sysadmin.

>
> Nate
>

Cheers,
Ben

Upcoming CI changes - service disruption

[Ben Cooksley]

Hi all,

In order to allow for two replacement physical build hosts to be
rotated in and the old ones to be decommissioned, i'm scheduling some
downtime for both the CI system and the Binary Factory tomorrow.

Assuming all goes well, this downtime should be fairly short. During
the downtime Jenkins will still be accessible, however builds will not
trigger on push as they usually do. The system will perform these
builds once the changeover is completed.

To help us detect issues with the changeover, it would be appreciated
if everyone could make sure their builds, particularly on FreeBSD and
Windows are successful prior to the switch.

At this time the following projects appear to have builds which have
regressed on these platforms:
- KItinerary
- Plasma Vault
- Amarok

Thanks,
Ben

Re: Upcoming CI changes - service disruption

[Ben Cooksley]

On Tue, Apr 10, 2018 at 10:42 PM, Ben Cooksley  wrote:
> Hi all,

Hi everyone,

>
> In order to allow for two replacement physical build hosts to be
> rotated in and the old ones to be decommissioned, i'm scheduling some
> downtime for both the CI system and the Binary Factory tomorrow.
>
> Assuming all goes well, this downtime should be fairly short. During
> the downtime Jenkins will still be accessible, however builds will not
> trigger on push as they usually do. The system will perform these
> builds once the changeover is completed.

The switchover has now been completed.
Unfortunately there were some minor issues which did crop up once the
switch was done, but those have now been rectified I believe.

My apologies to the developers of plasma-workspace, knewstuff and
ktexteditor - builds for your projects were affected by this.
Replacement builds have been started which should process normally.

>
> To help us detect issues with the changeover, it would be appreciated
> if everyone could make sure their builds, particularly on FreeBSD and
> Windows are successful prior to the switch.
>
> At this time the following projects appear to have builds which have
> regressed on these platforms:
> - KItinerary
> - Plasma Vault
> - Amarok

For several other projects there have unfortunately been regressions.
In instances where this impacts on Dependency Builds that need to be
conducted, developers will be receiving followup mail from me shortly.

>
> Thanks,
> Ben

Regards,
Ben

Re: Flatpak packaging for stable releases

[Ben Cooksley]

On Sun, Apr 15, 2018 at 11:52 AM, Aleix Pol  wrote:
> On Sat, Apr 14, 2018 at 11:20 PM, Matthieu Gallien
>  wrote:
>> Hello,
>>
>> I really appreciate the work that has gone into flatpak and the excellent
>> support for it in KDE and the KDE infrastructure for it.
>>
>> I have an hard time understanding what is the best way to distribute a stable
>> release through flatpak.
>>
>> I am not sure if the KDE flatpak repositories are supposed to also be used 
>> for
>> stable releases.
>>
>> I have seen a few KDE applications being also hosted on flathub. Is this the
>> way to go ?
>
> flatpak-kde-runtime is used for flathub stable releases,
> flatpak-kde-applications isn't.

Just curious - does this mean every download from Flathub for a KDE
application hits flatpak-kde-runtime, or is that a one-off hit when
the bundle is generated and uploaded to Flathub?

>
> As for your application, I would say the quickest way to go is flathub
> at this moment.
>
> Aleix

Cheers,
Ben

Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[Ben Cooksley]

On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw  wrote:
>
>
> On 08.05.2018 23:15, Milian Wolff wrote:
>>
>> On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:
>>>
>>> Hello,
>>>
>>> I have a question regarding kdesrc-build and CMake.
>>>
>>> I setup the build environment variables and ran kdesrc-build and got a
>>> compiler error kinfocenter.
>>>
>>> I investigated
>>> /home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt and
>>> found the following lines
>>>
>>>   //The directory containing a CMake configuration file for
>>> KF5Service.
>>>   KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service
>>>
>>>   //The directory containing a CMake configuration file for KF5Solid.
>>>   KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid
>>>
>>>   //The directory containing a CMake configuration file for
>>> KF5Wayland.
>>>   KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland
>>>
>>> The directories of the needed KF5 frameworks point to the system wide
>>> installed ones.
>>>
>>> I removed the system-wide devel package for solid (because it caused the
>>> compiler error) and ran kdesrc-build again:
>>>
>>>   //The directory containing a CMake configuration file for
>>> KF5Service.
>>>   KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service
>>>
>>>   //The directory containing a CMake configuration file for KF5Solid.
>>>   KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid
>>>
>>>   //The directory containing a CMake configuration file for
>>> KF5Wayland.
>>>   KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland
>>>
>>> Now it shows the correct (local) path for solid (but not the other ones).
>>> Is
>>> there an environment variable or something I have to set to tell Cmake to
>>> always look for local modules first?
>>
>>
>> Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:
>>
>> https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it
>
>
> Thanks for the hint. The variable was already set:
>
> CMAKE_PREFIX_PATH=/home/gregor/kde/usr:
>
> In the blog post, it is said, that CMAKE_PREFIX_PATH is searched _first_. I
> find it strange that I had to uninstall the system-wide devel package in
> order to have cmake pick up the library in /home/gregor/kde/usr. And for the
> other libraries it still uses /usr. Any idea how to investigate this
> further?

If you have previously run CMake without setting CMAKE_PREFIX_PATH you
will need to remove your build directory first, otherwise it will
reuse modules it has already found.

>
> Gregor

Cheers,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Wed, May 9, 2018 at 8:33 PM, Boudewijn Rempt  wrote:
> On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote:
>> Hi all,
>>
>> To improve the user experience around email and in-application
>> notifications from Phabricator, sysadmin have made some changes to the
>> configuration of our Herald rules.
>>
>> Going forward, instead of subscribing projects to reviews, we will
>> only be subscribing mailing lists now.
>
> So, should we now get all phabricator mail at, say, kimages...@kde.org, or
> should we create a second mailing list, say krita-p...@kde.org? I do want to
> receive mail for everything krita-related that happens on phabricator!

That decision is up to individual projects.
To date most have opted to treat Phabricator like Reviewboard and have
it sent to their usual project mailing list.

>
>> For those reviews which have
>> already been created, they will be updated to reflect the new practice
>> the next time they are changed.
>>
>> This means that individual project members will no longer receive
>> notifications and emails for every single review or task change that
>> affects their project. Instead, they will only receive notifications
>> and emails for reviews they have been individually subscribed to.
>
> :-(
>
>>
>> To help this change take full effect, it would be appreciated if
>> people refrain from adding Projects as reviewers, as that will have
>> the effect of subscribing the Project to the review as well
>
> But what if that's what a project really wants?

This change was made due to a series of complaints Sysadmin received
noting that people were finding their Phabricator notification queues
useless, and who had also taken the step of filtering all mail they
received from Phabricator to a folder they never read. This defeats
the entire purpose of the system, and also means that reviews which
require that person's explicit attention were being missed.

It also meant people weren't responding to Sysadmin responses to
tickets these people had filed.

>
>> (Phabricator does not require you specify a reviewer)
>
> I know. Most newcomers don't and do not specify any reviewer, so review
> requests often fall between the cracks.

It was originally envisioned that every repository should have been
caught by one or more Herald rules which would have ensured mailing
lists were notified that the review had been created, hence why
reviewers weren't needed.

>
>> Should anyone have any questions regarding this, please open a thread
>> on the kde-devel@kde.org mailing list.
>
>
> I discovered today that I did not have a subscription to this list and that
> there are no archives, so I've missed all discussions, if there have been any.
> I would have expected the discussion to happen on kde-community, but maybe we
> just have too many mailing lists.

There wasn't a discussion in advance of this change as the perceived
impact was minimal (we simply substituted projects for mailing lists
in the Herald rules)
No Herald rules were removed.

Looking at our list of rules it seems that Krita doesn't have any
rules so it looks like you may have always been missing out on these
notifications!

>
>
> --
> Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Cheers,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Wed, May 9, 2018 at 9:25 PM, Timothée Giet  wrote:
> Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit :
>>
>> On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote:
>>>
>>> Hi all,
>>>
>>> To improve the user experience around email and in-application
>>> notifications from Phabricator, sysadmin have made some changes to the
>>> configuration of our Herald rules.
>>>
>>> Going forward, instead of subscribing projects to reviews, we will
>>> only be subscribing mailing lists now.
>>
>> So, should we now get all phabricator mail at, say, kimages...@kde.org, or
>> should we create a second mailing list, say krita-p...@kde.org? I do want
>> to
>> receive mail for everything krita-related that happens on phabricator!
>>
>>> For those reviews which have
>>> already been created, they will be updated to reflect the new practice
>>> the next time they are changed.
>>>
>>> This means that individual project members will no longer receive
>>> notifications and emails for every single review or task change that
>>> affects their project. Instead, they will only receive notifications
>>> and emails for reviews they have been individually subscribed to.
>>
>> :-(
>>
>>> To help this change take full effect, it would be appreciated if
>>> people refrain from adding Projects as reviewers, as that will have
>>> the effect of subscribing the Project to the review as well
>>
>> But what if that's what a project really wants?
>
>
> That is also exactly what we use to do in GCompris... it's the best solution
> for us to easily connect the diff to the relevant group of people.
> Subscribing our current mailing list is surely not what we want.

If you could elaborate on your use case here that would be appreciated.
Traditionally most development has taken place via mailing lists, so
it's interesting to see people who don't follow that model.

(To date all Herald rule setup requests have been for mailing lists)

I note that GCompris also doesn't appear to have any rules setup,
which is possibly why this hasn't come up before.

>
>>
>>> (Phabricator does not require you specify a reviewer)
>>
>> I know. Most newcomers don't and do not specify any reviewer, so review
>> requests often fall between the cracks.
>>>
>>> Should anyone have any questions regarding this, please open a thread
>>> on the kde-devel@kde.org mailing list.
>>
>>
>> I discovered today that I did not have a subscription to this list and
>> that
>> there are no archives, so I've missed all discussions, if there have been
>> any.
>> I would have expected the discussion to happen on kde-community, but maybe
>> we
>> just have too many mailing lists.
>
>
> I am subscribed to this list but didn't see much discussion on the topic
> before this change announcement.
>
> Timothée
>
>

Cheers,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Wed, May 9, 2018 at 9:47 PM, Milian Wolff  wrote:
> On Mittwoch, 9. Mai 2018 10:08:28 CEST Ben Cooksley wrote:
>> Hi all,
>>
>> To improve the user experience around email and in-application
>> notifications from Phabricator, sysadmin have made some changes to the
>> configuration of our Herald rules.
>>
>> Going forward, instead of subscribing projects to reviews, we will
>> only be subscribing mailing lists now. For those reviews which have
>> already been created, they will be updated to reflect the new practice
>> the next time they are changed.
>>
>> This means that individual project members will no longer receive
>> notifications and emails for every single review or task change that
>> affects their project. Instead, they will only receive notifications
>> and emails for reviews they have been individually subscribed to.
>>
>> To help this change take full effect, it would be appreciated if
>> people refrain from adding Projects as reviewers, as that will have
>> the effect of subscribing the Project to the review as well
>> (Phabricator does not require you specify a reviewer)
>>
>> Should anyone have any questions regarding this, please open a thread
>> on the kde-devel@kde.org mailing list.
>
> Is there a way to opt-in to the old behavior somehow? Or I can somehow
> manually register myself on phabricator to be notified about $anything that
> affects a given repo?
>
> I ask mainly for smaller projects like heaptrack, which don't even have a
> mailing list afaik.

Please note that anyone who hasn't had a Herald rule explicitly setup
for them is unaffected by this (this includes Heaptrack, as well as
Krita and GCompris)
The changes I made a few hours ago were only to Herald rules.

For projects which lack mailing lists (like Kile) we will continue to
subscribe Projects (as the level of traffic should be much lower and
there is no other option for notifying those involved).

This change was principally made for larger projects (who have mailing
lists) and whose activity levels and number of people involved make
notifications and email to everyone and the mailing list unusable.

>
> Bye
>
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

Regards,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Wed, May 9, 2018 at 10:45 PM, Timothée Giet  wrote:
> Le 09/05/2018 à 12:11, Ben Cooksley a écrit :
>>
>> On Wed, May 9, 2018 at 9:25 PM, Timothée Giet  wrote:
>>>
>>> Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit :
>>>>
>>>> On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> To improve the user experience around email and in-application
>>>>> notifications from Phabricator, sysadmin have made some changes to the
>>>>> configuration of our Herald rules.
>>>>>
>>>>> Going forward, instead of subscribing projects to reviews, we will
>>>>> only be subscribing mailing lists now.
>>>>
>>>> So, should we now get all phabricator mail at, say, kimages...@kde.org,
>>>> or
>>>> should we create a second mailing list, say krita-p...@kde.org? I do
>>>> want
>>>> to
>>>> receive mail for everything krita-related that happens on phabricator!
>>>>
>>>>> For those reviews which have
>>>>> already been created, they will be updated to reflect the new practice
>>>>> the next time they are changed.
>>>>>
>>>>> This means that individual project members will no longer receive
>>>>> notifications and emails for every single review or task change that
>>>>> affects their project. Instead, they will only receive notifications
>>>>> and emails for reviews they have been individually subscribed to.
>>>>
>>>> :-(
>>>>
>>>>> To help this change take full effect, it would be appreciated if
>>>>> people refrain from adding Projects as reviewers, as that will have
>>>>> the effect of subscribing the Project to the review as well
>>>>
>>>> But what if that's what a project really wants?
>>>
>>>
>>> That is also exactly what we use to do in GCompris... it's the best
>>> solution
>>> for us to easily connect the diff to the relevant group of people.
>>> Subscribing our current mailing list is surely not what we want.
>>
>> If you could elaborate on your use case here that would be appreciated.
>> Traditionally most development has taken place via mailing lists, so
>> it's interesting to see people who don't follow that model.
>>
>> (To date all Herald rule setup requests have been for mailing lists)
>>
>> I note that GCompris also doesn't appear to have any rules setup,
>> which is possibly why this hasn't come up before.
>>
>
> Thanks a lot Ben for the clarification :)
> So it seems we are unaffected by the change and can continue to work like we
> do.
> To elaborate as you asked for it, we try to use phabricator as much as
> possible for task management and review request.
> For review requests we ask people to add GCompris or one of the appropriate
> subprojects (like GCompris: Improvements) as Group-reviewer.
> This way all people subscribed to this project/sub-project gets a mail
> notification, but most importantly has it listed in his
> https://phabricator.kde.org/differential/

Thanks for that.
You should probably ask for a Herald rule to be setup as it can
automate parts of this.

>
> See http://gcompris.net/wiki/Contribution_process , especially "Asking for a
> Review Request"
>
> It seems that Krita is doing the same, since I also see lot of diffs with
> Krita reviewer in my list and notifications (which I also like to have ;) )
>
> Only "issue" for me is I have some mail duplicates from kde-edu list. It
> would be great to find a way to avoid them, but if not possible I can live
> with that.

Everyone will continue to receive duplicates where they are subscribed
to a mailing list which receives review mail and have been subscribed
(either by being the named reviewer or explicitly subscribed) for a
repository's reviews. This cannot be avoided i'm afraid (Phabricator
has no idea who is subscribed to a given list).

>
> Our devel mailing list is now mostly used for occasional wider dev
> communication, and for occasional contributors.
>
> Cheers,
> Timothée

Regards,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Thu, 10 May 2018, 02:08 Nate Graham,  wrote:

> 1. What is the canonical way to be notified of Phabricator changes for
> projects you're interested in? Subscribe to that project's mailing list?
> Can you clarify what this means for someone who joins or "watches" a
> project in Phabricator? Should we stop doing that?
>

I would recommend subscribing to the individual Projects mailing lists yes.

Joining or watching a Project would still result in email and notifications
where the Project is a reviewer. Tasks are unaffected by this.


> 2. If someone is subscribed to the project's mailing list and also joins
> the project in Phabricator, will they continue to receive duplicate emails?
>

They shouldn't receive duplicates anymore.

The only exception where duplicates would be received is if the user is
individually subscribed to tasks or reviews.


> 3. Who should be listed as reviewers for diffs? Only individual people?
> Nobody?
>

Individuals. For smaller Projects it may still be practical for the Project
to be the reviewer, however this does not scale for larger ones such as
Frameworks and Plasma (where the complaints came from)


> 4. What does this mean for projects like Dolphin or Spectacle that don't
> have mailing lists?
>

Dolphin appears to be using the kfm-devel mailing list.

Projects that don't have mailing lists (and which are small by nature) will
continue to have the Project subscribed for reviews.



> Nate
>

Cheers,
Ben


>
> On 05/09/2018 02:08 AM, Ben Cooksley wrote:
> > Hi all,
> >
> > To improve the user experience around email and in-application
> > notifications from Phabricator, sysadmin have made some changes to the
> > configuration of our Herald rules.
> >
> > Going forward, instead of subscribing projects to reviews, we will
> > only be subscribing mailing lists now. For those reviews which have
> > already been created, they will be updated to reflect the new practice
> > the next time they are changed.
> >
> > This means that individual project members will no longer receive
> > notifications and emails for every single review or task change that
> > affects their project. Instead, they will only receive notifications
> > and emails for reviews they have been individually subscribed to.
> >
> > To help this change take full effect, it would be appreciated if
> > people refrain from adding Projects as reviewers, as that will have
> > the effect of subscribing the Project to the review as well
> > (Phabricator does not require you specify a reviewer)
> >
> > Should anyone have any questions regarding this, please open a thread
> > on the kde-devel@kde.org mailing list.
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
> >
>
>

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Thu, May 10, 2018 at 8:08 AM, Nate Graham  wrote:
>  On Wed, 09 May 2018 12:46:30 -0700 Luigi 
> Toscano wrote 
>  > Nate Graham ha scritto:
>  > > Thanks for the responses, Ben.
>  > >
>  > > I'm a bit concerned that all of this raises the barrier to entry for new 
> contributors. Now they'll have to match up Phabricator projects with mailing 
> lists, which do not have a 1:1 mapping. How is someone interested in Dolphin 
> supposed to know that they need to subscribe to the kfm-dev mailing list to 
> follow the development? It doesn't have the word "Dolphin" in it or even have 
> a description set on https://mail.kde.org/mailman/listinfo. And Dolphin's own 
> Phabricator page doesn't mention anything about it.
>  >
>  > Then it's time to set the the description of the list then.
>
> Who has access to do that?
>
> This is really an issue with information availability. It's all available in 
> pieces in different places, rather than all "under one roof", so to speak. 
> It's important to centralize wherever possible so that people get the full 
> picture.

That would be the list administrator, whose email address is shown in
the footer of all pages about that mailing list by Mailman:
kfm-devel list run by frank78ac at googlemail.com

Sysadmin of course has overriding access if need be.

In regards to Dolphin's Phabricator project, it's the responsibility
of those involved with Dolphin to ensure it's project is setup to help
people find their way to the various things people will need to get
involved. KDE Connect is a reasonable example of what is possible -
https://phabricator.kde.org/tag/kde_connect/ - as is Baloo -
https://phabricator.kde.org/tag/baloo/

>
> Nate
>

Cheers,
Ben

Re: Changes to Phabricator review subscriptions

[Ben Cooksley]

On Fri, May 11, 2018 at 8:25 PM, Dmitry Kazakov  wrote:
> Hi, Ben!

Hi Dmitry,

>
> There is a small problem with not-subscribing Differential Revisions to
> projects: one cannot use Phabricator's Dashboard functionality for filtering
> the incoming revisions. Is there any way to configure dashboard's Revisions
> panel to all diffs related to a specific repository?
>
> Here is my default dashboard:
> https://phabricator.kde.org/home/menu/view/289/

You'll want to configure a search something like this -
https://phabricator.kde.org/differential/query/Q9pbWWtsYuN./#R

Please note that as Krita did not have any Herald rules previously,
this isn't something which has changed for you - it's always been this
way.

>
> In the central part it shows revisions for all the projects I'm a member of.
> If some person creates a diff against Krita repository, but doesn't add
> #krita project to it, I will **not** see this diff in the list. Is there
> some workaround to it?

The view you're showing there is a bucketed one, meaning it only cares
about the reviews for which you are a reviewer, or the submitter, of
the review.
The solution to this (and likely other projects which have a small
group of core developers who do the reviews) is probably to have
Herald add the responsible developers  as reviewers.

Subscribing whole projects didn't have this effect - it just sent
everyone in the project a notification about it.

>
> In the attachment you can find a screenshot of the panel when I'm logged in.
>
> --
> Dmitry Kazakov
>

Regards,
Ben

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Sun, May 27, 2018 at 9:05 PM, Elvis Angelaccio
 wrote:
> On Fri, May 11, 2018 at 11:06 PM Christoph Feck  wrote:
>
>> On 11.02.2018 20:52, Nate Graham wrote:
>> > All right, so let's give it a shot. How about we make it so that normal
>> > users have full privilages except the following:
>> >
>> > - Can't bulk change
>> > - Can't change Importance field
>
>> We now see regressions caused by this particular change:
>> - new 'wishlist' tickets end up reported as 'normal'
>> - crashes (even from DrKonqi) end up reported as 'normal'
>
>> Manual intervention is needed to correct these wrong states,
>> see https://bugs.kde.org/show_bug.cgi?id=391187
>
>> Unfortunately, bugzilla does not differentiate between own tickets and
>> changing tickets from others, and I doubt it was our intention to
>> remove existing abilities, so I propose to revert the permissions for
>> the 'Severity' field.
>
>> Any objections?
>
> Hi Ben,

Hi Elvis,

> given that no one objected, is it possible to fix this regression?

Christoph filed a ticket moments before your mail was sent, it should
be actioned in the next few days.

>
> Thanks,
> Elvis

Cheers,
Ben

>
>
>
>
>
>> > - Can't re-open bugs in the CLOSED state

Re: Closing old Plasma 4 bugs

[Ben Cooksley]

On Sat, Jun 9, 2018 at 9:06 AM, Scott Harvey  wrote:
> Did anyone check how much space has been freed up in the Bugzilla database?

The closure of bugs doesn't archive them from the database.
Once entered into the system they're in there permanently.

Cheers,
Ben


> On Jun 8, 2018, 3:39 PM -0500, Nate Graham , wrote:
>
> This work is done; all the bugs and feature requests in the plasma4
> product have been closed. Hope all of your inboxes survived the onslaught!
>
> Nate
>
>
>
> On 02/21/2018 07:21 AM, Nate Graham wrote:
>
> I have also cleaned up the bug triaging page:
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
>
> It's still a bit long, so any further editing to condense it a bit would
> be welcome.
>
> Nate
>
>
>
> On 02/21/2018 07:16 AM, Nate Graham wrote:
>
>
>
> On 02/21/2018 06:26 AM, Nate Graham wrote:
>
>
>
> On Feb 21, 2018, at 12:59 AM, Ben Cooksley  wrote:
>
> On Wed, Feb 21, 2018 at 9:34 AM, pointedstick
>  wrote:
> I have editbugs power on bugs.kde.org, but cannot edit the
> Importance field
> or mark a bug as CLOSED on bugstest.kde.org. I appear to have the
> new normal
> permissions.
>
>
> Thanks for confirming my testing Nate.
>
> I've now gone ahead and rolled this out on bugs.kde.org.
> Everyone who had editbugs rights already (all 3,221 of us) have been
> made members of the new (fully empowered) contributors group.
>
> If someone would like to announce this via a blog post please feel
> free to do so as I likely won't have time in the next few days to do
> so.
>
>
> Fantastic! I'll do that.
>
>
> Done:
> https://pointieststick.wordpress.com/2018/02/21/its-now-much-easier-to-be-a-bug-triager/
>
>
> Nate
>
>
>

Binary Factory & Windows CI builds temporarily offline

[Ben Cooksley]

Hi everyone,

Due to some issues with MSVC we are currently encountering, the Binary
Factory is currently unable to successfully complete Windows builds.
As part of diagnosing these, reinstallation of MSVC has been required,
which has required Windows CI builds to be disabled temporarily.

It is likely that CI coverage will be restored sometime in the next 24
hours, however Binary Factory capability will take longer.

Unfortunately due to the nature of these failures it is possible we
will not be able to restore full service until Microsoft releases the
3rd preview release of Visual Studio 15.8.

For those interested, the issue preventing us from restoring coverage
is a compiler/linker regression within MSVC in the 15.7 series, which
occurs when building the WebRTC component used within QtWebEngine (and
which also affects builds of Firefox and Chrome for those doing that).

Unfortunately rolling back to an earlier version of MSVC isn't an
option in our case as changes to the Visual Studio build utility
(MSBuild) cause it to pass unsupported arguments to the
compiler/linker when building glib. It would appear that regardless of
the version of Visual Studio you choose to install, you receive a
version of MSBuild which only works properly with 15.7.

In most circumstances this would not be an issue, however other
changes necessitate a complete rebuild of the entire dependency tree
(including glib and Qt).

My apologies for any inconvenience this causes.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Binary Factory & Windows CI builds temporarily offline

[Ben Cooksley]

On Mon, Jun 11, 2018 at 4:18 PM, Ben Cooksley  wrote:
> Hi everyone,

Hi all,

>
> Due to some issues with MSVC we are currently encountering, the Binary
> Factory is currently unable to successfully complete Windows builds.
> As part of diagnosing these, reinstallation of MSVC has been required,
> which has required Windows CI builds to be disabled temporarily.
>
> It is likely that CI coverage will be restored sometime in the next 24
> hours, however Binary Factory capability will take longer.

CI Coverage has now been restored, however please note that dependency
changes to non-KDE projects will not be possible until the Binary
Factory has been restored to operational condition (as the CI relies
on Craft for non-KDE projects, and it is unable to complete builds due
to the WebRTC/Glib issues).

We are also unable to deploy any new CI nodes for Windows at this time
due to the same issue.

The Binary Factory remains inoperable at this time.

>
> Unfortunately due to the nature of these failures it is possible we
> will not be able to restore full service until Microsoft releases the
> 3rd preview release of Visual Studio 15.8.
>
> For those interested, the issue preventing us from restoring coverage
> is a compiler/linker regression within MSVC in the 15.7 series, which
> occurs when building the WebRTC component used within QtWebEngine (and
> which also affects builds of Firefox and Chrome for those doing that).
>
> Unfortunately rolling back to an earlier version of MSVC isn't an
> option in our case as changes to the Visual Studio build utility
> (MSBuild) cause it to pass unsupported arguments to the
> compiler/linker when building glib. It would appear that regardless of
> the version of Visual Studio you choose to install, you receive a
> version of MSBuild which only works properly with 15.7.
>
> In most circumstances this would not be an issue, however other
> changes necessitate a complete rebuild of the entire dependency tree
> (including glib and Qt).
>
> My apologies for any inconvenience this causes.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Regards,
Ben

Upcoming change to mail infrastructure

[Ben Cooksley]

Hi all,

We've recently completed configuration of a new mail server which will
be replacing the current system which handles kde.org mail. This
system will be assuming responsibility for mailing lists as well as
authenticated mail sending for those who require that service.

To ensure a smooth transition however some changes may be needed on
your side, especially if you are using our authenticated mail sending
service.

As part of the new system, we have configured updated filters which
will begin enforcing DMARC policies for domains which have specified
these, along with improved SPF verification. As a consequence, if you
are forwarding mail from another provider to your kde.org or
kdemail.net address, this may cease working following the transition.
We recommend you configure these services to instead forward directly
to your final mail provider should this impact on you.

For those users of the authenticated mail service: please change your
mail client to use the server "letterbox.kde.org" instead of the
current server "postbox.kde.org". Additionally, if you are currently
using port 588 to send mail, this should now be changed to the
standard submission port, 587.

As part of this setup we have also completely reworked our
SpamAssassin setup. As a consequence of this, we are now looking for
spam mail to begin training the filter to ensure it is ready to begin
filtering the substantial mail volumes Postbox handles.

Mailing list moderators whose lists receive significant quantities of
spam are therefore requested to not discard this, and instead let us
know so we can use the spam from your moderation queue to train the
filter. Please note that we can grab the mail directly from the queue,
so forwarding it elsewhere is not required.

Once the filter has been sufficiently trained, we will commence the
cutover and transfer handling of kde.org mail, including mailing
lists, to the new system.

Should anyone have any questions regarding this process, please let us know.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Upcoming change to mail infrastructure

[Ben Cooksley]

On Tue, Jul 3, 2018 at 10:44 PM, Paul Brown  wrote:
> On martes, 3 de julio de 2018 12:29:41 (CEST) Ben Cooksley wrote:
>> Hi all,
>>
>> We've recently completed configuration of a new mail server which will
>> be replacing the current system which handles kde.org mail. This
>> system will be assuming responsibility for mailing lists as well as
>> authenticated mail sending for those who require that service.
>>
>> To ensure a smooth transition however some changes may be needed on
>> your side, especially if you are using our authenticated mail sending
>> service.
>>
>> As part of the new system, we have configured updated filters which
>> will begin enforcing DMARC policies for domains which have specified
>> these, along with improved SPF verification. As a consequence, if you
>> are forwarding mail from another provider to your kde.org or
>> kdemail.net address, this may cease working following the transition.
>> We recommend you configure these services to instead forward directly
>> to your final mail provider should this impact on you.
>>
>> For those users of the authenticated mail service: please change your
>> mail client to use the server "letterbox.kde.org" instead of the
>> current server "postbox.kde.org". Additionally, if you are currently
>> using port 588 to send mail, this should now be changed to the
>> standard submission port, 587.
>>
>> As part of this setup we have also completely reworked our
>> SpamAssassin setup. As a consequence of this, we are now looking for
>> spam mail to begin training the filter to ensure it is ready to begin
>> filtering the substantial mail volumes Postbox handles.
>>
>> Mailing list moderators whose lists receive significant quantities of
>> spam are therefore requested to not discard this, and instead let us
>> know so we can use the spam from your moderation queue to train the
>> filter. Please note that we can grab the mail directly from the queue,
>> so forwarding it elsewhere is not required.
>>
>> Once the filter has been sufficiently trained, we will commence the
>> cutover and transfer handling of kde.org mail, including mailing
>> lists, to the new system.
>>
>> Should anyone have any questions regarding this process, please let us know.
>>
>> Regards,
>> Ben Cooksley
>> KDE Sysadmin
>
> When do you plan to finalise the transition and flip the switch?

Once the Bayes filter has been sufficiently trained, which may take a
few days depending on how much spam we collect.
I've no other clearer timeline than that at this stage i'm afraid.

>
> Cheers
>
> Paul

Regards,
Ben

> --
> Promotion & Communication
>
> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
>

Re: Upcoming change to mail infrastructure

[Ben Cooksley]

On Tue, Jul 3, 2018 at 11:11 PM, Paul Brown  wrote:
> On martes, 3 de julio de 2018 12:59:49 (CEST) Ben Cooksley wrote:
>> On Tue, Jul 3, 2018 at 10:44 PM, Paul Brown  wrote:
>> > On martes, 3 de julio de 2018 12:29:41 (CEST) Ben Cooksley wrote:
>> >> Hi all,
>> >>
>> >> We've recently completed configuration of a new mail server which will
>> >> be replacing the current system which handles kde.org mail. This
>> >> system will be assuming responsibility for mailing lists as well as
>> >> authenticated mail sending for those who require that service.
>> >>
>> >> To ensure a smooth transition however some changes may be needed on
>> >> your side, especially if you are using our authenticated mail sending
>> >> service.
>> >>
>> >> As part of the new system, we have configured updated filters which
>> >> will begin enforcing DMARC policies for domains which have specified
>> >> these, along with improved SPF verification. As a consequence, if you
>> >> are forwarding mail from another provider to your kde.org or
>> >> kdemail.net address, this may cease working following the transition.
>> >> We recommend you configure these services to instead forward directly
>> >> to your final mail provider should this impact on you.
>> >>
>> >> For those users of the authenticated mail service: please change your
>> >> mail client to use the server "letterbox.kde.org" instead of the
>> >> current server "postbox.kde.org". Additionally, if you are currently
>> >> using port 588 to send mail, this should now be changed to the
>> >> standard submission port, 587.
>> >>
>> >> As part of this setup we have also completely reworked our
>> >> SpamAssassin setup. As a consequence of this, we are now looking for
>> >> spam mail to begin training the filter to ensure it is ready to begin
>> >> filtering the substantial mail volumes Postbox handles.
>> >>
>> >> Mailing list moderators whose lists receive significant quantities of
>> >> spam are therefore requested to not discard this, and instead let us
>> >> know so we can use the spam from your moderation queue to train the
>> >> filter. Please note that we can grab the mail directly from the queue,
>> >> so forwarding it elsewhere is not required.
>> >>
>> >> Once the filter has been sufficiently trained, we will commence the
>> >> cutover and transfer handling of kde.org mail, including mailing
>> >> lists, to the new system.
>> >>
>> >> Should anyone have any questions regarding this process, please let us
>> >> know.
>> >>
>> >> Regards,
>> >> Ben Cooksley
>> >> KDE Sysadmin
>> >
>> > When do you plan to finalise the transition and flip the switch?
>>
>> Once the Bayes filter has been sufficiently trained, which may take a
>> few days depending on how much spam we collect.
>> I've no other clearer timeline than that at this stage i'm afraid.
>
> Sure. I ask so that, when you do, we know and can check things are working and
> we are not left sitting around oblivious and wondering why everybody has
> suddenly gone awfully quiet.
>
> To avoid this I suppose that, when you do know the exact time and date, you
> will make it public, right?

Yes, there will be a notification made when the changeover is done,
and Letterbox (the new system) will be monitored extensively for the
first hour or so to ensure everything is working as expected.

Cheers,
Ben

>
> Cheers
>
> Paul
> --
> Promotion & Communication
>
> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
>

Re: Upcoming change to mail infrastructure

[Ben Cooksley]

On Tue, Jul 3, 2018 at 11:25 PM, Paul Brown  wrote:
> On martes, 3 de julio de 2018 13:12:56 (CEST) Ben Cooksley wrote:
>> On Tue, Jul 3, 2018 at 11:11 PM, Paul Brown  wrote:
>> > On martes, 3 de julio de 2018 12:59:49 (CEST) Ben Cooksley wrote:
>> >> On Tue, Jul 3, 2018 at 10:44 PM, Paul Brown  wrote:
>> >> > On martes, 3 de julio de 2018 12:29:41 (CEST) Ben Cooksley wrote:
>> >> >> Hi all,
>> >> >>
>> >> >> We've recently completed configuration of a new mail server which will
>> >> >> be replacing the current system which handles kde.org mail. This
>> >> >> system will be assuming responsibility for mailing lists as well as
>> >> >> authenticated mail sending for those who require that service.
>> >> >>
>> >> >> To ensure a smooth transition however some changes may be needed on
>> >> >> your side, especially if you are using our authenticated mail sending
>> >> >> service.
>> >> >>
>> >> >> As part of the new system, we have configured updated filters which
>> >> >> will begin enforcing DMARC policies for domains which have specified
>> >> >> these, along with improved SPF verification. As a consequence, if you
>> >> >> are forwarding mail from another provider to your kde.org or
>> >> >> kdemail.net address, this may cease working following the transition.
>> >> >> We recommend you configure these services to instead forward directly
>> >> >> to your final mail provider should this impact on you.
>> >> >>
>> >> >> For those users of the authenticated mail service: please change your
>> >> >> mail client to use the server "letterbox.kde.org" instead of the
>> >> >> current server "postbox.kde.org". Additionally, if you are currently
>> >> >> using port 588 to send mail, this should now be changed to the
>> >> >> standard submission port, 587.
>> >> >>
>> >> >> As part of this setup we have also completely reworked our
>> >> >> SpamAssassin setup. As a consequence of this, we are now looking for
>> >> >> spam mail to begin training the filter to ensure it is ready to begin
>> >> >> filtering the substantial mail volumes Postbox handles.
>> >> >>
>> >> >> Mailing list moderators whose lists receive significant quantities of
>> >> >> spam are therefore requested to not discard this, and instead let us
>> >> >> know so we can use the spam from your moderation queue to train the
>> >> >> filter. Please note that we can grab the mail directly from the queue,
>> >> >> so forwarding it elsewhere is not required.
>> >> >>
>> >> >> Once the filter has been sufficiently trained, we will commence the
>> >> >> cutover and transfer handling of kde.org mail, including mailing
>> >> >> lists, to the new system.
>> >> >>
>> >> >> Should anyone have any questions regarding this process, please let us
>> >> >> know.
>> >> >>
>> >> >> Regards,
>> >> >> Ben Cooksley
>> >> >> KDE Sysadmin
>> >> >
>> >> > When do you plan to finalise the transition and flip the switch?
>> >>
>> >> Once the Bayes filter has been sufficiently trained, which may take a
>> >> few days depending on how much spam we collect.
>> >> I've no other clearer timeline than that at this stage i'm afraid.
>> >
>> > Sure. I ask so that, when you do, we know and can check things are working
>> > and we are not left sitting around oblivious and wondering why everybody
>> > has suddenly gone awfully quiet.
>> >
>> > To avoid this I suppose that, when you do know the exact time and date,
>> > you
>> > will make it public, right?
>>
>> Yes, there will be a notification made when the changeover is done,
>
> If you send a notification via email (how else?) and people on the other side
> are not receiving email because something went wrong, how are they going to
> know?
>
> Wouldn't it be better to send a message out, say, a couple of hours  *BEFORE*
> you change over and then flip the switch? Then users can test sending and
> receiving when the time comes.

All going well, you probably won't even notice the switch over.
We've done these changeovers in the past, so i'm not too concerned
about problems, as we'll be able to monitor them easily.

Cheers,
Ben

>
> Paul
>
>> and Letterbox (the new system) will be monitored extensively for the
>> first hour or so to ensure everything is working as expected.
>>
>> Cheers,
>> Ben
>>
>> > Cheers
>> >
>> > Paul
>> > --
>> > Promotion & Communication
>> >
>> > www: http://kde.org
>> > Mastodon: https://mastodon.technology/@kde
>> > Facebook: https://www.facebook.com/kde/
>> > Twitter: https://twitter.com/kdecommunity
>
>
> --
> Promotion & Communication
>
> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
>

Re: Upcoming change to mail infrastructure

[Ben Cooksley]

On Wed, Jul 4, 2018 at 10:30 AM, Reindl Harald  wrote:
>
>
> Am 03.07.2018 um 12:29 schrieb Ben Cooksley:
>> We've recently completed configuration of a new mail server which will
>> be replacing the current system which handles kde.org mail. This
>> system will be assuming responsibility for mailing lists as well as
>> authenticated mail sending for those who require that service.
>
> did you also notice and fix the long outstanding bugzilla SPF problems
> within your own infrastructure before make checks even sharper?
>
> https://bugs.kde.org/show_bug.cgi?id=392685
>
> there are at leat *three* problems:
> * the notify mails have the envelope-sender of the reoprter
> * postbox.kde.org don't skip SPF checks from bluemchen.kde.org
> * the SPF can not match because bluemchen.kde.org is not
>   in the reporters SPF
> * finally you send backscatter-bounces for each and every
>   mail back to the reporter that the notify to the others
>   was rejected by postbox.kde.org and so reports don't get attention
> 
> * don't use reporters enevlope sender to begin with
> * don't SPF check inbound mail within the own infrastructure
> * don't backscatter to the innocent reporter
> 
> : host postbox.kde.org[46.4.96.248] said: 550
> 5.7.23 : Recipient address rejected: Message
> rejected due to: SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfrom;id=li...@rhsoft.net;ip=208.118.235.41

I'd be curious to know when you observed that, as I can find no trace
of such a message being carried by Bluemchen in recent times for that
address aside from one which was successfully delivered to you on Jun
29 at 17:14:37 UTC.

The behaviour you are describing was at one point provided by a custom
patch we had to support legacy behaviour. I'm not sure when it was
removed (my mail archives indicate it was sometime in late 2015), but
I know it did generate quite a few complaints when we did remove it.

In regards to the above points, Bugzilla has been configured to use
it's own envelope sender, bugzilla_nore...@kde.org, as evidenced by
the following log entry:

Jun 29 17:14:23 bluemchen postfix/qmgr[452]: 4EEF2100B8B:
from=, size=2457, nrcpt=1 (queue active)

and also confirmed by the following lines from mail headers on a
Bugzilla mail I received directly on June 28:

Received: from www-data by bugs.kde.org with local (Exim 4.82)
(envelope-from ) id 1fYKZ8-00035U-0m for
bcooks...@kde.org; Thu, 28 Jun 2018 00:13:38 +
From: bugzilla_nore...@kde.org
To: bcooks...@kde.org

Therefore all 3 points you've mentioned are all resolved, and have
been for some time.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Upcoming change to mail infrastructure -> SPF still broken

[Ben Cooksley]

On Wed, Jul 4, 2018 at 10:52 PM, Reindl Harald  wrote:
>
>
> Am 04.07.2018 um 12:38 schrieb Ben Cooksley:
>> On Wed, Jul 4, 2018 at 10:30 AM, Reindl Harald  
>> wrote:
>>> did you also notice and fix the long outstanding bugzilla SPF problems
>>> within your own infrastructure before make checks even sharper?
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=392685
>>>
>>> there are at leat *three* problems:
>>> * the notify mails have the envelope-sender of the reoprter
>>> * postbox.kde.org don't skip SPF checks from bluemchen.kde.org
>>> * the SPF can not match because bluemchen.kde.org is not
>>>   in the reporters SPF
>>> * finally you send backscatter-bounces for each and every
>>>   mail back to the reporter that the notify to the others
>>>   was rejected by postbox.kde.org and so reports don't get attention
>>> 
>>> * don't use reporters enevlope sender to begin with
>>> * don't SPF check inbound mail within the own infrastructure
>>> * don't backscatter to the innocent reporter
>>> 
>>> : host postbox.kde.org[46.4.96.248] said: 550
>>> 5.7.23 : Recipient address rejected: Message
>>> rejected due to: SPF fail - not authorized. Please see
>>> http://www.openspf.net/Why?s=mfrom;id=li...@rhsoft.net;ip=208.118.235.41
>>
>> I'd be curious to know when you observed that, as I can find no trace
>> of such a message being carried by Bluemchen in recent times for that
>> address aside from one which was successfully delivered to you on Jun
>> 29 at 17:14:37 UTC
>
> NOW!
>
> https://bugs.kde.org/show_bug.cgi?id=392685#c1

Please refrain from further use of exclamation marks, as it isn't
helping matters.

Also, note that you've never reported this issue in the past, so from
my perspective this is entirely new, regardless of how it may be known
from your side (and your bug report was posted less than 24 hours ago)

>
> "such a message being carried by Bluemchen in recent times for that
> address aside from one which was successfully delivered to you on Jun 29
> at 17:14:37 UTC" - yeah - when somebody *else* makes a comment i get
> that notify but when i write a brugreport or comment a get that damned
> backscatters below

I've checked our logs and have identified a bug in Bugzilla which is
responsible for this issue, and believe I now have the appropriate
information now to reproduce and resolve the issue. Due to the nature
of the issue it may take a few days before we can deploy a fix for
this problem.

This bug only affects a very limited number of users on our
installation of Bugzilla. As this issue already exists, and won't be
changed by the switch to Letterbox this issue will be treated
separately and won't prevent us from initiating the switchover to
Letterbox.

Regards,
Ben Cooksley
KDE Sysadmin

>
>  Weitergeleitete Nachricht 
> Betreff: Undelivered Mail Returned to Sender
> Datum: Wed,  4 Jul 2018 06:47:52 -0400 (EDT)
> Von: Mail Delivery System 
> An: li...@rhsoft.net
>
> This is the mail system at host bluemchen.kde.org.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>The mail system
>
> : host postbox.kde.org[2a01:4f8:140:8302::4] said: 550
> 5.7.23 : Recipient address rejected: Message rejected
> due to: SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfrom;id=li...@rhsoft.net
> ip=2001:4830:134:8::100;r= (in reply to RCPT TO command)
>
>
>  Weitergeleitete Nachricht 
> Betreff: Undelivered Mail Returned to Sender
> Datum: Wed,  4 Jul 2018 06:47:52 -0400 (EDT)
> Von: Mail Delivery System 
> An: li...@rhsoft.net
>
> This is the mail system at host bluemchen.kde.org.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
>The mail system
>
> : host postbox.kde.org[2a01:4f8:140:8302::4] said: 550
> 5.7.23 : Recipient address rejected: Message rejected
> due to: SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfrom;id=li...@rhsoft.net;ip=2001:4830:

Re: Upcoming change to mail infrastructure -> SPF still broken

[Ben Cooksley]

On Thu, 5 Jul 2018, 02:09 Reindl Harald,  wrote:

>
> Am 04.07.2018 um 15:31 schrieb Luca Beltrame:
> > Il giorno Wed, 4 Jul 2018 14:45:00 +0200 Reindl Harald
> >  ha scritto:
> >
> >> https://bugs.kde.org/show_bug.cgi?id=392685 2018-04-03 18:45:47
> >> UTC
> >
> > For the record, Sysadmin tickets should be filed through
> > Phabricator (https://go.kde.org/systickets) rather than Bugzilla:
> > this makes sure that they won't get lost.
>

For the record, this subthread should now be considered closed, as the
issue has been located and work is underway to correct it.


> and how do you imagine that for *users* like me which just reading teh
> devel-list and have no access with their bugzilla credentials there?
>
> and even if i can register at https://identity.kde.org/ please make a
> reality check how likely it is that people register here and there and
> there too just to report a bug in KDE software in a way it's recognized
>

You are reporting an issue in our Infrastructure, which is quite different
to our software (and also an internal issue) hence why it is managed on
Phabricator.


> > (Bugzilla is still used for KDE software - this is for
> > Sysadmin-related stuff)
>
> that's why "bugs.kde.org" is in the product dropdown i guess - if
> someone would take a look at new bugreports and be it only the
> subjects this one would have been seen within 24 hours and internally
> handed to the right group
>

That is a legacy product, dating back to before we had Phabricator (and
when we had a dedicated Bugzilla maintainer...)


> -
>
> if this contains one of my own machines i see the mistake not
> configure "mynetworks" in /etc/postfix/main.cf proper within 24 hours
> because i did "man grep", "man cron" and "man bash"
>
> 1   Jun 26 09:45:42 mail-gw postfix/smtpd[636481]: NOQUEUE: reject:
> RCPT from mailnet.top[5.79.119.167]: 550 5.7.23
> : Recipient address rejected: Message
> rejected due to: SPF fail - not authorized. Please see
> http://www.openspf.net/Why?s=mfrom;id=webmaster@mailnet.
> top;ip=5.79.119.167;r=contai...@thelounge.net;
> from= to= proto=ESMTP
> helo=
>

In regards to the above, Bluemchen is our transactional mail gateway,
responsible for handling all the mail from Bugzilla, Forum and Wiki
notifications, Identity account registrations and the like.

As such Bluemchen is responsible for its own mail delivery, for both KDE
Sysadmin operated and other domains.
Due to the nature of its role, it should only ever be sending as @KDE.org
(and is authorised to do so in our SPF records). The fact that it isn't is
due to a bug in software we use, which we are in the process of fixing.

Therefore from my perspective everything is configured correctly, as
Bluemchen is external as far as Postbox (and Letterbox) are concerned.

Regards,
Ben Cooksley
KDE Sysadmin

>

Mail system switchover complete

[Ben Cooksley]

Hi everyone,

I'm happy to announce that our transition from our old mail system
(Postbox) to our new mail system (Letterbox) has been made
successfully.

The transition was made with minimal impact on service as far as we
can tell, aside from a slight delay in mail delivery as the DNS change
propagated. At this time all major providers appear to have picked up
this change and are now delivering to Letterbox successfully.

As part of this changeover, we started from scratch with our Bayesian
database. While initial training has been completed and appears to be
operating well, further tuning will take place over the coming week.
Mailing list moderators who see an increase in spam volume should
please leave that spam in the moderation queue and contact Sysadmin so
we can train the filter with it.

At this time the only degradation in service is for Yahoo users, who
may experience a delay in mail being delivered for the next few days
while our new IP address is "warmed up" in their reputation databases.
Once this is completed they should receive mail again as normal. No
mail will be lost as a result of this. This condition was expected
(and occurred when we migrated from KTown to Postbox)

We'd like to thank Bytemark (bytemark.co.uk) for sponsoring the
Letterbox server.

Should anyone have any queries regarding the status of the system,
please contact sysad...@kde.org, or file a Sysadmin ticket.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: KDE Frameworks 5.48.0 released

[Ben Cooksley]

On Sun, Jul 15, 2018 at 2:28 AM, Roman Collins  wrote:
> There's no unsubscribe links, please fix that

Hi Roman,

I'm afraid due to the propagation of standards such as DKIM and DMARC,
it is impossible for us to add unsubscribe links to the body of emails
sent through our mailing lists. We still add RFC standard List-*
headers to emails, which all decent mail clients (including GMail
itself) will use to offer the user the option to unsubscribe.

If we were to enable the Mailman functionality that added unsubscribe
links to the footer of our emails, then the DKIM signatures of those
emails would be broken.

If we were to break these signatures, members of our community would
be deprived of their ability to participate on our lists as some mail
providers reject mail which has broken DKIM signatures or which fail
DMARC validation. Using GMail as an example, they deliver all mail
that fails DMARC validation to the Spam folder regardless of any other
characteristics it has (and around 50% of all mail we deliver goes to
GMail, so their policies are what we'll follow above all else).

Should you wish to unsubscribe from our lists, you can either send an
email to -unsubscr...@kde.org or visit
https://mail.kde.org/mailman/options/ and follow the prompts
there. This information is also included in the RFC standard
List-Unsubscribe header, contained in all emails you've received from
our lists.

Regards,
Ben Cooksley
KDE Sysadmin

>
> On Sat, Jul 14, 2018, 5:37 AM David Faure  wrote:
>>
>> 14th July 2018. KDE today announces the release of KDE Frameworks 5.48.0.
>>
>> KDE Frameworks are 78 addon libraries to Qt which provide a wide variety
>> of·
>> commonly needed functionality in mature, peer reviewed and well tested·
>> libraries with friendly licensing terms. For an introduction see the·
>> Frameworks 5.0 release announcement.
>>
>>
>> Attica
>>
>>   Port remaining uses of qDebug() to qcDebug(ATTICA)
>>   Fix checking invalid provider url
>>   Fix broken url to API specification
>>
>> Baloo
>>
>>   Remove unused entry X-KDE-DBus-ModuleName from the kded plugin metadata
>>   [tags_kio] The url query should be a key-value pair
>>   The power state signal should only be emitted when the power state
>> changes
>>   baloodb: Make changes to cmdline arg description after rename prune ->
>> clean
>>   Clearly show duplicate filenames in tag folders
>>
>> BluezQt
>>
>>   Update D-Bus xml files to use "Out*" for signal type Qt annotations
>>   Add signal for devices's address changing
>>
>> Breeze Icons
>>
>>   Use the broom-style icon for edit-clear-all too
>>   Use a broom-style icon for edit-clear-history
>>   change 24px view-media-artist icon
>>
>> Extra CMake Modules
>>
>>   Android: Make it possible to override a target's APK directory
>>   Drop outdated QT_USE_FAST_OPERATOR_PLUS
>>   Add -Wlogical-op -Wzero-as-null-pointer-constant to KF5 warnings
>>   [ECMGenerateHeaders] Add option for other header file extension than .h
>>   Don't include a 64 when building 64bit architectures on flatpak
>>
>> KActivitiesStats
>>
>>   Fix off by one error in Cache::clear (bug 396175)
>>   Fix ResultModel item moving (bug 396102)
>>
>> KCompletion
>>
>>   Remove unneeded moc include
>>   Make sure KLineEdit::clearButtonClicked is emitted
>>
>> KCoreAddons
>>
>>   Remove QT definitions duplicated from KDEFrameworkCompilerSettings
>>   Make sure that it compiles with strict compile flags
>>   Remove unused key X-KDE-DBus-ModuleName from test servicetype metadata
>>
>> KCrash
>>
>>   Reduce QT_DISABLE_DEPRECATED_BEFORE to minimum dep of Qt
>>   Remove QT definitions duplicated from KDEFrameworkCompilerSettings
>>   Make sure to build with strict compile flags
>>
>> KDeclarative
>>
>>   check the node actually has a valid texture (bug 395554)
>>
>> KDED
>>
>>   KDEDModule servicetype definition: remove unused key
>> X-KDE-DBus-ModuleName
>>
>> KDELibs 4 Support
>>
>>   Set QT_USE_FAST_OPERATOR_PLUS ourselves
>>   Don't export kf5-config to the CMake config file
>>   Remove unused entry X-KDE-DBus-ModuleName from the kded plugin metadata
>>
>> KDE WebKit
>>
>>   Port KRun::runUrl() & KRun::run() to undeprecated API
>>   Port KIO::Job::ui() -> KIO::Job::uiDelegate()
>>
>> KFileMetaData
>>
>>   Avoid compiler warnings for taglib headers
>>   PopplerExtractor: use directly QByteArray() args instead of 0 pointers
>>   t

Re: Limiting who can create v${NUMBER}.${NUMBER}.${NUMBER} tags in KDE Applications git repos

[Ben Cooksley]

Hi all,

Given that no objection has been raised to this, I have now implemented this.
All repositories in Frameworks, KDE Applications and Plasma can now
only have tags starting with the convention of vN. modified by their
respective release managers.

This has been implemented using a whitelist of release manager account
names, which is the same system we use for controlling access to
website and sysadmin repositories.

While GPG was suggested as one option, we would have to maintain a
whitelist anyway as well as maintain additional GPG code which seemed
unnecessary given their identity has already been authenticated via
their SSH Keys.

Cheers,
Ben

Upcoming reorganisation of the CI system

[Ben Cooksley]

Hi all,

Currently CI jobs are all created within a flat namespace, meaning
that it is quite difficult to view the overall status of an individual
project. Additionally, it creates the issue that the main default view
can take a significant amount of time to load.

To resolve this we intend to shift everything within Folders in
Jenkins. These folders will be structured in the form of Product /
Project / 

If this creates issues for anyone, or if anyone has any questions
regarding this, please let me know.

At this stage it is intended that we will keep all build history for
jobs on the system (although downtime will be needed in order to allow
for the changeover).

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Upcoming reorganisation of the CI system

[Ben Cooksley]

On Tue, 14 Aug 2018, 17:09 Christoph Feck,  wrote:

> On 14.08.2018 15:03, Ben Cooksley wrote:
> > Currently CI jobs are all created within a flat namespace, meaning
> > that it is quite difficult to view the overall status of an individual
> > project. Additionally, it creates the issue that the main default view
> > can take a significant amount of time to load.
> >
> > To resolve this we intend to shift everything within Folders in
> > Jenkins. These folders will be structured in the form of Product /
> > Project / 
>
> Will we still be able to see the status of all Applications (or all
> Frameworks) without clicking hundreds of subfolders? This is useful to
> get an overview before doing releases.
>

Yes, with a recursive view this will still be possible - it just won't be
the default landing page.


> Christoph Feck
>

Cheers,
Ben

>

Re: Upcoming reorganisation of the CI system

[Ben Cooksley]

Hi all,

Final call for objections or queries for this change - i'll be looking
to roll this out this weekend.

Note: Plasma and KDevelop, i'm not subscribed to your lists so please
ensure i'm in CC for any responses.

Cheers,
Ben

Re: Upcoming reorganisation of the CI system

[Ben Cooksley]

On Wed, Aug 22, 2018 at 2:36 AM Morten Volden  wrote:
>
> Hi Ben

Hi Morten,

>
> I don't know if this is on you radar or not, but here goes.
>
> I have noticed that quite a few of the KDevelop unittests are failing on the 
> Windows CI.
>
> Running the tests locally they work fine.
>
> If I look at the output of the failing tests it is similar to that pasted 
> below.
>
> Searching brought me to this page:
>
> https://stackoverflow.com/questions/43897167/does-qt-build-with-opengl-angle-fix-support-for-windows-clients-not-having-openg/43932575#43932575
>
> Which seem to suggest that (re) install DirectX End-User Runtimes (June 
> 2010).should fix the issues.
>
> Since people will be giving the servers some TLC in the near future I thought 
> it might be worth looking at.

I suspect in this instance the problem may be caused by the KVM QXL
drivers that we're reliant on to serve as the system graphics.
Any ideas as to whether this might be the case or not?

As part of the system setup we have to install the DirectX SDK for
some components so I would have expected that it took care of
installing all the necessary runtime components as well.

>
> Kind Regards
>
> Morten

Cheers,
Ben

>
>
> qt.qpa.input.tablet: Tablet support:  "None"
> qt.qpa.windows: QWindowsContext::setProcessDpiAwareness 2
> SetProcessDpiAwareness(2) failed: COM error 0x80070005 E_ACCESSDENIED 
> (Unknown error 0x080070005), using 2
> qt.qpa.windows: QWindowsIntegrationPrivate::QWindowsIntegrationPrivate 
> DpiAwareness= 2 effective process DPI awareness= 2
> qt.qpa.windows: QWindowsContext::registerWindowClass "Qt5ClipboardView" 
> style=0x0 brush=0x0 icon=false atom=49400
> qt.qpa.mime: QWindowsClipboard::registerViewer m_clipboardViewer: 0xede04e8 
> format listener: true next: 0x0
> qt.qpa.windows: New Monitor:  Screen "WinDisc" 1024x768+0+0 avail: 
> 1024x768+0+0 physical: -1x-1 DPI: 96x96 Depth: 32 Format: 6 hMonitor: 0x10001 
> primary virtual desktop lock screen
> qt.qpa.fonts: QWindowsFontDatabase::systemDefaultFont QFont( "MS Shell Dlg 
> 2,8.25,-1,5,50,0,0,0,0,0" )
> qt.qpa.windows: QWindowsTheme::refreshIconPixmapSizes (QSize(16, 16), 
> QSize(32, 32), QSize(48, 48), QSize(256, 256))
> qt.qpa.gl: QWindowsIntegration::createPlatformOpenGLContext 
> QSurfaceFormat(version 2.0, options QFlags(), 
> depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, 
> alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior 
> QSurfaceFormat::SwapBehavior(DefaultSwapBehavior), swapInterval 1, colorSpace 
> QSurfaceFormat::ColorSpace(DefaultColorSpace), profile  
> QSurfaceFormat::OpenGLContextProfile(NoProfile))
> qt.qpa.gl: Basic wglCreateContext gives version 1.1
> qt.qpa.gl: OpenGL version too low
> qt.qpa.gl: OpenGL 2.0 entry points not found
> qt.qpa.gl: GPU features: QSet("disable_d3d11", "disable_desktopgl", 
> "disable_d3d9")
> qt.qpa.gl: Disabling Desktop GL:  GpuDescription(vendorId=0x0, deviceId=0x0, 
> subSysId=0x0, revision=0, driver: "", version=, "")
> qt.qpa.gl: Disabling D3D11:  GpuDescription(vendorId=0x0, deviceId=0x0, 
> subSysId=0x0, revision=0, driver: "", version=, "")
> qt.qpa.gl: Disabling D3D9:  GpuDescription(vendorId=0x0, deviceId=0x0, 
> subSysId=0x0, revision=0, driver: "", version=, "")
> qt.qpa.gl: QWindowsOpenGLTester::supportedRenderers 
> GpuDescription(vendorId=0x0, deviceId=0x0, subSysId=0x0, revision=0, driver: 
> "", version=, "") renderer:  QFlags(0x8|0x20)
> qt.qpa.gl: Qt: Using EGL from libEGLd
> qt.qpa.gl: Qt: Using OpenGL ES 2.0 from libGLESv2d
> qt.qpa.gl: QWindowsEGLStaticContext::create Created EGL display 0x1e5631fcd80 
> v 1 . 4
>
>
>
>
> Den tir. 21. aug. 2018 kl. 17.27 skrev Ben Cooksley :
>>
>> Hi all,
>>
>> Final call for objections or queries for this change - i'll be looking
>> to roll this out this weekend.
>>
>> Note: Plasma and KDevelop, i'm not subscribed to your lists so please
>> ensure i'm in CC for any responses.
>>
>> Cheers,
>> Ben
>
>
>
> --
> Regards / Med venlig hilsen
>
> Morten Danielsen Volden
> Software Developer
> M.Sc. EE

CI System Reorganisation

[Ben Cooksley]

Hi all,

As a followup to my earlier mail sent about 3 weeks ago, i've now
transitioned all builds on the CI system over to the folder layout
previously described.

Builds can now be found in folders following the following structure
on Jenkins:
 / 

For those with access to run DSL Scripts: Please do not run them.
While I have completed the necessary adaptions to them, I have yet to
test them and would like to have a full backup of the current state of
Jenkins before I proceed with doing so (due to the colossal number of
files and data involved, this takes quite a bit of time)

When the DSL Job is run the views I mentioned previously, which will
provide recursive overviews for those who prefer those, will become
available.

If anyone encounters any issues please let us know.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: CI System Reorganisation

[Ben Cooksley]

On Mon, 10 Sep 2018, 01:17 Christoph Feck,  wrote:

> On 09.09.2018 10:59, Ben Cooksley wrote:
> > As a followup to my earlier mail sent about 3 weeks ago, i've now
> > transitioned all builds on the CI system over to the folder layout
> > previously described.
> >
> > Builds can now be found in folders following the following structure
> > on Jenkins:
> >  / 
>
> How I can view all of "stable" Applications on a single page? I remember
> I asked if it would still be possible after the change, but I cannot see
> a filter or link to get an overview of all builds.
>

These views will come available when the DSL Job is run. It hasn't been run
yet as I want a full backup of the current state of Jenkins before I do so,
in the event something goes wrong.

Cheers,
Ben


> Christoph Feck
>

Emergency downtime notice

[Ben Cooksley]

Hi all,

We've just received notice that both disks in the server hosting
Phabricator, along with our Git and Subversion repositories have
failed their SMART self-assessment tests.

I have now requested replacement of one of those disks, and once the
array has been rebuilt will request the second be replaced.

To preserve our data in the meantime I have shutdown the container
hosting Phabricator/Git/Subversion, so they will be unavailable for
the next few hours.

My apologies for the inconvenience.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Emergency downtime notice

[Ben Cooksley]

On Wed, Oct 10, 2018 at 8:51 PM Ben Cooksley  wrote:
>
> Hi all,
>
> We've just received notice that both disks in the server hosting
> Phabricator, along with our Git and Subversion repositories have
> failed their SMART self-assessment tests.
>
> I have now requested replacement of one of those disks, and once the
> array has been rebuilt will request the second be replaced.
>
> To preserve our data in the meantime I have shutdown the container
> hosting Phabricator/Git/Subversion, so they will be unavailable for
> the next few hours.

As an update, one disk has now been exchanged and the array has been
synced to the new disk.
I have now asked for replacement of the second disk and will advise
once it has been replaced.

>
> My apologies for the inconvenience.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Thanks,
Ben

Re: Emergency downtime notice

[Ben Cooksley]

On Wed, Oct 10, 2018 at 9:35 PM Ben Cooksley  wrote:
>
> On Wed, Oct 10, 2018 at 8:51 PM Ben Cooksley  wrote:
> >
> > Hi all,
> >
> > We've just received notice that both disks in the server hosting
> > Phabricator, along with our Git and Subversion repositories have
> > failed their SMART self-assessment tests.
> >
> > I have now requested replacement of one of those disks, and once the
> > array has been rebuilt will request the second be replaced.
> >
> > To preserve our data in the meantime I have shutdown the container
> > hosting Phabricator/Git/Subversion, so they will be unavailable for
> > the next few hours.
>
> As an update, one disk has now been exchanged and the array has been
> synced to the new disk.
> I have now asked for replacement of the second disk and will advise
> once it has been replaced.

The second disk has now been replaced and the array is fully synced again.

Normal service has now resumed for both Phabricator as well as SCM
Hosting (Git and SVN)

>
> >
> > My apologies for the inconvenience.
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
>
> Thanks,
> Ben

Cheers,
Ben

Downtime announcement: www.kde.org

[Ben Cooksley]

Hi all,

In order to allow for hardware maintenance, one of our physical
hardware hosts will need to be shutdown for a few hours on Monday.
This downtime will commence around 9:30am UTC and may take several
hours.

During this time a number of sites will be inaccessible, including:
- www.kde.org
- autoconfig.kde.org
- docs.kde.org
- ev.kde.org
- freebsd.kde.org
- hig.kde.org
- kdesrc-build.kde.org
- neon.kde.org
- releases.neon.kde.org
- networkcheck.kde.org
- planet.kde.org

Other websites within KDE.org that are dependent on resources hosted
on those sites may also experience delayed loading times in browsers
during this window.

As some of these sites are relied upon by applications to function
properly, those applications may experience degraded functionality
during this time.

Affected applications include:
- Discover
- Kaffeine
- Kopete
- Plasma Network Manager (when behind a captive portal)
- Any application using GHNS

In addition, any other site which is hosted by the server known as
"olios.kde.org" will also be unavailable during this time.

Apologies for any inconvenience caused.

Regards,
Ben Cooksley
KDE Sysadmin

Re: Downtime announcement: www.kde.org

[Ben Cooksley]

On Sat, Nov 3, 2018 at 7:50 AM Ben Cooksley  wrote:
>
> Hi all,

Hi all,

>
> In order to allow for hardware maintenance, one of our physical
> hardware hosts will need to be shutdown for a few hours on Monday.
> This downtime will commence around 9:30am UTC and may take several
> hours.
>
> During this time a number of sites will be inaccessible, including:
> - www.kde.org
> - autoconfig.kde.org
> - docs.kde.org
> - ev.kde.org
> - freebsd.kde.org
> - hig.kde.org
> - kdesrc-build.kde.org
> - neon.kde.org
> - releases.neon.kde.org
> - networkcheck.kde.org
> - planet.kde.org
>
> Other websites within KDE.org that are dependent on resources hosted
> on those sites may also experience delayed loading times in browsers
> during this window.
>
> As some of these sites are relied upon by applications to function
> properly, those applications may experience degraded functionality
> during this time.
>
> Affected applications include:
> - Discover
> - Kaffeine
> - Kopete
> - Plasma Network Manager (when behind a captive portal)
> - Any application using GHNS
>
> In addition, any other site which is hosted by the server known as
> "olios.kde.org" will also be unavailable during this time.
>
> Apologies for any inconvenience caused.

The maintenance window has now commenced.
The above sites will be inaccessible until the maintenance is completed.

>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Regards,
Ben

Re: TechEvent Telegram Channel

[Ben Cooksley]

Hi all,

The sender of these messages has now been removed from both this, and
all other KDE.org mailing lists (they sent it elsewhere for those not
subscribed to other affected lists)

Regards,
Ben

Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

Hi all,

I've been informed by the PIM developers that they would like to bump
the dependency of the Qt version they use, from Qt 5.9 which it's on
currently, to Qt 5.10.

As a consequence, due to many KDE projects using PIM libraries, their
dependency on Qt will also be effectively bumped. To minimize the
maintenance cost of this bump for the CI system, I would like to bump
everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end
up chasing down build failures for a long time)

As most distributions have moved on from 5.10, and use Qt 5.11 now
(and will in many cases soon move to Qt 5.12), i'd like to suggest
that instead of going to Qt 5.10, we move straight to 5.11.

Because Frameworks has a two versions prior support policy, it'll
remain on 5.9 for now until it's ready to move up to 5.10 (assuming
5.12 is a usable Qt version)

If nobody has any objections, i'll proceed with this change in around
3 days time.

Cheers,
Ben

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

On Mon, Dec 3, 2018 at 10:31 PM René J.V. Bertin  wrote:
>
> Hi,
>
> Can't you just configure the CI to use Qt 5.10? I think it's not good to 
> hardcode an "overzealous" (for lack of a better word) Qt version in projects 
> that don't require them AND I think that one should support the current LTS 
> release in as many projects as possible as a general rule of principle.

Not really, because it won't be long before 5.10 is no longer any of
the current mainstream distributions.

>
> There's a reason why those LTS releases exist and that should probably be 
> taken into consideration ESPECIALLY for the KF5 Frameworks (remember why 
> kdelibs4 was split up)!

As mentioned in my mail, this applies to everything but Frameworks.
It doesn't affect Frameworks - which will continue on Qt 5.9 at this stage.

>
> People working only on Linux may not realise it but even Qt 5.9 already 
> dropped support for Mac OS versions that are still widely used.
>
> IMHO, projects that use PIM libraries can decide for themselves how they want 
> to deal with a Qt minimum version bump in those dependencies, while 
> distribution maintainers *could* decide to keep those (and only those) 
> dependencies on an earlier version in order to keep supporting whatever 
> oldest Qt requirement they have (5.9 for my MacPorts packaging). Also, don't 
> of those projects have only optional dependencies on PIM libraries?

For some it's mandatory.

>
> I tend to see a CI as something that tests software on one or a handful of 
> the most common configurations. Anyone not using such a configuration is 
> either on their own or acting as a kind of additional CI.
>
> Bumping the minimum Qt version across the line would decrease the burden on 
> the CI, but probably increase the burden on distributions, or force them to 
> stop following upgrades earlier than justified.
>
> Also:
> > (otherwise we'll end up chasing down build failures for a long time)
>
> How so? If you want to install project B that requires Qt 5.9+ but also uses 
> PIM library A which requires Qt 5.1x you're going to need to install 
> something newer than Qt 5.9 . What kind of build failures we cannot already 
> get ("B requires PIM library A which is not installed") are you expecting?

The CI system has no way of knowing what a project says it requires.
It relies on it's own configuration files to dictate what jobs are
generated, and those jobs in turn determine what platform they're run
on.

What i'm referring to here is the manual process of having to go and
exclude various projects which do use PIM libraries (the CI system
doesn't have a concept of optional, it's either needed or not present
at all). The only way to do this will be by hunting through the
dependency graph, which is easier said than done (because Application
A uses library B which uses library C which in turn uses PIM library
D)

Individual project failures might not seem too bad, apart from the
fact it's me (or one of the handful of people familiar with the CI
system configuration) who will have to update the configuration for
many projects (which will result in either lots of Sysadmin tickets,
or a ton of various people spending time hunting these issues down).

Note that in order for the CI system to operate properly the
"Dependency Build" jobs need to be able to run successfully (otherwise
you'll have missing dependencies when you go to run a build). In most
cases it won't be jobs themselves that fail, it'll be the Dependency
Build jobs - and because these jobs start from scratch (ECM, then up
through Frameworks and so on until every project's dependencies have
been built) it's extremely expensive to keep running these jobs as
they occupy builders for quite a bit of time.

> There could be errors from *other* projects not depending on PIM libraries, 
> but if they intend to support an "older" Qt version that implies rather 
> explicitly that they also intend to address build failures, no?
>

We see those on a semi-regular basis - as those who have seen QtTest
casting issues will be well aware.

>
> R.

Cheers,
Ben

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

On Tue, Dec 4, 2018 at 9:45 AM Elvis Angelaccio
 wrote:
>
>
>
> On 03/12/18 09:46, Ben Cooksley wrote:
> > Hi all,
>
> Hi Ben

Hi Elvis,

>
> >
> > I've been informed by the PIM developers that they would like to bump
> > the dependency of the Qt version they use, from Qt 5.9 which it's on
> > currently, to Qt 5.10.
> >
> > As a consequence, due to many KDE projects using PIM libraries, their
> > dependency on Qt will also be effectively bumped. To minimize the
> > maintenance cost of this bump for the CI system, I would like to bump
> > everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end
> > up chasing down build failures for a long time)
>
> It's not clear if you are suggesting to bump the minimum required Qt
> version in each CMakeLists.txt file, or if you are just going to bump
> the Qt version used by the CI server.
>
> Could you please clarify? Thanks!

I'll only be bumping the version used by the CI system, the
applications themselves will be left unchanged.

>
> >
> > As most distributions have moved on from 5.10, and use Qt 5.11 now
> > (and will in many cases soon move to Qt 5.12), i'd like to suggest
> > that instead of going to Qt 5.10, we move straight to 5.11.
> >
> > Because Frameworks has a two versions prior support policy, it'll
> > remain on 5.9 for now until it's ready to move up to 5.10 (assuming
> > 5.12 is a usable Qt version)
> >
> > If nobody has any objections, i'll proceed with this change in around
> > 3 days time.
> >
> > Cheers,
> > Ben
> >
>
> Cheers,
> Elvis

Cheers,
Ben

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid  wrote:
>
> El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va 
> escriure:
> > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote:
> > > Can't you just configure the CI to use Qt 5.10? I think it's not good to
> > > hardcode an "overzealous" (for lack of a better word) Qt version in
> > > projects that don't require them AND I think that one should support the
> > > current LTS release in as many projects as possible as a general rule of
> > > principle.
> > >
> > > There's a reason why those LTS releases exist and that should probably be
> > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember why
> > > kdelibs4 was split up)!
> >
> > Which is exactly why 5.11.3 (released today) should be picked. It contains 
> > all
> > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to
> > 5.10.1 means regressing all those fixes.
>
> It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10.
>
> Of course users should be using 5.11.3, but that's a different story.

So you'd prefer we move to Qt 5.10 then, and then do another move to
5.11 when Frameworks moves it's bar up?

>
> Cheers,
>   Albert
>
>

Regards,
Ben

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

[Ben Cooksley]

On Wed, Dec 5, 2018 at 8:18 AM Albert Astals Cid  wrote:
>
> El dimarts, 4 de desembre de 2018, a les 20:13:43 CET, Ben Cooksley va 
> escriure:
> > On Wed, Dec 5, 2018 at 7:22 AM Albert Astals Cid  wrote:
> > >
> > > El dimarts, 4 de desembre de 2018, a les 18:10:44 CET, Thiago Macieira va 
> > > escriure:
> > > > On Monday, 3 December 2018 01:30:25 PST René J.V. Bertin wrote:
> > > > > Can't you just configure the CI to use Qt 5.10? I think it's not good 
> > > > > to
> > > > > hardcode an "overzealous" (for lack of a better word) Qt version in
> > > > > projects that don't require them AND I think that one should support 
> > > > > the
> > > > > current LTS release in as many projects as possible as a general rule 
> > > > > of
> > > > > principle.
> > > > >
> > > > > There's a reason why those LTS releases exist and that should 
> > > > > probably be
> > > > > taken into consideration ESPECIALLY for the KF5 Frameworks (remember 
> > > > > why
> > > > > kdelibs4 was split up)!
> > > >
> > > > Which is exactly why 5.11.3 (released today) should be picked. It 
> > > > contains all
> > > > fixes that 5.9.7 contains, whereas 5.10.1 does not. Moving from 5.9.7 to
> > > > 5.10.1 means regressing all those fixes.
> > >
> > > It doesn't matter, apps need 5.10 to compile, so CI needs to use 5.10.
> > >
> > > Of course users should be using 5.11.3, but that's a different story.
> >
> > So you'd prefer we move to Qt 5.10 then, and then do another move to
> > 5.11 when Frameworks moves it's bar up?
>
> Personally, yes, it's much easier to detect apps requiring 5.11 API when they 
> don't pretend to (not sure there's much new api in 5.11 but anyhow). I mean 
> in an ideal world we'd compile each app with their required min Qt version to 
> detect those things, but since that's not possible with the current setup 
> let's settle for the smallest possible version.

Fair enough.

>
> And Frameworks requiring 5.11 is still kind of far no?

That will happen once Qt 5.13 starts to come up for release?

As we have no choice in regards to the bump to 5.10 (because PIM will
be forcing the issue) i've started the process now of moving all of
Applications, Extragear, Calligra and KDevelop over to 5.10 for Linux
builds.

>
> Cheers,
>   Albert

Regards,
Ben

>
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > >
> >
> > Regards,
> > Ben
>
>
>
>

CI system disruption

[Ben Cooksley]

Hi all,

Due to a massive translation change which took place in the last 24
hours, the CI system is currently in the process of rebuilding the
whole of KDE for all the platforms it covers (both branch sets)

This is a process that has already been underway for several hours,
and at this stage is expected to take several more. Normal CI service
will unfortunately be unavailable until this completes.

Unfortunately, as a matter of bad timing, the network card in one of
the main CI builders has also glitched and as a consequence is now
intermittent from time to time. This is causing various builds to fail
as a result. Those builds that do fail will be restarted by Sysadmin
once these issues have been corrected.

The translation team which made the change in question has been
requested to contact Sysadmin regarding the large change and it's
nature.

Apologies for any inconvenience caused.

Regards,
Ben Cooksley
KDE Sysadmin

Re: CI system disruption

[Ben Cooksley]

On Sun, Jan 6, 2019 at 10:14 PM Ben Cooksley  wrote:
>
> Hi all,

Hi everyone,

>
> Due to a massive translation change which took place in the last 24
> hours, the CI system is currently in the process of rebuilding the
> whole of KDE for all the platforms it covers (both branch sets)
>
> This is a process that has already been underway for several hours,
> and at this stage is expected to take several more. Normal CI service
> will unfortunately be unavailable until this completes.
>
> Unfortunately, as a matter of bad timing, the network card in one of
> the main CI builders has also glitched and as a consequence is now
> intermittent from time to time. This is causing various builds to fail
> as a result. Those builds that do fail will be restarted by Sysadmin
> once these issues have been corrected.

The CI system has over the past few hours finished making it's way
through all of the builds, and the CI builder with networking issues
has now had it's issue fixed.
All of the impacted builds have now been restarted and look to be
finishing successfully at this stage.

>
> The translation team which made the change in question has been
> requested to contact Sysadmin regarding the large change and it's
> nature.
>
> Apologies for any inconvenience caused.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin

Cheers,
Ben

Bugzilla Server Move

[Ben Cooksley]

Hi all,

We've just completed the migration of Bugzilla from a previous system
to a newer system. While this hasn't changed Bugzilla itself much, it
did involve an update from Ubuntu 14.04 to Ubuntu 18.04.

>From our testing everything appears to be operating correctly.

Should anyone see anything unusual or broken, please let Sysadmin know.

Thanks,
Ben

Upcoming Service Downtime

[Ben Cooksley]

Hi all,

Sysadmin is currently in the process of planning server migrations for
a large number of services which have significant visibility, and
which are often substantially involved in the release process for
projects as well as general community operation.

As it may take several hours to perform these migrations, we are
asking people to please let us know when they are planning to do
things for the next month or so to allow us to schedule the migrations
accordingly. Each migration will be done separately in turn (this
won't be an all at once exercise).

The affected services include:
- All CMS sites (dot.kde.org, krita.org, akademy.kde.org, labplot.kde.org, etc)
- All Wikis (userbase, techbase, community, etc)
- All CiviCRM instances
- Forum
- Nextcloud instance (share.kde.org)
- Content distributions networks (download.kde.org, files.kde.org, etc)
- Realtime chat services (Jabber, IRC bots such as pursuivant and sKreamer, BNC)
- Event management services (events.kde.org, conf.kde.org,
reimbursements.kde.org)

Should anyone have any questions regarding this, please let us know.

Thanks,
Ben

Re: Request from Finland

[Ben Cooksley]

On Sun, Jan 13, 2019 at 10:09 AM Valorie Zimmerman
 wrote:
>
>
> Hi all, is there a better list for this inquiry? If so, please forward it 
> there.

Hi Edward,

In order to best assist here, it would be nice to know which operating
system the students are running on their laptops.
Based on it not already being available, I suspect they're using
either Windows or macOS?

>
> Valorie

Cheers,
Ben

>
> -- Forwarded message -
> From: edward krogius 
> Date: Sat, Jan 12, 2019 at 9:04 AM
> Subject: Request from Finland
> To: 
>
> Hello !
>
> In Finland the upper secondary
> national examination board
> provides an exam with KDEutilities
> KCalc calculator. Now there is a
> demand among students to
> get a standalone version of the
> calculator to run on their laptop
> operating systems.
>
> How can we get that to work?
>
> STEM teacher
> Edward Krogius
> edward.krog...@eduvantaa.fi

Re: Troubles with icon themes

[Ben Cooksley]

On Wed, Jan 23, 2019 at 4:48 PM Jonathan Schultz  wrote:
>
> Hello KDE developers,

Hi Jonathan,

>
> I wonder if someone can help me work out what is going on here.
>
> I have build some KDE applications (konsole and okular) from source using 
> kdesrc-build, using QT5 version 5.11.3 also built from sources. The 
> applications build and run, but do not load the icons used in the UI. I have 
> the following lines in ~/.config/kdeglobals:
>
> > [Icons]
> > Theme=oxygen
>
> and running strace on the application reveals that it is finding and crawling 
> the oxygen icon theme directories. However, if I rename the oxygen theme 
> directory to hicolor then the application does find the icons correctly.
>
> I have written a trivial Qt test, using 'QIcon::setThemeName("oxygen")' to 
> set the theme and it works fine.
>
> I also note that kiconfinder5 also finds the icons in the oxygen directory.
>
> I've tried some reverse-engineering/debugging but succeeded only in getting 
> lost in the code.
>
> One thing I suspect it that the problem might be related to my development 
> environment, which is a sandboxed Docker container with no display manager 
> installed. I understand that KDE tries to work out what icon theme is already 
> in use by an installed display manager, so perhaps this environment is 
> somehow triggering some unexpected (by me at least) behaviour.

By any chance, is the environment variable XDG_CURRENT_DESKTOP set
when applications are launched within the Docker container?
If not, it probably should be set to 'KDE' otherwise the appropriate
QPA won't be loaded and you won't get any icons loaded (as the theme
won't be known to the application)

>
> Thanks as always.
>
> Jonathan
>

Cheers,
Ben

Re: LXR is inaccessible

[Ben Cooksley]

On Tue, Feb 12, 2019 at 5:23 AM Nate Graham  wrote:
>
> Hello Sysadmins,
> https://lxr.kde.org/ is inaccessible right now. Any ETA on getting it
> back up?

Hi Nate,

Sorry for this - LXR went down when the physical host for it crashed
around 18 hours ago.
While the physical host was revived, the container that runs LXR
wasn't restarted.

I've now started it back up again.

>
> Nate
>

Cheers,
Ben

Re: Phabricator seems down

[Ben Cooksley]

On Wed, Feb 13, 2019 at 5:09 AM Nate Graham  wrote:
>
> Hello sysadmins,

Hi Nate,

> https://phabricator.kde.org is not responding responding right now for
> myself and others. Can you give it a kick?

It appears to have corrected itself.

>
> Thanks!
>
> Nate
>

Regards,
Ben Cooksley
KDE Sysadmin

Re: notes.kde.org having auth trouble

[Ben Cooksley]

On Wed, Feb 20, 2019 at 4:48 AM Nate Graham  wrote:
>
> Hello Sysadmin,

Hi Nate,

> People are having trouble authenticating to any of the documents on
> notes.kde.org. It's rejecting everyone's credentials for all documents
> at the moment.

It seems Nginx freaked out and forgot how to talk to LDAP.
Following a restart it is behaving correctly again and normal service
should be restored.

>
> Would someone mind taking a look?
>
> Nate
>

Regards,
Ben

Gitlab Evaluation & Migration

[Ben Cooksley]

Hi all,

Over the past few months a small group of KDE projects have been
evaluating Gitlab as a replacement for Phabricator, and we’ve now
reached the point where we’re ready to have a community wide
discussion regarding whether we’d like to migrate to Gitlab. We'd like
to start this by thanking those projects that have assisted in
evaluating Gitlab for KDE, at list of which can be found at
https://invent.kde.org/kde/

This evaluation process was started in response to feedback Sysadmin
received in the BoF session in Akademy last year regarding issues
developers we're having with Phabricator. These included the ability
to see the submitters details (name and email address), ability to do
multi-commit reviews and to merge changes conveniently from the web
amongst other things.

Based on the feedback we’ve received to date regarding the Gitlab
evaluation, the consensus seems to be that a migration would be
beneficial and helpful to us in the long term.

Among the benefits identified thus far are:
1) Provision of full featured task management and code review
functionality to scratch (personal) repositories, which will ease the
transition to playground and first release.
2) Ability to handle native Git commits as part of the code review
process and merge commits from the web interface rather than having to
take additional steps to integrate a change.
3) Easier and more logical grouping of projects, including being able
to view the tasks and repositories related to a specific project more
intuitively

Further notes on the evaluation can be found at
https://notes.kde.org/p/gitlab-evaluation-notes

In regards to Phabricator it should be noted that upstream does not
currently have plans to work on features which would resolve the
issues we've encountered, and their responsiveness to inquiries from
us has decreased since we migrated to it several years ago. Gitlab on
the other hand has a thriving community which openly accepts patches
and have been very helpful in assisting us with the evaluation process
(including solving problems we've found).

In addition to sysadmins and some of projects maintainers, KDE e.V.
board, and onboarding goal team has been involved in Gitlab evaluation
process as well, and they've made the following comments:

Neofytos Kolokotronis of the Onboarding goal team:
We believe this switch will be a great step forward for the Onboarding
goal as well. The workflow, features and general behavior of Gitlab
should be much more familiar to developers and non-coders interested
to contribute to KDE, thus lowering the entry barrier.  Further,
people coming from FOSS projects already on Github or Gitlab should
find it very straightforward to start contributing to KDE right away.
One area that is not to be ignored is that Gitlab has some great and
up to date documentation.

Eike Hein on behalf of the KDE e.V. board of directors:
After sysadmin gave us a situation report on our code hosting and
review infrastructure last year, we were initially involved with
building a relationship with GitLab upstream and setting up a call
schedule. We then turned the evaluation over to the sysadmin and
onboarding teams and received continual updates on its progress. We're
impressed by and thankful for the work done by everyone involved in
the intervening months, and stand by to help implement a community
decision based on what was collected.

Based on all of the above we'd like to propose migrating towards
Gitlab. Comments?

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Sun, Feb 24, 2019 at 4:56 AM Boudewijn Rempt  wrote:
>
> On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote:
>
> > As someone who uses gitlab on a dayjob I can tell it's pretty easy too.
> > With disregard to server interface you do `git push my-fork HEAD`,
> > right? Now, when you push to gitlab server, you get in the git output a
> > link that refers to creating a merge request to upstream. You just
> > click it, and then in a browser press "Ok".
>
> No, you misunderstand me. In the first place, we've got a lot of people in 
> our community who wouldn't understand a single word of that paragraph. What 
> they understand is
>
> * clone the repo
> * hack
> * type 'git diff > mydiff.diff'
> * upload the diff for review
> * add a bit of text explaining the change
> * wait for me or dmitry to look at their patches
>
> They don't have push access to kde's git server at all, so I guess 'git push 
> my-fork HEAD' won't work in any case.

The workflow in this case will be slightly different, but should be a
very familiar workflow for those coming from a Github world.

1) Login to invent.kde.org, fork the repository there into your
personal namespace
2) Clone the forked repository to your local system
3) Hack
4) Commit and push your changes to the forked repository
5) Follow the link in the push to create the merge request, adding all
the necessary commentary around it
6) Wait for review

Once you're happy with it you can integrate it by merging it from the
web interface (so no need to download and apply the patch locally)

Of course you'll still have the option of fetching their changes and
reviewing them on your local machine should you wish.
More documentation on merge requests is available at
https://invent.kde.org/help/user/project/merge_requests/index.md

>
> --
> https://www.valdyas.org | https://www.krita.org
>
>

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Sun, Feb 24, 2019 at 7:28 AM Boudhayan Gupta  wrote:
>
> Hi Ben et. al.,
>
> What are our plans regarding integrating with GitLab CI? I see that we have 
> the YAML files in some of the repos already, but do we plan to replace 
> Jenkins in the long run?

We've been experimenting with it, mostly at this time as a way of
providing CI on merge requests.

Our main issue at this stage is determining a way of deploying it in a
way that is maintainable (at the moment with Jenkins all builds are
conducted from a small set of central templates which makes
implementing KDE wide changes trivial, however Gitlab requires
per-repository .gitlab-ci.yaml files)

Once we've sorted that, it will definitely be brought online at the
very least to provide CI on merge requests and may quite possibly
replace build.kde.org as well.
Due to complexities and other security concerns changes to the Binary
Factory are not under consideration at this time.

>
> Sincerely,
> Boudhayan Gupta
>

Cheers,
Ben

>
> On Sat, 23 Feb 2019 at 11:04, Gleb Popov <6year...@gmail.com> wrote:
>>
>>
>>
>> On Sat, Feb 23, 2019 at 1:44 PM Ben Cooksley  wrote:
>>>
>>> Hi all,
>>>
>>> Over the past few months a small group of KDE projects have been
>>> evaluating Gitlab as a replacement for Phabricator, and we’ve now
>>> reached the point where we’re ready to have a community wide
>>> discussion regarding whether we’d like to migrate to Gitlab. We'd like
>>> to start this by thanking those projects that have assisted in
>>> evaluating Gitlab for KDE, at list of which can be found at
>>> https://invent.kde.org/kde/
>>>
>>> This evaluation process was started in response to feedback Sysadmin
>>> received in the BoF session in Akademy last year regarding issues
>>> developers we're having with Phabricator. These included the ability
>>> to see the submitters details (name and email address), ability to do
>>> multi-commit reviews and to merge changes conveniently from the web
>>> amongst other things.
>>>
>>> Based on the feedback we’ve received to date regarding the Gitlab
>>> evaluation, the consensus seems to be that a migration would be
>>> beneficial and helpful to us in the long term.
>>>
>>> Among the benefits identified thus far are:
>>> 1) Provision of full featured task management and code review
>>> functionality to scratch (personal) repositories, which will ease the
>>> transition to playground and first release.
>>> 2) Ability to handle native Git commits as part of the code review
>>> process and merge commits from the web interface rather than having to
>>> take additional steps to integrate a change.
>>> 3) Easier and more logical grouping of projects, including being able
>>> to view the tasks and repositories related to a specific project more
>>> intuitively
>>>
>>> Further notes on the evaluation can be found at
>>> https://notes.kde.org/p/gitlab-evaluation-notes
>>>
>>> In regards to Phabricator it should be noted that upstream does not
>>> currently have plans to work on features which would resolve the
>>> issues we've encountered, and their responsiveness to inquiries from
>>> us has decreased since we migrated to it several years ago.
>>
>>
>> My own experience agrees with this statement. I've got an impression that
>> Phabricator devs completely not interested in bug reports coming from users
>> with a pact (a term for paid support used by Phacility).
>>
>> So, I'm all for moving from Phabricator and that PHP-based CLI.
>>
>>> Gitlab on
>>> the other hand has a thriving community which openly accepts patches
>>> and have been very helpful in assisting us with the evaluation process
>>> (including solving problems we've found).
>>>
>>> In addition to sysadmins and some of projects maintainers, KDE e.V.
>>> board, and onboarding goal team has been involved in Gitlab evaluation
>>> process as well, and they've made the following comments:
>>>
>>> Neofytos Kolokotronis of the Onboarding goal team:
>>> We believe this switch will be a great step forward for the Onboarding
>>> goal as well. The workflow, features and general behavior of Gitlab
>>> should be much more familiar to developers and non-coders interested
>>> to contribute to KDE, thus lowering the entry barrier.  Further,
>>> people coming from FOSS projects already on Github or Gitlab should
>>> find it very straightforwa

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt  wrote:
>
> On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote:
>
> > "A lot" is probably a bit exaggerated, e.g. I don't really know where to
> > upload patches to Phabricator or create a pull request there, but do
> > understand how GitLab works.
>
> I was talking about the Krita community, which uses Phabricator extensively 
> in this way. I don't think you're familiar enough with the Krita community to 
> make this comment. Also, not knowing some thing (how to find the Code Review 
> link in the https://phabricator.kde.org/ homepage) while being familiar with 
> another workflow doesn't mean that the first thing is hard, and the second 
> one not.
>
> > So I guess we have many different people in the community and many of
> > them can get used to change.
>
> Everyone can get used to change; as long as the thing remains possible.
>
> > > * clone the repo
> > > * hack
> >
> > * git commit
> > * git push awesome-feature-branch
>
> So, basically, what you're saying is that unless a person has push rights, 
> they cannot collaborate? That's worse than I thought.

In the Gitlab world, people would fork the main repository, work on
their changes there and then send a merge request.
To make it absolutely clear, push rights to main repositories are not
required under any circumstances to contribute to a repository in the
Gitlab world.

For KDE Developers of course, they'll have the option of either
forking the repository (like anyone else would for making changes) or
working on a separate branch within the main repository. How projects
want to work is up to them indvidually, but both models work - only
non-developers are required to use forks.

>
> > * click on the link in the output
> >
> >
> > > * add a bit of text explaining the change
> > > * wait for me or dmitry to look at their patches
> >
> > One more step for the first creation of a merge request. Not that much
> > different.
> >
> > > They don't have push access to kde's git server at all, so I guess
> > > 'git push my-fork HEAD' won't work in any case.
> >
> > I guess this needs to change (with more fine grained permissions), the
> > whole Merge Request System is based on merging other branches to Master.
> > Afaik uploading just a patch doesn't work in GitLab.
>
> Well, that's too bad. Unless someone can explain to me how people can submit 
> patches for review without having push rights, a migration seems impossible. 
> It's already hard for some people to understand they need to create a KDE 
> identity, but once they've got that, they should be able to offer patches for 
> review.
>
> --
> https://www.valdyas.org | https://www.krita.org
>
>

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Sun, Feb 24, 2019 at 10:30 AM Alexander Potashev
 wrote:
>
> сб, 23 февр. 2019 г. в 12:44, Ben Cooksley :
> > Based on all of the above we'd like to propose migrating towards
> > Gitlab. Comments?
>
> Hi,

Hi Alexander,

>
> 1. We migrated from github.com to self-hosted GitLab when I worked
> full-time in a team of 4 developers. A major drawback we noticed back
> then was slow page loading when browsing a large diff (e.g. in a merge
> request). For example, this commit takes around 15 seconds to load:
> https://invent.kde.org/kde/kdenlive/commit/aadd9305b0467fa39e5c84af606c7d9eb1568533

That commit is massive and is far beyond what would be routine for a
project to commit, so I think it's quite reasonable for the system to
take a bit of time to process it.
Loading that page right now using the web inspector shows it takes
about 8 seconds to generate, followed by a further 4 seconds to
download, which doesn't seem unreasonable for 3200 lines of changes,
plus context, over 187 files - especially given it syntax highlights
it.

> .
>
> We had load times of over 30 seconds for a real-world merge request in
> a proprietary project of our team, however it depends on the
> server-side hardware.

We have relatively decent hardware available, so I don't expect that
to be an issue.

>
> 2. My other concern is the risk of uncontrolled creation of new
> branches because with GitLab they are created in the central repo for
> every new patch/feature. A repo may end up with dozens of branches of
> unclear status.
>
> The branch-per-feature approach works well for a small team of
> full-time developers since you can easily ask your colleagues "OK to
> delete this branch?" at any time and keep the repo as clean as you
> want. For >1000 people having write access (and who may become
> unavailable without notice), the same won't work.

It depends on the model you want to work with, as I mentioned in one
of my earlier emails regarding how merge requests would work.

Projects can choose one of two ways to do it (and even use both models
simultaneously should they wish):

1) Use branch-per-feature / review-request, with the branches being
housed in the main repository.
2) Use individual repository forks

With either model, as part of submitting the merge request you are
given the option to have the source branch removed when the merge
request is approved, which will cleanup the repository the merge
request is originated from.

>
> 3. Also, after moving to self-hosted GitLab, KDE's Git hosting will
> get the same familiar look and feel like
> github.com/gitlab.com/bitbucket, which may encourage random people to
> use it for anything (and their photo archives and more). Do we have
> the same infrastructure and administrative resources like GitHub has
> to overcome spam/abuse?

Other open source projects which have switched to Gitlab also allow
repositories to be created freely and they have not had to deal with
abuse problems.
I don't see why we would be any different.

>
> Even a fair user may create scratch repo/branch and forget about it,
> thousands of such users may easily turn our Git hosting into a
> landfill.

Because the repositories are under users own individual namespaces
this won't pollute the listing of main repositories which are what
everyone will be interested in.

>
> I know we had scratch repos before, but the steps to create them
> weren't as well-known and accessible as with GitLab. I believe, this
> is why we only have a limited number of scratch repos as of today.

git@code:~$ cat projects-list/projects-to-anongit.list | wc -l
2380
git@code:~$ cat projects-list/projects-to-anongit.list | grep -v
^scratch/ | grep -v ^clones/ | wc -l
1030
git@code:~$ cat projects-list/projects-to-anongit.list | grep ^scratch/  | wc -l
985
git@code:~$ cat projects-list/projects-to-anongit.list | grep ^clones/  | wc -l
365

If we count scratch and clone repositories together, 57% of all
repositories on our systems currently are "personal" repositories, so
they're certainly not in limited use.

>
> --
> Alexander Potashev

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser  wrote:
>
> Am 2019-02-23 10:44, schrieb Ben Cooksley:
> > Hi all,
>
> > Based on all of the above we'd like to propose migrating towards
> > Gitlab. Comments?
>
> I'm totally honest here: I'm not happy about yet another migration. This
> will be the fifth reviewing toolkit I use for KDE (reviewboard for svn,
> reviewboard for git, gerrit, phabricator and now gitlab). Each of the
> transitions was painful for everyone involved and the commit rate to the
> project I was involved suffered from the transitions. As an example for
> the problems: KWin's hacking document still mentions reviewboard:
> https://community.kde.org/KWin/Hacking#Submitting_Changes

Please don't over exaggerate the numbers here.

Gerrit was never an official system for reviews, it was something that
was evaluated by a small group and which was never proceeded with as
an official whole-of-KDE solution.
Reviewboard for SVN/Git are basically the same thing (just a different
instance url), so this is only really the third system, not the fifth

Please also bear in mind that we've been on Git now for coming up on 9
years (I have mails for git.kde.org starting around June 2010) so
switching systems twice in that time frame as software continues to
mature seems quite reasonable to me.

>
> I'm not pleased that we want to transit to another solution after just a
> few years. I understand that there is the feeling that our phabricator
> solution limits contributions from newcomers. I don't believe that and
> are afraid of the long term developers walking away due to the changes
> (which is something I saw with every transition). I don't know whether I
> will continue to contribute if I have to relearn the tooling - my time
> for KDE is currently very limited. If I have an hour to hack and have to
> spend half the time on how to contribute now, that sucks and lowers
> motivation.

If you've worked with Github before then Gitlab is very similar, so
the learning curve shouldn't be too steep.

>
> Changing the tooling will not solve any of the contribution problems.
> Instead we introduce new ones like all documentation going out of life.
>
> Please consider whether the advantages are really worth it.

Please also see my comments re. Phabricator upstream as to part of the
reason why we're considering this, along with the feedback we received
at Akademy last year.

>
> Best regards
> Martin

Regards,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Tue, Feb 26, 2019 at 10:02 PM Eike Hein  wrote:
>
>
>
> On 2/26/19 4:17 AM, Nate Graham wrote:
> > Like you, I have some reservations about Gitlab. I'm not thrilled about 
> > losing approve/request changes statuses (that's in the EE edition only 
> > right now).
>
> Me too. It's one of the things we're asking to be moved to the CE -- and
> so is Gnome. GitLab knows we're talking to each other and doubling down
> on this need.
>
>
>  > the kdesrc-build experience
>
> How would GitLab impact the kdesrc-build experience?
>
>
>  > Landing patches is time-consuming and error-prone.
>
> Yes. As a maintainer of things I often land patches by new contributors
> without dev access, and it's super annoying and painful. `arc patch`,
> remember to correct author info, merge around, ...
>
>
>  > Phab's system that attempts (and fails) to abstract away Git itself
>
> I think Phab was originally written for SVN - it shows I guess.

I can confirm that Phabricator was originally written for SVN (as that
is what is used internally at Facebook).

The ability to have Phabricator host repositories was something it
only gained around the time we started looking at migrating to it.
Prior to that it had exclusively been a repository viewer and code
review tool (and I suspect the code review part predates the
repository viewer component)

>
>
> Cheers,
> Eike

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Tue, Feb 26, 2019 at 5:54 AM Martin Flöser  wrote:
>
> Am 2019-02-24 21:03, schrieb Ben Cooksley:
> > On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser 
> > wrote:
> >>
> >> Am 2019-02-23 10:44, schrieb Ben Cooksley:
> >> > Hi all,
> >>
> >> > Based on all of the above we'd like to propose migrating towards
> >> > Gitlab. Comments?
> >>
> >> I'm totally honest here: I'm not happy about yet another migration.
> >> This
> >> will be the fifth reviewing toolkit I use for KDE (reviewboard for
> >> svn,
> >> reviewboard for git, gerrit, phabricator and now gitlab). Each of the
> >> transitions was painful for everyone involved and the commit rate to
> >> the
> >> project I was involved suffered from the transitions. As an example
> >> for
> >> the problems: KWin's hacking document still mentions reviewboard:
> >> https://community.kde.org/KWin/Hacking#Submitting_Changes
> >
> > Please don't over exaggerate the numbers here.
> >
> > Gerrit was never an official system for reviews, it was something that
> > was evaluated by a small group and which was never proceeded with as
> > an official whole-of-KDE solution.
> > Reviewboard for SVN/Git are basically the same thing (just a different
> > instance url), so this is only really the third system, not the fifth
>
> You missed the point. What I wrote is that the transitions were painful
> - also the very simple transition from svn.reviewboard to
> git.reviewboard was painful. That it was the same tool doesn't matter.
> It was still a transition, it meant looking at two places, lost reviews,
> update to documentation, change of workflow, etc. etc.
>
> Also gerrit was a tool I used for KDE hacking. I wrote it will be the
> fifth toolkit for me. That's true for me and I don't over exaggerate any
> numbers here.
>
> >
> > Please also bear in mind that we've been on Git now for coming up on 9
> > years (I have mails for git.kde.org starting around June 2010) so
> > switching systems twice in that time frame as software continues to
> > mature seems quite reasonable to me.
>
> Please keep also in mind that the git transition took a long time and
> started for different projects at different times. That you as sysadmin
> had mails going back so long does not mean others as well. I consider it
> as a transition too early after Phabricator was praised so much. I was
> sure that this would be a solution for the next decade.
>

Unfortunately this has turned out not to be the case, due to changing
needs of the community.

> >
> >>
> >> I'm not pleased that we want to transit to another solution after just
> >> a
> >> few years. I understand that there is the feeling that our phabricator
> >> solution limits contributions from newcomers. I don't believe that and
> >> are afraid of the long term developers walking away due to the changes
> >> (which is something I saw with every transition). I don't know whether
> >> I
> >> will continue to contribute if I have to relearn the tooling - my time
> >> for KDE is currently very limited. If I have an hour to hack and have
> >> to
> >> spend half the time on how to contribute now, that sucks and lowers
> >> motivation.
> >
> > If you've worked with Github before then Gitlab is very similar, so
> > the learning curve shouldn't be too steep.
>
> I haven't worked with github.
>
> >
> >>
> >> Changing the tooling will not solve any of the contribution problems.
> >> Instead we introduce new ones like all documentation going out of
> >> life.
> >>
> >> Please consider whether the advantages are really worth it.
> >
> > Please also see my comments re. Phabricator upstream as to part of the
> > reason why we're considering this, along with the feedback we received
> > at Akademy last year.
>
> Well I remember how phabricator was praised for the very responsive
> team. That seems to have changed. But who guarantees that gitlab will
> continue to be responsive and cooperative? Will we have to switch again
> if the team stops to be responsive?
>
> You asked for comments. I gave comment that I'm not pleased about yet
> another transition. Please keep that in mind. It means learning and
> interrupted workflows for every one. If you have already decided and
> don't want anybody to point out that transitions are painful, please
> don't ask for comments. Instead say that sysadmins decided. That's at
> least honest - your reply gives me the feeling the decision is already
> done and negative feedback was not expected. Sorry to feel this way.

Undertaking the process of transitioning from one tool to another is
not something we do lightly, as it not only involves disruption for
people who have to switch to a new set of tools, but also requires
substantial changes to the infrastructure (I will note that
Phabricator never took over hosting of our repositories)

No decision has been made, that's what this thread is about.
I may have my personal views on what may be best, but that's all they
are - my views.

>
> Cheers
> Martin

Regards,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Tue, Feb 26, 2019 at 10:26 PM  wrote:
>
> On 2019-02-26 10:13, Ben Cooksley wrote:
>
> > No decision has been made, that's what this thread is about.
> > I may have my personal views on what may be best, but that's all they
> > are - my views.
>
> I might be one of the few KDE contributors who actively likes
> phabricator, but I'm all for migrating. I've had a number of questions,
> but those have all been answered satisfactorily.
>
> * can new contributors without push access to the main repos still
> submit patches: yes
> * is our phabricator history safe: yes
> * I've seen one workboard per project, that's not ideal, otoh, the Krita
> community early on went overboard with workboards, so we can make do
> with that
> * it's possible to add images to issues, so the lack of mockups isn't
> that important -- we organized our mockups per task in any case
>
> I'm still not happy with how issue tracking and project management are
> conflated, but I guess I can live with that, as long as we keep bugzilla
> for user bug reports.

At this time we do most definitely plan to keep Bugzilla for user bug reports.

>
> We discussed this topic at yesterday's weekly Krita meeting, and
> everyone agreed that we are in favor of moving to gitlab.
>
> Boudewijn

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Wed, Feb 27, 2019 at 5:18 AM Harald Sitter  wrote:
>
> On Mon, Feb 25, 2019 at 2:38 PM Boudewijn Rempt  wrote:
> >
> > On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote:
> >
> > > * Is there anything we can have that can replace tasks and workboards? We 
> > > usually have some very long-running tasks that get a lot of sub-tasks and 
> > > that basically document our development process. One thing I've learned 
> > > with Phabricator is that project planning and issue tracking have nothing 
> > > to do with each other.
> >
> > Another thing here: what would be a good way to keep the really valuable 
> > information we've put in our tasks available? We have been tracking some 
> > big projects in phab's task system, and that information would be really 
> > hard to lose, but it would also rather suck to have to convert that 
> > manually to wiki pages or whatever...
>
> I suppose I could be persuaded to migrate all tasks again ;)
> As Eike mentioned the current boards feature is fairly limited though,
> so that may complicate things (a lot).

Fortunately we've already been linked to work done by others (FD.o,
GNOME, etc), so hopefully it'll just be a case of testing it on our
data, fixing any minor things we come across, then performing the
actual live migration :)

I haven't looked too much into that though as I wanted confirmation we
were going to undertake a migration before focusing on getting this
working 100%.

>
> HS

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne  wrote:
>
> On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> >   On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein  wrote 
> >  > On 2/27/19 4:38 AM, Nate Graham wrote:
> >  > > It's really pretty nice. But  Gitlab has a 
> > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, 
> > people without commit access won't just be able to start hacking with the 
> > source checkout that kdesrc-build downloads, or else they won't be able to 
> > push their branch to any remotes and create a Merge Request.
> >  >
> >  > No, this is not correct.
> >  >
> >  > When you have a local git repository (be it your own or a clone), it can
> >  > interact with any number of remote git repositories.
> >  >
> >  > When you do `git clone `, git automatically adds 
> >  > as a remote named "origin" to the local repository. But what "origin"
> >  > points to can be changed at any time, or other remotes with other names
> >  > can be added for pushing too. "origin" is just a convention.
> >  >
> >  > I.e. someone can totally do this:
> >  > 1. use kdesrc-build to clone stuff
> >  > 2. git checkout -b feature to make a feature branch
> >  > 3. hack
> >  > 4. make a private fork on gitlab
> >  > 5. push to their fork from the clone they've been working in
> >  >
> >  > It's not necessary to fork first and clone your fork to get started.
> >
> > Thanks Eike, that makes e a lot of sense. Going to the website to fork
> > each repo for the first time still adds an additional manual step
> > compared to the status quo, so it would be nice if we can get
> > kdesrc-build so set up forks automatically. That would be really
> > slick.
>
> That would be slick. I wonder if Gitlab exposes an API for that (ideally
> something that doesn't involve kdesrc-build having to store your creds)?
> Potentially this API
> https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's
> documented for EE not CE)?

The API for both EE and CE is identical, except for the functionality
that is dependent on the edition of EE it is available in (which is
only enabled if you are using that edition)
With regards to credentials, you would need to give it an API Token yes.

In terms of server load, it would be nice if the setup of forks was
still something the developer had to initiate rather than being done
automatically for every repository touched by kdesrc-build (I say this
mainly as if we had 50 people fork just half of the mainline
repositories we have, that's ~450GB of space used up - a massive
scalability issue)

>
> Regards,
>  - Michael Pyne

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Thu, Feb 28, 2019 at 11:24 AM Albert Astals Cid  wrote:
>
> El dimecres, 27 de febrer de 2019, a les 20:12:55 CET, Eike Hein va escriure:
> >
> > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > It's really pretty nice. But  Gitlab has a 
> > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, 
> > > people without commit access won't just be able to start hacking with the 
> > > source checkout that kdesrc-build downloads, or else they won't be able 
> > > to push their branch to any remotes and create a Merge Request.
> >
> > No, this is not correct.
>
> Can we enable the upload diff by email option? I know it's not the best UI 
> but for some people that have trouble understanding git remotes it may help?
>
> https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email

For ease of deployment, we didn't enable the email interface for the
evaluation instance.

As it's likely we would end up setting up the email interface for a
full production instance, this would be enabled as part of that.

>
> Cheers,
>   Albert
>
>

Regards,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Thu, Feb 28, 2019 at 10:23 PM Filipe Saraiva  wrote:
>
> Em 24/02/2019 22:25, Filipe Saraiva escreveu:
> >
> > 4. Is there any date to officially start the migration for all projects?
> > How will it be?
> >
>
> Will the migration happen before GSoC? Is it possible to a project
> request for migration and set Gitlab in the time for GSoC?

There is quite a bit of infrastructural work that will need to be done
should the consensus conclusion be that we should be migrating.
As such there is no guarantee that the migration will be in progress
or complete by the time GSoC starts.

Given we're still in early discussion on this, no policy around how
projects not involved in the evaluation can opt in early has yet been
made.

>
> --
> Filipe Saraiva
> http://filipesaraiva.info/

Regards,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Fri, Mar 1, 2019 at 3:13 AM Nate Graham  wrote:
>
>   On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley  
> wrote 
>  > In terms of server load, it would be nice if the setup of forks was
>  > still something the developer had to initiate rather than being done
>  > automatically for every repository touched by kdesrc-build (I say this
>  > mainly as if we had 50 people fork just half of the mainline
>  > repositories we have, that's ~450GB of space used up - a massive
>  > scalability issue)
>
> This seems like a challenge that needs to be addressed regardless of whether 
> or not kdesrc-build does it automatically, because people creating tons and 
> tons of forks is guaranteed to happen anyway if we move to Gitlab. It seems 
> non-optimal if having more people able to submit merge requests results in 
> the potential to blow up our servers.

We have a little over 1,000 mainline repositories, so in the above
example we'd be talking about 25,000 forks being created - and i'd be
expecting quite a bit more than 50 people to use kdesrc-build. To use
another scenario, if the metric of half the repositories being
involved (or even a quarter) held true with say 300 users, you're now
looking at 75,000 - 150,000 forked repositories (and probably around
1.4TB - 2.7TB of space used) courtesy of an automated tool.

It would take quite a while for us to reach 150,000 forked
repositories on Gitlab if humans were to be creating these manually,
however if an automated tool is going to be creating them as part of
it's workflow, then we will hit it much more quickly (and is a
phenomenal waste of resources given virtually all of those forks will
never be utilised)

I certainly do expect a number of forks to be created yes, but i'd
rather they be useful forks where someone at least intends on working
on something, rather than ones created automatically by software "just
in case" someone decides to work on a project.

>
> Nate
>

Cheers,
Ben

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Fri, 1 Mar 2019, 07:21 Gleb Popov <6year...@gmail.com wrote:

>
>
> On Thu, Feb 28, 2019 at 9:43 PM Ben Cooksley  wrote:
>
>> On Fri, Mar 1, 2019 at 3:13 AM Nate Graham  wrote:
>> >
>> >  ---- On Wed, 27 Feb 2019 23:02:03 -0700 Ben Cooksley <
>> bcooks...@kde.org> wrote 
>> >  > In terms of server load, it would be nice if the setup of forks was
>> >  > still something the developer had to initiate rather than being done
>> >  > automatically for every repository touched by kdesrc-build (I say
>> this
>> >  > mainly as if we had 50 people fork just half of the mainline
>> >  > repositories we have, that's ~450GB of space used up - a massive
>> >  > scalability issue)
>> >
>> > This seems like a challenge that needs to be addressed regardless of
>> whether or not kdesrc-build does it automatically, because people creating
>> tons and tons of forks is guaranteed to happen anyway if we move to Gitlab.
>> It seems non-optimal if having more people able to submit merge requests
>> results in the potential to blow up our servers.
>>
>> We have a little over 1,000 mainline repositories, so in the above
>> example we'd be talking about 25,000 forks being created - and i'd be
>> expecting quite a bit more than 50 people to use kdesrc-build. To use
>> another scenario, if the metric of half the repositories being
>> involved (or even a quarter) held true with say 300 users, you're now
>> looking at 75,000 - 150,000 forked repositories (and probably around
>> 1.4TB - 2.7TB of space used) courtesy of an automated tool.
>>
>> It would take quite a while for us to reach 150,000 forked
>> repositories on Gitlab if humans were to be creating these manually,
>> however if an automated tool is going to be creating them as part of
>> it's workflow, then we will hit it much more quickly (and is a
>> phenomenal waste of resources given virtually all of those forks will
>> never be utilised)
>>
>
> I wonder if advanced filesystem features like ZFS deduplication may help
> in this situation.
>

Deduplication can only do so much.

Even if you were to solve the capacity/resource issues, you would hit
another issue: Your personal namespace would be flooded with these
automatically created forks.

This would make your actual personal projects (which are future playground
projects in most cases) nearly impossible to find.


>
>> I certainly do expect a number of forks to be created yes, but i'd
>> rather they be useful forks where someone at least intends on working
>> on something, rather than ones created automatically by software "just
>> in case" someone decides to work on a project.
>>
>> >
>> > Nate
>> >
>>
>> Cheers,
>> Ben
>>
>
Regards,
Ben

>

Concluding the Gitlab Discussion

[Ben Cooksley]

Hi all,

Over the past few weeks we've had a discussion on whether we'd like to
migrate from Phabricator to Gitlab, for handling both our code reviews
as well as internal tasks (user facing bug reports are explicitly out
of context at this time)

Based on the comments the overall consensus seems to be at this stage
to favour switching to Gitlab.

This however is subject to a caveat around multiple task boards, which
would be needed for larger projects to effectively coordinate amongst
the various sub-projects.

As part of the transition we will also arrange for the email interface
to be enabled (for emailing in patches) and for the default for merges
to be rebase when it's not a fast forward merge for all repositories.

Does anyone have any final comments?

In terms of the steps forward from here, Sysadmin will need a bit of
time to prepare various parts of the infrastructure for the transition
(such as the anongit network, which will need a full rebuild as part
of switching).

Once this is complete, we'll be in touch with more information on how
the transition will take place.

Thanks,
Ben Cooksley
KDE Sysadmin

Re: Gitlab Evaluation & Migration

[Ben Cooksley]

On Sat, Mar 23, 2019 at 12:42 AM Milian Wolff  wrote:
>
> On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote:
> > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne  wrote:
> > > On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote:
> > > >   On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein  wrote
> > > >  
> > > >
> > > >  > On 2/27/19 4:38 AM, Nate Graham wrote:
> > > >  > > It's really pretty nice. But  Gitlab has a
> > > >  > > fork-the-repo-and-submit-a-merge-request workflow, so in steps 3
> > > >  > > and 4, people without commit access won't just be able to start
> > > >  > > hacking with the source checkout that kdesrc-build downloads, or
> > > >  > > else they won't be able to push their branch to any remotes and
> > > >  > > create a Merge Request.> >  >
> > > >  > No, this is not correct.
> > > >  >
> > > >  > When you have a local git repository (be it your own or a clone), it
> > > >  > can
> > > >  > interact with any number of remote git repositories.
> > > >  >
> > > >  > When you do `git clone `, git automatically adds
> > > >  > 
> > > >  > as a remote named "origin" to the local repository. But what "origin"
> > > >  > points to can be changed at any time, or other remotes with other
> > > >  > names
> > > >  > can be added for pushing too. "origin" is just a convention.
> > > >  >
> > > >  > I.e. someone can totally do this:
> > > >  > 1. use kdesrc-build to clone stuff
> > > >  > 2. git checkout -b feature to make a feature branch
> > > >  > 3. hack
> > > >  > 4. make a private fork on gitlab
> > > >  > 5. push to their fork from the clone they've been working in
> > > >  >
> > > >  > It's not necessary to fork first and clone your fork to get started.
> > > >
> > > > Thanks Eike, that makes e a lot of sense. Going to the website to fork
> > > > each repo for the first time still adds an additional manual step
> > > > compared to the status quo, so it would be nice if we can get
> > > > kdesrc-build so set up forks automatically. That would be really
> > > > slick.
> > >
> > > That would be slick. I wonder if Gitlab exposes an API for that (ideally
> > > something that doesn't involve kdesrc-build having to store your creds)?
> > > Potentially this API
> > > https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's
> > > documented for EE not CE)?
> >
> > The API for both EE and CE is identical, except for the functionality
> > that is dependent on the edition of EE it is available in (which is
> > only enabled if you are using that edition)
> > With regards to credentials, you would need to give it an API Token yes.
> >
> > In terms of server load, it would be nice if the setup of forks was
> > still something the developer had to initiate rather than being done
> > automatically for every repository touched by kdesrc-build (I say this
> > mainly as if we had 50 people fork just half of the mainline
> > repositories we have, that's ~450GB of space used up - a massive
> > scalability issue)
>
> Are you sure about this? Isn't gitlab using something like `git-new-workdir`
> internally to save on the disk overhead? If not, then request it, that would
> be an obvious optimization opportunity.

I haven't checked, but at first glance it doesn't seem to do this
(which would make sense, because you're actually able to have multiple
Gitaly instances to store repositories for a single Gitlab instance).

In any case, i'd rather that we used fork in a manner that makes sense
rather than trying to optimise for something that ends up creating
thousands of repositories which are never used. We should only be
creating forks / repositories which are actually going to be used.

>
> Bye
>
> --
> Milian Wolff
> m...@milianw.de
> http://milianw.de

Regards,
Ben

Re: Concluding the Gitlab Discussion

[Ben Cooksley]

On Tue, Mar 19, 2019 at 10:47 PM Nate Graham  wrote:
>
> One thing I'd really like to not lose is the review status feature 
> (approved/changes requested/etc). I've head that this is EE only. Is there 
> any word on getting that added to our package?

We'll look into discussing this with them.

>
> Other than that, I think I think what Gitlab offers over Phabricator is 
> either a significant win or else just something different that you can get 
> used to quickly.
>
> Nate

Regards,
Ben

>
>
>   On Tue, 19 Mar 2019 02:26:24 -0600 Ben Cooksley  
> wrote 
>  > Hi all,
>  >
>  > Over the past few weeks we've had a discussion on whether we'd like to
>  > migrate from Phabricator to Gitlab, for handling both our code reviews
>  > as well as internal tasks (user facing bug reports are explicitly out
>  > of context at this time)
>  >
>  > Based on the comments the overall consensus seems to be at this stage
>  > to favour switching to Gitlab.
>  >
>  > This however is subject to a caveat around multiple task boards, which
>  > would be needed for larger projects to effectively coordinate amongst
>  > the various sub-projects.
>  >
>  > As part of the transition we will also arrange for the email interface
>  > to be enabled (for emailing in patches) and for the default for merges
>  > to be rebase when it's not a fast forward merge for all repositories.
>  >
>  > Does anyone have any final comments?
>  >
>  > In terms of the steps forward from here, Sysadmin will need a bit of
>  > time to prepare various parts of the infrastructure for the transition
>  > (such as the anongit network, which will need a full rebuild as part
>  > of switching).
>  >
>  > Once this is complete, we'll be in touch with more information on how
>  > the transition will take place.
>  >
>  > Thanks,
>  > Ben Cooksley
>  > KDE Sysadmin
>  >
>

Re: Concluding the Gitlab Discussion

[Ben Cooksley]

On Tue, Mar 19, 2019 at 9:26 PM Ben Cooksley  wrote:
>
> Hi all,
>
> Over the past few weeks we've had a discussion on whether we'd like to
> migrate from Phabricator to Gitlab, for handling both our code reviews
> as well as internal tasks (user facing bug reports are explicitly out
> of context at this time)
>
> Based on the comments the overall consensus seems to be at this stage
> to favour switching to Gitlab.
>
> This however is subject to a caveat around multiple task boards, which
> would be needed for larger projects to effectively coordinate amongst
> the various sub-projects.
>
> As part of the transition we will also arrange for the email interface
> to be enabled (for emailing in patches) and for the default for merges
> to be rebase when it's not a fast forward merge for all repositories.
>
> Does anyone have any final comments?
>
> In terms of the steps forward from here, Sysadmin will need a bit of
> time to prepare various parts of the infrastructure for the transition
> (such as the anongit network, which will need a full rebuild as part
> of switching).
>
> Once this is complete, we'll be in touch with more information on how
> the transition will take place.

As it has now been a month since the initial thread was opened, and
with no final comments aside from Nate's over the past couple of days,
it seems that everyone is happy with the above as the community
consensus.

We'll now proceed with preparing for a migration to Gitlab, subject to
the above caveat of getting multi-project boards (and with a request
to see if we can get merge request approvers sorted as well if
possible)

>
> Thanks,
> Ben Cooksley
> KDE Sysadmin

Regards,
Ben

Re: Concluding the Gitlab Discussion

[Ben Cooksley]

On Sun, Mar 24, 2019 at 8:46 AM Tomaz Canabrava  wrote:
>
> People, and the apps that are still in svn, like kmldonkey, will be migrated 
> too ?

Subversion will not be impacted in any form.
They'll remain outside of Gitlab.

Cheers,
Ben

>
> Em sáb, 23 de mar de 2019 às 03:31, Ben Cooksley  escreveu:
>>
>> On Tue, Mar 19, 2019 at 9:26 PM Ben Cooksley  wrote:
>> >
>> > Hi all,
>> >
>> > Over the past few weeks we've had a discussion on whether we'd like to
>> > migrate from Phabricator to Gitlab, for handling both our code reviews
>> > as well as internal tasks (user facing bug reports are explicitly out
>> > of context at this time)
>> >
>> > Based on the comments the overall consensus seems to be at this stage
>> > to favour switching to Gitlab.
>> >
>> > This however is subject to a caveat around multiple task boards, which
>> > would be needed for larger projects to effectively coordinate amongst
>> > the various sub-projects.
>> >
>> > As part of the transition we will also arrange for the email interface
>> > to be enabled (for emailing in patches) and for the default for merges
>> > to be rebase when it's not a fast forward merge for all repositories.
>> >
>> > Does anyone have any final comments?
>> >
>> > In terms of the steps forward from here, Sysadmin will need a bit of
>> > time to prepare various parts of the infrastructure for the transition
>> > (such as the anongit network, which will need a full rebuild as part
>> > of switching).
>> >
>> > Once this is complete, we'll be in touch with more information on how
>> > the transition will take place.
>>
>> As it has now been a month since the initial thread was opened, and
>> with no final comments aside from Nate's over the past couple of days,
>> it seems that everyone is happy with the above as the community
>> consensus.
>>
>> We'll now proceed with preparing for a migration to Gitlab, subject to
>> the above caveat of getting multi-project boards (and with a request
>> to see if we can get merge request approvers sorted as well if
>> possible)
>>
>> >
>> > Thanks,
>> > Ben Cooksley
>> > KDE Sysadmin
>>
>> Regards,
>> Ben

CI system maintainability

[Ben Cooksley]

Hi all,

We currently have a rather substantial issue, in that the CI system
has been once again left in a position where it isn't possible to make
any changes to the system.

This means we can't update to newer versions of packages, add new
packages or correct for binary incompatible changes which periodically
get introduced to non-Frameworks.

This issue has arisen because currently we have a recurring failure to
build from source, within KDE PIM. Specifically, KContacts fails due
to broken CMake logic. Despite this breakage having been in place for
several days now, and the relevant mailing list being informed
automatically by the CI system, the issue has not been corrected.

While the most immediate fix is to correct this failure to build from
source, that is only a short term fix and does not fix the underlying
issue which makes the CI system difficult to maintain - and that is
build failure reports being ignored, and people pushing broken code
that doesn't even build.

(For those wondering, the CI system uses OpenSUSE Tumbleweed, a
rolling release distribution, for it's builds, so it isn't a case of
old CMake or anything along those lines)

We therefore need a long term fix for this. Note that pre-commit (as
part of review) CI is not a solution in this instance, as the
offending commits did not go through review.

Does anyone have any ideas for a long term, proper fix to this?

At this point given the amount of effort required to maintain a CI
system vs. the amount of care actually being given by some developers
(who are ignoring it's failure emails) it becomes questionable whether
the effort is worth the return (and if not, we should just shut it
down)

Regards,
Ben Cooksley
KDE Sysadmin

Re: CI system maintainability

[Ben Cooksley]

On Thu, Mar 28, 2019 at 7:56 PM Konstantin Kharlamov  wrote:
>
>
>
> On Чт, Mar 28, 2019 at 19:40, Ben Cooksley  wrote:
> > Hi all,
> >
> > We currently have a rather substantial issue, in that the CI system
> > has been once again left in a position where it isn't possible to make
> > any changes to the system.
> >
> > This means we can't update to newer versions of packages, add new
> > packages or correct for binary incompatible changes which periodically
> > get introduced to non-Frameworks.
> >
> > This issue has arisen because currently we have a recurring failure to
> > build from source, within KDE PIM. Specifically, KContacts fails due
> > to broken CMake logic. Despite this breakage having been in place for
> > several days now, and the relevant mailing list being informed
> > automatically by the CI system, the issue has not been corrected.
> >
> > While the most immediate fix is to correct this failure to build from
> > source, that is only a short term fix and does not fix the underlying
> > issue which makes the CI system difficult to maintain - and that is
> > build failure reports being ignored, and people pushing broken code
> > that doesn't even build.
> >
> > (For those wondering, the CI system uses OpenSUSE Tumbleweed, a
> > rolling release distribution, for it's builds, so it isn't a case of
> > old CMake or anything along those lines)
> >
> > We therefore need a long term fix for this. Note that pre-commit (as
> > part of review) CI is not a solution in this instance, as the
> > offending commits did not go through review.
> >
> > Does anyone have any ideas for a long term, proper fix to this?
> >
> > At this point given the amount of effort required to maintain a CI
> > system vs. the amount of care actually being given by some developers
> > (who are ignoring it's failure emails) it becomes questionable whether
> > the effort is worth the return (and if not, we should just shut it
> > down)
> >
> > Regards,
> > Ben Cooksley
> > KDE Sysadmin
>
> I don't know abut the current CI, but judging by recent discussion that
> is about KDE migrating to gitlab; quick search shows gitlab does allow
> prohibiting a merge if CI failed¹
>
> Note however, in my experience of contributing to diffrent project CI
> often fails for reasons absolutely irrelevant to code being tested
> (e.g. errors in a CI script), in this case prohibiting a merge may
> worsen the situation.

Please note that the commits in this instance were pushed without
review, so restrictions on merge requests wouldn't make a difference
in this case unfortunately.

>
> 1:
> https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds
>
>

Cheers,
Ben

Re: Updating the Framework apidocs part 1: fixing the presentation

[Ben Cooksley]

On Fri, Mar 29, 2019 at 9:47 PM Juan Carlos Torres  wrote:
>
> Hello everyone!
>
> It's that docs guy again! Hope you don't mind this brief interruption of 
> coding activities to give our apidocs some TLC.
>
> I recently went over the KDE Frameworks apidocs, one framework and class at a 
> time, to get an overview of what we're facing. And, to be honest, there's 
> quite a lot to be done but we can probably already start with the lowest 
> hanging fruit: the presentation/style. There are three things that seem to be 
> off with the current design that we're using (I'll be filing bug reports as 
> well):
>
> - All the class names at the top of their respective pages only show the 
> Framework name. For example, instead of showing "KAboutData", it displays 
> "KCoreAddons" only. [1]
> - The table-based layout for parameters/returns and their descriptions are 
> too narrow and run into each other. [2]
> - The headers of Deprecated and Todo pages (of frameworks that have them) are 
> unreadable. [3]
>
> Probably small stuff but enough to get started on making the apidocs look 
> professional. On that note, is there someone I need to get in touch with 
> about the design of the apidocs? ECM, for example, looks totally out of place.

>From my understanding ECM has a totally separate and different system
for generating it's API Documentation (because Doxygen can't handle
CMake files I believe) which is why it looks totally different.

>
> I'd love to hear your thoughts and suggestions on the current state of our 
> Frameworks apidocs and how we can make them even better than before. I'm also 
> on IRC (Jucato) and Matrix (also Jucato), though do note I live on UTC+8.
>
> 1. https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html
> 2. 
> https://api.kde.org/frameworks/attica/html/classAttica_1_1AccountBalance.html#a71c29c3638accbd6216be60b08509b76
> 3. https://api.kde.org/frameworks/karchive/html/deprecated.html
>
>
> Regards,

Cheers,
Ben

>
> --
>
> Juan Carlos Torres
> Jucato

Re: CI system maintainability

[Ben Cooksley]

On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
 wrote:
>
> Hi,

Hi,

>
> (Sorry for top-posting)
>
> I fear that a mandatory reviews would add too juch strain on smaller teams. 
> If there's just one person with an intimate knowledge of the code-base, plus 
> two co-developers, then who should do the reviews?
>
> How about a distinction based on importance of a project instead? I.e. 
> mandatory reviews for frameworks and any app that wants to be included in KDE 
> apps releases. Non-mandatory reviews can then also come with a "price" to 
> pay: if CI errors are not dealt with in a timely manner, you should be free 
> to disable the CI for administrative reasons...

While this does seem like a nice solution, unfortunately for many
repositories it isn't a case of disabling CI coverage for it, but also
CI coverage for everything that depends on it. In the case of
KContacts, this would also impact on parts of Extragear and Calligra
(who depending on their exact requirements would either lose a
dependency being available, or lose all of their CI coverage).

This is why i've not pursued this as an option in the past, because
it's not fair on other projects that don't have anything to do with
another project aside from being a user of it's interfaces to lose
their coverage, simply because the project they depend on is broken.

>
>   Johannes

Cheers,
Ben

>
> Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava :
> >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame 
> >wrote:
> >>
> >> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto:
> >> > I'd argue we're loosing more with the current state of PIM than
> >we'd loose
> >> > with mandatory reviews.
> >>
> >> Perhaps, instead of an all-or-nothing approach, why not a minimal set
> >of
> >> "requirements" that would require a review? Yes, it requires more
> >discipline
> >> from those involved, but at least it will help people getting
> >"ingrained" with
> >> the concept without being a wall.
> >>
> >> Examples:
> >>
> >> - No review: typo fixes, compile errors, version bumps (internal)
> >> - Review: build system adjustments (perhaps CC some people
> >knowledgeable in
> >> this case), non-trivial changes like patches
> >> - "Deprecation" removals (as in the casus belli here) - review if
> >touching
> >> more than a handful of files / multiple repos
> >>
> >> (list made by someone who has a passing knowledge of C++, so feel
> >free to rip
> >> me to shreds)
> >>
> >> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps
> >direct
> >> mailing to the user (as I suggested earlier) in case of continuous
> >failures
> >> will also help.
> >>
> >> If this thing works, one can gradually ramp up the requirements of
> >things that
> >> go through review when the "muscle memory" is formed.
> >
> >The problem is that a git comit is a git commit, there's no way that a
> >typo will be treated differently then another commit.
> >I strongly advocate for "reviews always", but since I was outvoted a
> >few times on this I would at least say "can we at least have reviews
> >for non project members" ?
> >
> >
> >> --
> >> Luca Beltrame
> >> GPG key ID: A29D259B

Re: CI system maintainability

[Ben Cooksley]

On Fri, Mar 29, 2019 at 10:33 PM Friedrich W. H. Kossebau
 wrote:
>
> Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel:
> > Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> > > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> > > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > > > > Given the actual purpose of this thread, I would be more curious how
> > > > > you
> > > > > have CI integrated in your workflow?
> > > >
> > > > CI: sometime I look at it, sometime not, sometime some guys informs me
> > > > that
> > > > it's broken (I remember that Luca told me some days ago that a package
> > > > didn't compile, so I fixed it).
> > > > Sometime my code compiles on local so for me it's ok but it's just that
> > > > I
> > > > forgot to trash my builddir.
> > >
> > > So you do not go on yourself to build.kde.org and check yourself? Does
> > > #kde- pim have a bot reporting build failures?
> >
> > Long time ago we had it in #kontact.
> > It's not the case now.
>
> Do you remember a reason why it is no longer the case?
>
> IMHO bringing the build report bot back to the chat channel could help with
> the issue this thread is about.

It was quite possibly lost during one of the various refactors we've
had to do of the CI system to solve maintainability issues.
We've had a couple of generations of the CI system so far (by my
count, we're on generation 4), and things have unfortunately been lost
in between the switch between various generations.

IRC channel notifications are currently governed by the rules in
sysadmin/irc-notifications (which is also where commits and Bugzilla
activity notifications for IRC channels are controlled from). See
https://cgit.kde.org/sysadmin/irc-notifications.git/tree/jenkins/notifications.cfg

>
> People tend to look more often into the chat channel then in their email
> folder, so this bot would improve the visibility of the state on
> build.kde.org, also be in a public place so people can directly chat about
> any reasons.
>
> > > > > more? Given you said you work daily on KDE projects, it seems that
> the
> > > > > brokeness of those projects on the KDE CI has slipped your attention.
> > > > > So
> > > > > how does this happen, and how could this be prevented, other than
> > > > > people
> > > > > having to hunt you down on irc and tell you :)
> > > >
> > > > I think that Luca idea to send an email directly to the people which
> > > > breaks
> > > > code when it breaks from several commit is a good idea.
> > >
> > > Noted. Personally I would also fancy that over the generic mass emailing,
> > > where most of the time it was somebody else breaking stuff, so they
> should
> > > care. Given the time-offset due to build times it is also unclear who
> > > broke
> > > things, given the email is not easy to parse, and one might already be
> off
> > > again to other things in life.
> > >
> > > Question is: when would you read the email, and how quick would you
> react?
> >
> > I read it sometime as it arrives in my kdepim-devel mailbox, but indeed
> > sometime we can have several mail in same time because we increase a
> package
> > dependancy and it breaks all other packages. So indeed I didn"t look at all
> > the time.
> >
> > But when a people signals me a problem I try to fix it quickly.
> >
> > An email send after 1 day that package is broken can be a good idea, so it
> > can't be a dependancy problem because we increase package version just that
> > it's really broken.
>
> Increasing the package version ideally should not result in CI breakages.
> Ideally CI only fails if there is a real issue, otherwise people just get
> used to it failing and do not give the deserved attention.
>
> What would prevent you to turn to a system like used with KDE Frameworks,
> where there is some internal dependency version and a separate actual
> version, with the actual version bumped earlier and the internal dependency
> version only bumped some days later? From what I saw, you increase versions
> quite often in PIM, so related breakages would happen quite often.
>
> Cheers
> Friedrich

Cheers,
Ben

>
> PS: Okay if we start to slim the list of CC:s a bit now? Would leave out
> plasma, kdevelop, frameworks-devel on any next reply at least.
>
>

Re: CI system maintainability

[Ben Cooksley]

On Fri, Mar 29, 2019 at 9:56 PM Kevin Ottens  wrote:
>
> Hello,
>
> On Thursday, 28 March 2019 20:35:11 CET Dr.-Ing. Christoph Cullmann wrote:
> > I and others tried to get more reviews done in the past, but actually I
> > merged more than once stuff that I reviewed but it did break the CI.
>
> That I hope we'll get fixed at some point. It's a big big advantage when you
> can get a CI run on reviews. I find it best when you get both humans and
> scripts looking at the code in a review. It helps a lot in having better
> quality reviews from the humans since they are relieved from the boring
> redundant nitpicking (catching warnings, basic code style, etc.).

With the shift to Gitlab we should be able to provide this hopefully.

We're still figuring out how to be able to provide CI in an easy to
maintain manner (in terms of controlling platforms builds are done
for, which branches, etc).
This is a non-trivial problem (which is why Jenkins is only able to do
master/trunk and stable builds currently) but it should be solvable.

>
> Regards.
> --
> Kevin Ottens, http://ervin.ipsquad.net

Cheers,
Ben

Re: CI system maintainability

[Ben Cooksley]

On Sat, Mar 30, 2019 at 10:46 PM Volker Krause  wrote:
>
> On Friday, 29 March 2019 20:54:54 CET Ben Cooksley wrote:
> > On Fri, Mar 29, 2019 at 6:45 AM Johannes Zarl-Zierl
> > > I fear that a mandatory reviews would add too juch strain on smaller
> > > teams. If there's just one person with an intimate knowledge of the
> > > code-base, plus two co-developers, then who should do the reviews?
> > >
> > > How about a distinction based on importance of a project instead? I.e.
> > > mandatory reviews for frameworks and any app that wants to be included in
> > > KDE apps releases. Non-mandatory reviews can then also come with a
> > > "price" to pay: if CI errors are not dealt with in a timely manner, you
> > > should be free to disable the CI for administrative reasons...
> > While this does seem like a nice solution, unfortunately for many
> > repositories it isn't a case of disabling CI coverage for it, but also
> > CI coverage for everything that depends on it. In the case of
> > KContacts, this would also impact on parts of Extragear and Calligra
> > (who depending on their exact requirements would either lose a
> > dependency being available, or lose all of their CI coverage).
> >
> > This is why i've not pursued this as an option in the past, because
> > it's not fair on other projects that don't have anything to do with
> > another project aside from being a user of it's interfaces to lose
> > their coverage, simply because the project they depend on is broken.
>
> I agree that anything on the CI level would be merely a workaround for this at
> best. I'd rather suggest we address this at the source by turning the
> externally used modules into frameworks. We did that last year already for
> KHolidays and Syndication who were used by Plasma among others. KContacts,
> KCalCore and KMime should follow that next IMHO.
>
> The next time window to do that relatively painlessly is coming up after the
> 19.04 applications release I think, and all of those have been part of the
> KDE4-era kdepimlibs module that complied with KF5-like ABI guarantees, so the
> necessary work should be limited hopefully. Extra review of the public
> interfaces would certainly help with making this happen I think.

This would certainly help resolve many of the issues I think, because
then the build issues should be mostly contained to one specific
Product, which makes this much easier to work with in the long term.

>
> Regards,
> Volker

Cheers,
Ben

Re: Signing keys for commercial app stores

[Ben Cooksley]

On Mon, Jun 10, 2019 at 2:03 PM Simon Redman  wrote:
>
> Hello,

Hi Simon,

>
> I am Simon, and I work on KDE Connect. This summer, KDE Connect has two
> excellent GSoC students, one working on a MacOS port and one working on
> a Windows port, with the end goal of bringing those ports to feature
> pairity with our Linux version and doing an official release.
>
> While we could just post our releases to some X.kde.org website and
> distribute unsigned binaries, this would not reach as many users as
> having them properly signed and released via the offical MacOS and
> Windows app stores.
>
> Does anyone have experience with:
> A. Windows App Store Releases
> B. MacOS App Store Release
>

While i'm not 100% familiar with things, for Windows releases at least
we already have substantial tooling and infrastructure in place for
this.

The Binary Factory (binary-factory.kde.org) is capable of generating
both regular signed Windows installers, as well as Windows appx
bundles for uploading to the Windows Store. The KDE e.V. also operates
an official presence (as such) on the Windows which Sysadmin governs
control of.

To get started with these, i'd suggest your Windows student work on
the Craft packaging for KStars. Once that is in place we can look into
delegating access to the Windows Store to one of the KStars team to
allow you to submit KStars there (along with updates as needed)

With regards to MacOS, due to how Apple manages this we have no
official option for signing or making releases on the Apple Store at
this time.

Given that an Apple Developer ID is required at minimum for signing
applications, and with an impending change to require applications be
notarised by Apple in future versions of MacOS (will be enforced from
Catalina onwards), it is unlikely we'll be making a change to this (as
there is no benefit to us having the Binary Factory sign apps when
they need to be notaised for users to run them without having to jump
through hoops - we may as well ship them unsigned).

> Thanks,
> Simon

Regards,
Ben