Running it now.

I will try to implement this but one thing is that if a user is experienced, they should have auto patrol right and they would be automatically excluded.

It hasn't been written into in dewiki for a couple of days now:

root@db1183:/srv/sqldata# ls -l */flaggedpage_pending.ibd
-rw-rw---- 1 mysql mysql 6291456 May 30 20:17 dewiki/flaggedpage_pending.ibd

I haven't seen any complaints or bug reports regarding this change. It's good to go.

It's because the columns depends on the election. You might have a different criteria that could not be fit inside the table.

https://lists.wikimedia.org/postorius/lists/u4c.lists.wikimedia.org/

"Get short url" widget is also not going to dark mode: https://test.wikipedia.org/wiki/Ruine_Th%C3%BCrndl?vectornightmode=1 (click on "Get shortened URL")

Flow will be undeployed soon. I'm not sure it's worth working on. Just my 2c.

@Ottomata thanks, I'll take a read, totally agreed we should collaborating on shared needs more.

I'll get it done on monday.

https://lists.wikimedia.org/postorius/lists/wikiclub-toronto.lists.wikimedia.org/

That's good enough. Thanks. I create it soon.

Sure. Only Polish Wikipedia or all wikis?

Hi, I'm not seeing any meta page about this club. Is it done by Wikimedia Canada?

We can. But we are not allowed to disclose them. Did you send the email to wikija-g-owner@lists.wikimedia.org?

@Kallichore With the next train, you will have a better view of pages needing review.

Yeah, basically what Jaime said. Currently we have these information is in puppet and putting it in database require many moving parts (e.g. giving access to that database via an API to sanitarium hosts to filter private tables). Also it's not 100% known that it'll be too large. In this example above every table has four to six lines and we have around 200 tables in production (for mw), that's around 1,000 lines that is not small but not too large either. In other words, first we need to build the platform and the system, if we realize this part or that part doesn't work, we can pivot to a more complex solution. I want to avoid unnecessary complexity of setting up a database and APIs to serve it and so on if we don't need it.

Making the fix isn't that hard, I can backport it if you manage to get it done and land it.

FWIW, there are two of me on the list: https://wikimediafoundation.org/role/staff-contractors/#technology

Last time we deployed this to testwiki, a user without NDA (who got office banned later) got access to PII data. Just asking to be extra careful putting people into this group or revert it once you're done testing

I suggest just compressing anything that's above some certain threshold (like 1GB)

Sure

I'd be great if you wait for the T352010: Gradually drop old pagelinks columns too. I'm about to start the schema change on the PK in s2

Hi, can you pick a name that's more aligned with our standardization policy? https://meta.wikimedia.org/wiki/Mailing_lists/Standardization if it's not possible, we need to come up with a naming scheme for such mailing lists.

All members of our user group suddenly had their admins removed in March.

We can anchor that link to subsectio of the page (via adding #mw-pageinfo-header-properties) Would that help in your case? e.g. https://de.wikipedia.org/w/index.php?title=Rosy_Wertheim&action=info#mw-pageinfo-header-properties

Thanks!

Now puppet is flowing again. You can see my hacks in https://gerrit.wikimedia.org/r/plugins/gitiles/cloud/instance-puppet/+log/master/deployment-prep/deployment-cache-text08.deployment-prep.eqiad1.wikimedia.cloud.yaml
deployment-cache-upload08 had the same issues and more (IPIP), which also you can see my hacks in https://gerrit.wikimedia.org/r/plugins/gitiles/cloud/instance-puppet/+log/master/deployment-prep/deployment-cache-upload08.deployment-prep.eqiad1.wikimedia.cloud.yaml

I prefer it to start from the right. i.e. start of the page (which would be left in LTR languages). The buttons can stay at the end of the page but text feels wrong to stay like this.

It's not too annoying to me but since start of the sentence is at the middle of the page, it feels wrong to me as a native speaker, specially since the counter is in latin digits (in Persian and some other languages the digits are different e.g. instead of 0 it's ۰, 1 -> ۱, 2 -> ۲, etc.) and generally numbers are read left to right even in Persian.

I want to put a screenshot but beta cluster is down

In T317180#9819165, @Krinkle wrote:

Might be a good candidate for a "structure" test with PHPUnit. This would be similar to what we do with autoloader, config artefacts, and other generated files in core.

I close this \o/ The subtickets are for the further work.

That query is wrong, JOIN pagelinks ON pagelinks.pl_target_id = page.page_id won't work. pl_target_id is not FK to page_id, pl_from is but it depends on your usecase.

We could not find a way to fo "left" using Wikimedia ORM and we used "SUBSTR" instead. Is that ok? or can you suggest a better method to use

Hi, I responded in the patch. hope that'd be useful for you.

Honestly, I think this should be declined as this is a x/y problem. I understand you need to see content of the whole law in one place, but that doesn't mean size of page should increase. A proper solution here is to have a way to see a full book or set of pages in one place. Think of google docs or a PDF file. That is doable but needs to resourced and prioritized and implemented. That can be useful in many other areas too (being able to read a large book in a way of "infinite scroll" on the wiki)

Does reducing the key sizes (from 256 to 128 for AES and 386 to 256 for SHA) sound good to people? We can deploy it temporarily and measure the impact.

Awesome thank you!

While non-Latin characters take twice as space, since Arabic and Hebrew scripts don't write short vowels (unless for children or disambiguation), the average letter per word is much lower than Latin scripts. In other words, even if you translate it to English, it'll just go above the threshold.

In T275319#9813641, @Fuzzy wrote:

I wish to avoid the discussion what "should be" the limit of the page length, in characters.

Yes. s5 wikireplica needs to actually get the alter (will be over in an hour) and then a run of maintain views. Be patient. It will be resolved soon.

A possible solution to this problem is this: T365303: Move update of category members count to CategoryMembershipChangeJob

Yeah, this would fix that bug automatically but maybe it's not a good solution. Depending on what mediawiki team thinks about this.

Okay cool. Thanks for checking.

In T365327#9811326, @Vgutierrez wrote:

Chacha20 is faster than AES when both are running without hardware acceleration. If AES-NI is present, AES is faster. This is also considered by clients to choose their ciphersuite suite to be sent to the server as part of the ClientHello

Stupid note: In my phone, it still prefers AES256. Maybe my client for whatever reason doesn't support ChaCha20 or it thinks it's strong enough to just go with AES instead. But I will try to confirm SSL_OP_PRIORITIZE_CHACHA is working.

Just to make it clearer, ChaCha20 is still that's not my preference. I prefer simply reducing the key size for AES and SHA instead.

I should have been clearer, Meta prefers it everywhere including desktop. It's the top of ciphersuite by default including where it's not the top of client's cipher suite too. Maybe because fb/instagram is heavily targeted for mobile users.

We can also consider preferring ChaCha20 everywhere as well like Meta websites.

Also noting that I'm talking about the lock in ::acquireAndInsertTerms() and not the one on ::deleteTermsWithoutClean() as the latter happens much less frequently and doesn't lock contention from what I'm seeing.

I agree that the pruning part needs to be rethought and revamped but I'm failing to see how it's connected to this problem. This is explicitly about locking the rows in wbt_item_terms which is the head. Let's say for Q1234 you have this:

+------------+--------------+----------------------+
| wbit_id    | wbit_item_id | wbit_term_in_lang_id |
+------------+--------------+----------------------+
|  767752395 |     1234 |                    5 |
| 6682347558 |    1234 |                  172 |
|   95594787 |      1234 |                  192 |
|   34102141 |       1234 |                  237 |
|  561818268 |     1234 |                  274 |
+------------+--------------+----------------------+