Hi @BTullis, thanks, I appreciate thorough checking. @Anton.Kokh has indeed mentioned Superset access as an immediate need, but the lived practice at the WMDE is that people end up running queries via Jupyter regularly.
So stat host access would be good.
I don't think Anton would be directly managing data pipelines, so airflow-wmde-ops membership does not seem necessary at this point.

@Jelto mind taking a look and confirm that our understanding of https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/modules/profile/templates/query_service/ and related config being not used anymore?
Or is it actually still used for the Commons Query Service still?

@Physikerwelt @Tacsipacsi note that the option I am looking at understanding here at WMDE is about "consolidating" those github repositories into main Wikibase repository, as, among other things, those "libraries" do not have any other use outside of Wikibase AFAICT. Therefore different "code hosting" (WMF Gitlab, github, etc) options discussion is not really relevant for the time being

Thank @herron, missed part of the template it seems. It is about a time-limited contract. Updating task description

Me having opened this request does indicate that I approve this request on WMDE's end.

I figure @AndyRussG_volunteer also needs to be added to nda LDAP group. I believe their account has been there, so maybe there's still a trace of NDA on record - I do not know what is the procedure here, but WMF SREs surely do

Let us confirm how problematic would be for us to move those repositories into Gerrit. I'll be back (with some details)

Hey @SLyngshede-WMF - I have approved for WMDE above T395917#10880432

Thanks @SLyngshede-WMF - approved on WMDE's behalf.

I approve this request on WMDE's end.

I approve this request on WMDE's end

seems it has happened in https://gerrit.wikimedia.org/r/c/wikibase/termbox/+/972533

Thanks to @Jakob_WMDE I've realized I had misunderstood what was going last week.
Given our change enabling making use of QUIBBLE_OPENSEARCH flag in Wikibase code had api tests job run successfull with the new zuul behavior, as you were kind to demonstrate @hashar in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1140156/8#message-db11aec2684ab701ade825c4a012b65f152c21c7, the Zuul/CI part was all done. What I missed to realize that the Wikibase CI code should have been merged ASAP.
So we will now get Wikibase change merged, as it is clear it will work as intended, and then re-request the change in Zuul. No need for additional non-voting jobs. Apologies for the noise.

I've managed to replicate the failures by running quibble locally. Notably, those test fail due to API unexpectedly responding 200 instead of 415, when running quibble from image docker-registry.wikimedia.org/releng/quibble-bullseye-php81:1.14.1, but pass, as they did until May 14, when using image docker-registry.wikimedia.org/releng/quibble-buster-php74:1.14.1. Reason unknown yet.

Likely caused by enabling Opensearch (fka Elastic) in [Wikiabse apitests](T386691):. Revert for the CI config change that turned it on: https://gerrit.wikimedia.org/r/c/integration/config/+/1146520

The current condition match solely integration-quibble-fullrun-opensearch which was used to tests the patches send to integration/quibble.

thanks @hashar! Do you mean like in https://gerrit.wikimedia.org/r/c/integration/config/+/1145213?

thanks @colewhite . The code in question does not load mediawiki's JS and directly talks to beacon/stats but the prefix limitation sounds convincing enough. We'll check this out

On WMDE's behalf I approve this request, and confirm @Lena_WMDE is who she claims to be.

Thanks for the checklist @Aklapper . I wonder however, what is the purpose of emptying the repository, instead of only marking it (README etc) that is archived and not active?