User Details
- User Since
- Oct 10 2014, 8:08 AM (467 w, 5 d)
- Availability
- Available
- IRC Nick
- dues, duesen
- LDAP User
- Daniel Kinzler
- MediaWiki User
- DKinzler (WMF) [ Global Accounts ]
Yesterday
The NetworkAuth extension would cover the need, though we'd likely want to trim it down a bit for production use.
Mon, Sep 25
testing of the RESTBase endpoint /data/lists/{id}/entries does not show these additional fields actually being included in the response, although review of the code suggests they should be there. The reasons for this are currently unclear.
If we do need some other combination of SQL and data built around a binary operator, another method would be needed.
Fri, Sep 22
Note that there are two options:
- call the parsoid endpoints exposed by the extension
- call the page endpoints exposed by core
Thu, Sep 21
Wed, Sep 20
This could be a problem... To put this in perspective, I dug around and made a histogram of how many different projects are references from individual reading lists.
Some ideas:
Tue, Sep 19
Looks like the summary isn't actually used by the app, see T346739.
A quick update on the status of the retrospective process: We have concluded the survey and had two listening sessions last week. We are currently evaluating the survey response and deciding whether more listening sessions are needed.
Mon, Sep 18
Thanks for looking into this @BPirkle! What you write mastly matches my own superficial understanding.
Thu, Sep 14
Wed, Sep 13
Tue, Sep 12
After some discussion, we collectively realized that WikiPage::doPurge will invalidate all relevant parser cache entries, and any resource-change event emitted by it applies to output of parsoid and the old parser alike. This makes it a lot easier to reason about things, we don't have to worry about when things actually get written to the parser cache.
Mon, Sep 11
Thu, Sep 7
I support this idea. I can't think of a situation where the current behavior would be required. The check can still be bypassed using RevisionRecord::RAW if needed.
Mon, Sep 4
It would be nice to resolve the underlying design flaw that caused this issue. I added a comment to the patch with some thoughts.
Wed, Aug 30
The now not-really-stateless back-end service
The idea sounds good, but I have no idea whether it's practical.
Tue, Aug 29
re polymorphic modeling: I not that we have the same problem with the ipblocks_restrictions table, where the ir_value field may reepresent a page ID or a namespace ID.
In this context, please note that we are relying on the assumption that there can only be a single active block in some places. In particular, when we want to provide information about the block of a given user, we just look at the most recent block log entry for that user. There is no good way right now to list all active blocks for a user and provide all relevant details about each block, because some of the info is in the block itself, and some is in the respective log entry. If we can have multiple active blocks for a given user, we should have a better way to link block log entries to blocks.
Aug 25 2023
Parsoid cache warming has been enabled everywhere for a couple of months now.
Resolved by increasing processing concurrency for the cache warming jobs.
We have been using the new backend for a couple of months now. It has been working fine.
Aug 24 2023
I find the term "IP masking" really misleading, can we rename the task so it talks about "automatic temp accounts" or something?
I like the idea of having DeferredUpdate act as a simple extension of the PHP runtime. However, its current implementation integrates with the per-wiki DB LoadBalancer instance. That logic would need to be factored out of the DeferredUpdate class. I added a comment on the patch with some ideas around that: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/951187/34#message-52b48595021e45b8f6c39f78a1bffd50feb88808
Aug 21 2023
Aug 17 2023
Aug 16 2023
Jul 28 2023
Ping @FJoseph-WMF: we need some kind of intake process for this kind of thing...
Jul 26 2023
The experiment of disabling parser cache writes in the parsoid endpoints was successfull: the jobrunner cluster can handle the load of doing all the parsoid re-parses on page edits without the help of the parsoid cluster. To achieve this, allowed concurrency for the parsoidCachePrewarm job had to be increased significantly.
I have not looked at the details, but the only recently merged change that seems potentially relevant is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/935921 by @tstarling.
Jul 24 2023
- Risky Patch! 🚂🔥
Jul 20 2023
Stalled for now, the plan is to come back to this in a month or two when we have team priorities sorted out.
Jul 19 2023
Jul 18 2023
I made a patch that shows how I think this should be approached.
I have no way to safely test this. @Ladsgroup do you have thoughts on how to figure out if this works, without breaking stuff?
Bumping to "high" since this is blocking the deployment of wikifunctions which is scheduled for next week.
The offending code is: