Re: Sysadmin Load Reduction: Code Related Services

2019-11-15 Thread Alexander Potashev
пт, 15 нояб. 2019 г. в 22:05, Ben Cooksley :
>
> On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev  
> wrote:
> >
> > пт, 15 нояб. 2019 г. в 15:46, Harald Sitter :
> > >
> > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev  
> > > wrote:
> > > >
> > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley :
> > > > > In the category of no longer in use, we have the compatibility
> > > > > generator for the kde_projects.xml file. This was introduced when we
> > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > > > keeping services that needed to discover a list of KDE Projects
> > > > > functional.
> > > > >
> > > > > As we've since migrated to using YAML files within the
> > > > > sysadmin/repo-metadata repository for both the CI System and
> > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > > checkouts) there shouldn't to my knowledge be anything still relying
> > > > > on this (aside from perhaps scripty).
> > > > >
> > > > > I'd therefore like to shut this generator down as well, along with the
> > > > > compaibility redirector running at projects.kde.org (given that it has
> > > > > been some time since we were using that site, and many projects have
> > > > > moved around in the virtual structure since then, making the redirects
> > > > > it is able to offer useless)
> > > >
> > > > Hi Ben,
> > > >
> > > > I am developing a new version of the "opensrc" plugin for Lokalize [1]
> > > > and it currently depends on kde_projects.xml. Of course I can add new
> > > > code to scan the Git repo instead of just fetching kde_projects.xml,
> > > > however it would be more complicated.
> > >
> > > https://projects.kde.org/api/doc/ specifically deals with this problem
> > > by abstracting the repo away behind a micro service.
> >
> > This looks like another view of the data available in
> > kde_projects.xml, however the API is very limited. For example I can't
> > query repo descriptions using this API. Thus not helpful.
> >
> > However if we were going to kill kde_projects.xml, are you sure
> > projects.kde.org/api/ would be still available and not shut down as
> > well?
>
> The API that Harald mentions is based off the YAML files, and is not
> reliant on the legacy kde_projects.xml file.

I can implement kde_projects.xml or a modernized version of it as part
of projects.kde.org/api/. Does this sound like a good idea?

We don't need to support the exact same XML format, so I would prefer
a JSON listing all projects with all their properties, at something
like GET https://projects.kde.org/api/v1/export or may be return all
project properties in GET https://projects.kde.org/api/v1/projects

-- 
Alexander Potashev


Re: Sysadmin Load Reduction: Code Related Services

2019-11-15 Thread Ben Cooksley
On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev  wrote:
>
> пт, 15 нояб. 2019 г. в 15:46, Harald Sitter :
> >
> > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev  
> > wrote:
> > >
> > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley :
> > > > In the category of no longer in use, we have the compatibility
> > > > generator for the kde_projects.xml file. This was introduced when we
> > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > > keeping services that needed to discover a list of KDE Projects
> > > > functional.
> > > >
> > > > As we've since migrated to using YAML files within the
> > > > sysadmin/repo-metadata repository for both the CI System and
> > > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > > checkouts) there shouldn't to my knowledge be anything still relying
> > > > on this (aside from perhaps scripty).
> > > >
> > > > I'd therefore like to shut this generator down as well, along with the
> > > > compaibility redirector running at projects.kde.org (given that it has
> > > > been some time since we were using that site, and many projects have
> > > > moved around in the virtual structure since then, making the redirects
> > > > it is able to offer useless)
> > >
> > > Hi Ben,
> > >
> > > I am developing a new version of the "opensrc" plugin for Lokalize [1]
> > > and it currently depends on kde_projects.xml. Of course I can add new
> > > code to scan the Git repo instead of just fetching kde_projects.xml,
> > > however it would be more complicated.
> >
> > https://projects.kde.org/api/doc/ specifically deals with this problem
> > by abstracting the repo away behind a micro service.
>
> This looks like another view of the data available in
> kde_projects.xml, however the API is very limited. For example I can't
> query repo descriptions using this API. Thus not helpful.
>
> However if we were going to kill kde_projects.xml, are you sure
> projects.kde.org/api/ would be still available and not shut down as
> well?

The API that Harald mentions is based off the YAML files, and is not
reliant on the legacy kde_projects.xml file.

>
> --
> Alexander Potashev

Cheers,
Ben


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

2019-11-15 Thread Valorie Zimmerman
Amen to that! Sysadmin have always supported us (Student Programs,
Community Working Group) in when we've asked and even before we ask. :-)

Thank you.

Valorie

On Sun, Nov 10, 2019 at 3:28 AM Martin Steigerwald 
wrote:

> Dear Ben, dear admins for KDE infrastructure,
>
> Ben Cooksley - 09.11.19, 00:49:49 CET:
> > One of the things that was prepared as a result of the Sysadmin BoF at
> > Akademy was a list of systems and services which we look after and
> > provide to the community.
> >
> > Whilst individually all of the services seem fairly reasonable and
> > maintainable, the cumulative number of them has created a situation
> > where they limit our ability to reasonably maintain our services as a
> > collective whole.
>
> I followed the discussion followed by this and your other mails about
> that topic. And I am completely missing a very important thing in there:
>
> *Thank you*!
>
> *Thank you big time* to you and the other admins for all the work you do
> to keep KDE infrastructure running smoothly.
>
> Your work often is a lot less visible than the next shiny feature inside
> of Plasma or an application. It often happens in the background and may
> not be always thanked for at all, just cause no one notices to what
> extent it is your work that keeps all the services we take for granted
> running so smoothly as I do. I know how it can feel as I did quite some
> of similar work myself for some time.
>
> On top of that you and other admins responded to some requests of mine
> often quite quickly and even when it was just about re-open and fill a
> mailing list archive for kdepim / kdepim-users on own KDE's own
> infrastructure or some spam here and there. You did that on top of all
> the other work you have.
>
> So again, so that it really sinks in:
>
> *Thank you*
>
>
> In addition to that I ask everyone who responds to the more detailed
> mails to consider whether your answer will mostly mean even more work
> for the admins or whether it would actually help to reduce some of the
> workload. Please think a moment or two how you can make is easier for
> the admins to ease reduce their workload instead of adding even more
> work on top of it.
>
> I considered to offer some of my time to KDE admin work some times ago,
> but so far did not do that step out of the fear that I would easily be
> swamped by work then while leading an already very busy life and
> struggling to achieve some of my most important goals. And knowing how
> challenging it can be for me to say "no"… I rather did not offer help,
> even tough I would consider myself qualified enough for this kind of
> work, beyond a little collecting of some mails into an archive so far or
> so.
>
> I see your mail as a call for help, a call to have your workload eased a
> bit, Ben. I thought you would only be writing this in case you struggle
> with the current workload. And I can easily imagine that you do.
>
> All I ask everyone for is some respect for that, some respect for the
> often unseen work you admins do.
>
> So again:
>
> *Thank you!*
>
> I appreciate your work. Big time.
>
> Best,
> --
> Martin
>
>
>

-- 
http://about.me/valoriez - pronouns: she/her


Re: Sysadmin Load Reduction: Project Specific Sites

2019-11-15 Thread Ben Cooksley
On Sat, Nov 16, 2019 at 4:37 AM Thomas Friedrichsmeier
 wrote:
>
> Sorry 'bout the noise:
>
> On Fri, 15 Nov 2019 15:51:07 +0100
> Thomas Friedrichsmeier 
> wrote:
> > 2) Can I retrieve the old screenshots, somewhere? Sure a bunch of
> > those could do with an update, but I'd still like to reuse most.
> > (Screenshots page is just a list of filenames, ATM).
>
> Never mind this part, an old local backup and archive.org have me
> covered on this front.
>
> I'd still much appreciate push access for me and Meik, though.

The error message you received indicates that you've tried to push to
git.kde.org, however the website repository is located on Gitlab
(hence why the push was denied).
You'll need to access the repository via
https://invent.kde.org/websites/rkward-kde-org instead.

As neither yourself or Meik have logged into Gitlab, it is not
possible for us to provision access for you to the repository at this
time.

>
> Regards
> Thomas

Cheers,
Ben


Re: Sysadmin Load Reduction: Project Specific Sites

2019-11-15 Thread Thomas Friedrichsmeier
Sorry 'bout the noise:

On Fri, 15 Nov 2019 15:51:07 +0100
Thomas Friedrichsmeier 
wrote:
> 2) Can I retrieve the old screenshots, somewhere? Sure a bunch of
> those could do with an update, but I'd still like to reuse most.
> (Screenshots page is just a list of filenames, ATM).

Never mind this part, an old local backup and archive.org have me
covered on this front.

I'd still much appreciate push access for me and Meik, though.

Regards
Thomas


pgpsCSBhEhtwB.pgp
Description: OpenPGP digital signature


Re: Sysadmin Load Reduction: Project Specific Sites

2019-11-15 Thread Thomas Friedrichsmeier
Hi!

On Thu, 14 Nov 2019 00:36:31 +
Carl Schwan  wrote:
> When this is done I can start the process to replace the current
> website (create sysadmin request to get repo with the correct
> namespace, create merge request to the ci tooling, and more). 

As I can see you've already done this. Thanks for your work, here! And
sorry for being so slow, myself.

Two things:
1) I've now tried to fix a few links, but I don't see to have
access(*). Could you please add me (and Meik)?

2) Can I retrieve the old screenshots, somewhere? Sure a bunch of those
could do with an update, but I'd still like to reuse most. (Screenshots
page is just a list of filenames, ATM).

Regards
Thomas


(*) Error message:

"FATAL: W any websites/rkward-kde-org tfry DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists."

Push  URL: ssh://g...@git.kde.org/websites/rkward-kde-org.git


pgp_KZxPuPQbf.pgp
Description: OpenPGP digital signature


Re: Sysadmin Load Reduction: Code Related Services

2019-11-15 Thread Alexander Potashev
пт, 15 нояб. 2019 г. в 15:46, Harald Sitter :
>
> On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev  
> wrote:
> >
> > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley :
> > > In the category of no longer in use, we have the compatibility
> > > generator for the kde_projects.xml file. This was introduced when we
> > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > > keeping services that needed to discover a list of KDE Projects
> > > functional.
> > >
> > > As we've since migrated to using YAML files within the
> > > sysadmin/repo-metadata repository for both the CI System and
> > > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > > checkouts) there shouldn't to my knowledge be anything still relying
> > > on this (aside from perhaps scripty).
> > >
> > > I'd therefore like to shut this generator down as well, along with the
> > > compaibility redirector running at projects.kde.org (given that it has
> > > been some time since we were using that site, and many projects have
> > > moved around in the virtual structure since then, making the redirects
> > > it is able to offer useless)
> >
> > Hi Ben,
> >
> > I am developing a new version of the "opensrc" plugin for Lokalize [1]
> > and it currently depends on kde_projects.xml. Of course I can add new
> > code to scan the Git repo instead of just fetching kde_projects.xml,
> > however it would be more complicated.
>
> https://projects.kde.org/api/doc/ specifically deals with this problem
> by abstracting the repo away behind a micro service.

This looks like another view of the data available in
kde_projects.xml, however the API is very limited. For example I can't
query repo descriptions using this API. Thus not helpful.

However if we were going to kill kde_projects.xml, are you sure
projects.kde.org/api/ would be still available and not shut down as
well?

-- 
Alexander Potashev


Re: Sysadmin Load Reduction: Code Related Services

2019-11-15 Thread Harald Sitter
On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev  wrote:
>
> сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley :
> > In the category of no longer in use, we have the compatibility
> > generator for the kde_projects.xml file. This was introduced when we
> > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > keeping services that needed to discover a list of KDE Projects
> > functional.
> >
> > As we've since migrated to using YAML files within the
> > sysadmin/repo-metadata repository for both the CI System and
> > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > checkouts) there shouldn't to my knowledge be anything still relying
> > on this (aside from perhaps scripty).
> >
> > I'd therefore like to shut this generator down as well, along with the
> > compaibility redirector running at projects.kde.org (given that it has
> > been some time since we were using that site, and many projects have
> > moved around in the virtual structure since then, making the redirects
> > it is able to offer useless)
>
> Hi Ben,
>
> I am developing a new version of the "opensrc" plugin for Lokalize [1]
> and it currently depends on kde_projects.xml. Of course I can add new
> code to scan the Git repo instead of just fetching kde_projects.xml,
> however it would be more complicated.

https://projects.kde.org/api/doc/ specifically deals with this problem
by abstracting the repo away behind a micro service.

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

HS