Seems no one else hat a problem with it.

I want to clarify. One thing I am certain about was that the APG grant was referred to. One example of what I said before was the recent deployment of the RevisionSlider extension, I was told explicitly that the WMF should, would and agreed to handle Security and RelEng tasks including deployment related to it.
Can you point to the explicit communication regarding the expectations? Can you point to explicit communication of confirmation of it by WMDE management? That would make it easier for me to point out mismatches.

(Have someone with access double-check which mediawiki.org account that the manager's Phabricator account is linked to, where the SUL account was created, and how it was created on that wiki.)

I think addshore personally is trustworthy for production access.

Adjusting priority to what I perceive to be the actual demand. Sorry, overestimated the amount of my free time.

According to my information you pinged the wrong people. I'll instead refer you to @Tobi_WMDE_SW .

I thought I had used some of these teams because I added users to the org to give them credit and that way I also remember why I added them. (Mirroring of credits from gerrit to github, where the team mirrored a gerrit group. But not conveying any rights on github as code review happened on gerrit. If you are not connected to the repo on github e.g. via an org you don't get credit even thought it is the same email.) But if they where empty I guess they were not actually use ful.

Yes, dpatrick his account dap only installed webhooks into repos.
The account in question then is wmfphab, see also T118946 related to it.

Seems I posted this to the wrong task:

In T137970#2436623, @JanZerebecki wrote:

I would be interested in doing this. But it probably takes at least a week for me to be able find the time (need to switch my computer among other things) and it is unclear at this time how much time I can invest in the future. I would be interested in training someone who actually wants to do this, but in the past I couldn't overcome the obstacles.

In T138943#2433625, @Addshore wrote:

In T138943#2433453, @JanZerebecki wrote:

As the above comments explicitly request that it not be included on testwikidatawiki then it will not be.

I did not find such an explicit request.

See T138943#2418599

The cryptography part specifies a technical solution. What is the reason or goal that lead you to specify it?

make business logic that does not know or care about UI or web API

Just tested it on beta wikidata, seems to work.
"Needing to move on" nor a time plan is a reason for overriding the requirements for deployment.

If they are done then why are they not closed?
If jenkins fails the extension then it should not be branched.

T133278 still has open patches.

Can't find the checklist right now. But I think as a beta feature needs at least a time frame for undeploy or graduation to a normal feature.

I currently have problems deploying jjb changes.

The build should be fixed instead, to make this work as intended.

What is the difference between a and b?

What is the goal here?

s3fs and rsync?

In T138708#2426549, @daniel wrote:

In T138708#2424766, @JanZerebecki wrote:

Why use a sha1 instead of inlining the normalized serialization in the text to sign?

Because that doubles the size of the serialization of a statement.

Would that part need to be stored?

I would suggest to store it. It's also possible to reconstruct it.

If the sha1 is used how do you reconstruct what it was composed of?

By normalizing the serialization of the statement of the revision in which the signature was added.

Why omit the revision ID of the predicate/property?

After inspiration from many, I think there is a way to entirely remove gating in favor of test jobs after patch upload and jobs after deployment-prep that is not worse in outcome. However that requires substantial changes to mediawiki development, testing, integration, registration and deployment. AFAIK nobody yet has automation for all the additional manual work that would require (even for other software stacks). Some automated tracking that would ensure that the outcome is not worse in the sense of leaving stuff behind might be a good idea. That tracking could be tried on one of the stacks that we already use that are also lacking that tracking.

See also Lydias comment in https://gerrit.wikimedia.org/r/#/c/297127/ .

Interesting, maybe this can lead to a distributed truthy bubble (see [:w:en:Filter bubble]), where the user can chose instead of someone else.

The lanyards and the labeling and placement of the no photo areas at the recent Wikimania where an improvement over the devsummit. Just to reference overton frame, my feedback is not related to the actual topic of this ticket.

Those server aliases where missing, I amended the patch to add them.

It was not about the first one.

Now echo 'error_reporting(-1); echo $foo;' |mwscript maintenance/eval.php testwikidatawiki 2>/dev/null does not print the notice.

A configuration in LocalSettings.php. WikibaseMediaInfo is where this would be needed, it currently works around it by not using the namespace part of extension.json.

Thank you.

We do not support Firefox 45 in the "Modern" grade, but according to https://www.mediawiki.org/wiki/Compatibility#Browsers it is in "Unkown".

In T137224#2388330, @mmodell wrote:

Greg: I guess https://gerrit.wikimedia.org/r/#/c/294867/ supersedes the others.

Please reopen if more is needed.

To make it fancy one could make the publisher a nodepool instance that is special in that it has secrets for object storage or certain git repos. Make it push the result of the doc generation to the object storage or those git repos. Then run a kubernetes service that either requests the docs from the object storage or pulls the git repos when triggered by a doc publishing being finished. I mean this more as food for thought, as I'm sure a few of the mentioned pieces can be removed without impacting the result.

Thank you for the clarification that answers my question, as such I don't want to give the impression to contributors that any review of patches will happen anywhere I know of. As ori on the patch, I also prefer https://gerrit.wikimedia.org/r/#/c/290379/ . @Jhernandez can you revisit your -1 ?

This should probably be included in the next core security release.
It seems people need to be individually subscribed to an access restricted ticket.

Isolating it from Jenkins in some form is a good idea. If zuul and nodepool are moved to labs would that make the whole CI more unreliable?

@mobrovac Can you review if the patch would solve your request?

While T137323#2365101 is important. I don't understand T137323#2368164, what exactly do you mean with private lan?

Is it correct that zuul can not be clustered? I.e. there can only be one and there is no failover/handover in its architecture?