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?

reverted https://gerrit.wikimedia.org/r/293732 zuul: make mwext-mw-selenium non voting
in https://gerrit.wikimedia.org/r/#/c/293744/2

That didn't work, see https://integration.wikimedia.org/ci/job/mwext-mw-selenium-composer/3504/consoleFull , same symptoms no firefox can be seen in https://integration.wikimedia.org/ci/job/mwext-mw-selenium-composer/3504/artifact/log/Non%20existing%20item%3A%20Edit%20tab.mp4 .

I'm sorry I skipped that question.

Sorry I forgot the main part of the request, the other namespaces besides file system. Will upload a patch.

Done. sc-admins share the namespaces of all services. (Except the tmpfs which the task indicates isn't needed.)

Based on your existing production access, you should be given the nda group.

I got to it to create a new ticket. Is there a way to add a notice above the create ticket form without being able to edit the rest of the form?

19:08 < jynus> jzerebecki, as far as I can see, it is only affecting itself, and not other connections
19:09 < jynus> (the wikidata job queue executions)

I think this is not needed today as it does not affect users.

@Charlie_WMDE verified that the account matches the person. Yes he works for WMDE. I endorse his grafana-admin LDAP group request.

Thank you, Jaime.

Wikimedia ArchCom can sign off on a revocation for technical or social reasons

So who will review patches for this extension (no matter where)?

Please answer https://gerrit.wikimedia.org/r/291354 and T136176#2336494.

No security review bugs remain open until the extension passes.

Next one might want to look at the graph of established connections and connection attempts to the wikidatawiki master. Perhaps compare with the connection limit (even over a changing master).

Any variation in MediaWiki.jobqueue.inserts_actual.wikibase_addUsagesForPage.rate seems normal. So this can't be a sudden increase in pages rendered.
The change in rates noticed in T136598#2340678 is only temporary afterwards it seems to be similar to before again.
The rest of the db errors (not from wikibase_addUsagesForPage, e.g. https://logstash.wikimedia.org/#dashboard/temp/AVUIrz6-_LTxu7wlGH5_ ) seem to have a high percentage of them going to wikidatawiki.

The cause is .prop( 'dir', this.element.prop( 'dir' ) || 'auto' ); trying to set the dir property on the input field to auto which is not valid in IE11.

The error is only triggered when one of the labels is empty.

*sigh* I can confirm what you said in IE11 (without logging in). That worked when I wrote T136543#2339545.
There is an error when clicking edit: Invalid Argument in the jQuery prop method called from createTag() in jquery.ui.tagadata.js . I'm not aware of a change since then.

While T133144#2222515 has an idea what went wrong another idea would be that there is some bug that made dispatching not notice that it couldn't create jobs.
From "job queues were not able to be written to" I assume the EnqueueJob strategy with two job queues was not implemented. And instead there was one job queue and trying to insert a job fails because the redis server was a slave in read only mode (i.e. job redis were switched while crons were not yet). If that is what happened this can be tested in a mediawiki vagrant instance (it comes with the job queue using redis).

At about 2016-05-30 1400 addUsagesForPage job pop failed starts to show about 50/min and ok starts to have higher fluctuation than before.
The database that is being connected to is wikidatawiki, most of the connection attempts are from the job running for client wikis T136598#2340744.

Editing on test and beta is broken in worse ways for IE11. Maybe because of outdated Gadgets?

Editing labels on repo is now fixed in IE11.
It seems connecting a page on the client does not work on IE11, instead I get the new item special page on the repo.

The documentation even mentions options as a valid token, it would be nice to update the docblock in core.