never mind, got confused

duplicate

Bumping to high, since this blocks 1.34

Bumping to high, because this blocks 1.34

Then, perhaps it would be easier to not use a replica in this test and/or disable post-send optimisations in MW

So, Chronology Protector appears to do something, but tests still fail when the replica is lagged. Needs more investigation.

Removing from sprint board. This isn't ready. Needs breaking up. Also, this doesn't block the schema migration for the revision table. It affects the page table instead.

If you put the title in the URL then you are back to the same place with inability to support IMS revalidation.

In T231580#5527638, @eprodromou wrote:

We were discussing title in the output! I'm not crazy about requiring a title in the URL, since it's requiring the client developer to provide data we don't actually need to get a unique diff. (We can do that with just the two unique revision IDs.)

pinging @Anomie to have a look

In T232485#5527928, @eprodromou wrote:

I updated to note that we'll set the Deprecation header.

@kostajh ok, thank you! yes, that is very helpful!

In T231580#5522820, @eprodromou wrote:

2. I don't want the slot name in the URL. For now, we are comparing the main slot. I've updated the URL template back to the original.

Brief discussion at the TechCom meeting indicates that there are unresolved issues, in particular wrt the fact that qunit tests are being used in different ways be different extensions and core. @Krinkle can probably provide more detail. It's unfortunate that @Milimetric is currently unavailable, since he seemed to have thoughts on this as well.

In T230211#5523863, @Krinkle wrote:

It's specifically about the storage not being the very database that we're tracking its replication position of. This is a paradox.

In T232485#5507155, @eprodromou wrote:

Since we're proposing this for full discussion, I've changed the version from 0 to 1, so we don't have to go through this exercise again. As an added benefit, many of the other APIs have "/v1/" as a prefix, so it should trigger everyone's pattern-recognition.

In T232485#5523639, @eprodromou wrote:

@Joe I think that's definitely a downside to having extensions write into their own namespace.

I don't see a way to have it both ways.

@Legoktm asked on the talk page:

What's the advantage of having a separate policy for this? Why not integrate the new stuff into the existing deprecation policy?

In T193613#5506792, @dcausse wrote:

Some comments/questions:

• unstable vs internal: should unstable/experimental be considered as "use at your own risk" (or alike) instead of "do not use outside the module"

...looking at the picture, I see a lot of calls to Title::newFromId, and RevisionStore::loadSlotRecords. Both should not be called much when RevisionStore::newRevisionsFromBatch(). It's designed to avoid exactly this. So either there is more code that needs to be changed to use newRevisionsFromBatch(), or there is a bug that prevents the optimization from being effective.

In T228675#5522097, @Nikerabbit wrote:

Here is a profiling visualization. Do note that this was taken with Ib33b4afc14f1098 cherry-picked on top of my optimization with reduces use of Title::makeTitleSafe (T230100). Still it manages to be about 20x slower.

Looks like this is done.

Moving to clinic duty, to confirm that this is (not) a thing.

Assuming this is no longer relevant, since we are moving away from HHVM, and no longer support it for future versions of MediaWiki.

Assuming this resolved itself with parser cache expiry. Please re-open if this is still a problem.

Doesn't seem to be "high", since nobody has cared for a while.

Do we really want the installer to silently skip extensions that have missing dependencies? Shouldn't it rather show a warning?

Pinging Editing-team, since they apparently own the extension.

Why this solution rather than implementing proper PHP serialization in RestBagOStuff so $_SESSION and corresponding Session functionality works like everyone else expects it to?

In T213478#5517007, @Daimona wrote:

Yes, it wouldn't perform really well. OTOH, the maintenance script has:

SELECT rev_text_id FROM revision

and

SELECT ar_text_id FROM archive

which are equally, if not more expensive.

In T213478#5516417, @Daimona wrote:

But well, reading it again... Would it be enough to just add a hook as proposed above? Something like 'PurgeRedundantText', and extensions may provide a list of IDs to spare. For, AF, it would be something along the lines of:

In T228675#5516794, @Pchelolo wrote:

All of the above are addressed by the existing patches.

Bumping back to inbox, since this got tagged for the 1.34 release, which makes it urgent.

I just realized that old_text and old_flags are also referenced directly in a couple of places. That needs to be fixed as well. Search:
https://codesearch.wmflabs.org/search/?q=%5B%20%27%22%3E.%3D%5Dold_(id%7Cflags%7Ctext)&i=nope&files=&repos=Extension:Translate