This RFC has been scheduled for another round of public discussion on November 22. The discussion will take place on IRC in #wikimedia-office, at 2pm PST / 22:00 CET (21:00 UTC).
Minutes of the IRC meeting on November 15: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-15-20.01.html
@Addshore I guess the tests were removed because the methods are now deprecated, and wfDeprecated makes tests fail.
Wed, Nov 15
@MaxSem i'm curious. Do you have any links explaining these problems?
@Legoktm that sounds encouraging, thanks!
This has become critical for Wikidata - without PSR-4 support, we have to maintain long lists of classes manually in extension.json. That's pretty painful...
Mon, Nov 13
@Aklapper Please add me so I can a) reorganize the TechCom workflow and b) set up (a) workboard(s) for MCR work.
Sat, Nov 11
This RFC has been scheduled for public discussion on IRC on Wednesday, November 15.
Fri, Nov 10
When all the tests have been added, please rebase https://gerrit.wikimedia.org/r/#/c/375050/ to see whether the tests still pass.
OOh, this is moving quickly! Thank you, guys!
Interesting. I would have expected it to be a lot more than that.
Wed, Nov 8
Tue, Nov 7
We should also consider a solution that will only put the full ids on labs. We don't actually need it in production. Could be a separate table, kept up to day by a trigger.
Sun, Nov 5
Sat, Nov 4
Fri, Nov 3
@WMDE-leszek The approach looks fine, and should help. The question is if it's sufficient.
Clarified, as per T169266#3711464.
Why do we need JS to add a tooltip? How about just using plain HTML?
@Multichill wb_items_per_site is *always* items. So to get the full item ID, just use concat('Q', ips_item_id).
Decline as per discussion at the Hackathon in Leon, now clarified by T169266: Clarify recommendations around using FauxRequest.
Thu, Nov 2
Is this the same as T139012: Use index on rc_this_oldid?
Wed, Nov 1
@hoo we should really look into generating RDF from JSON. Can probably be done in a week.
Minutes from the IRC meeting: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-11-01-21.01.html
Mon, Oct 30
robots.txt is controlled by the WMF. Special pages are listed there because Special pages generally contain dynamic data, and should not be cached.
It would indeed be very useful to us of @hoo had this access.
Because they're POST they'd be handled as an immediate pass through the varnish layers, so I don't think this would cause what we're looking at now.
@hoo Sounds like we should just go ahead and do this! Don't forget to change dispatchingLockManager accordingly.
In any case, this would consume front-edge client connections, but wouldn't trigger anything deeper into the stack
something that's doing a legitimate request->response cycle, but trickling out the bytes of it over a very long period.
Sat, Oct 28
Confirming that this RFC will be the topic of the IRC discussion on #wikimedia-office on Wednesday, November 1str. Note that this will happen at the usual time for the US (2pm PDT), but one hour earlier than usual in Europe (22:00 CET).
Wed, Oct 25
Tue, Oct 24
@hoo I agree that it's not pretty - it's an optimization following the most common usage pattern. That tends to be messy. But it may allow us to ignore a good 90% of sitelinks changes, one of the more common kinds of edit...
Commons very often links (in the page content) to other Wikipedias.
Mon, Oct 23
@Yurik Yea, good to hear from you!
Why are you asking me?
@debt if you want me in for the technical perspective, please send me an invite. PLease note that next week is Daylight Confusion Week: for a week, we are only 8 hours ahead of your instead of the usual 9. Should make it a little easier to find a meeting time :)
@Jdlrobson gave me his perspective on the matter as follows:
@Yurik Do you feel like having this discussion again? On Wednesday, 2pm PDT?
@hoo Access to "other" sitelinks is widely used? How/where exactly? Note that for the purpose of sitelinks, Wikipedias are considered to be in the same family as Commons.
I updated the task description with more detailed information. I dropped the "introduce API for registering usages". That seems really scary. I'd want to have a much clearer idea of how that would work before we consider it as a viable option.
@Joe To clarify, these parameters are for ops to tweak. I can guess at good values, but this is really your department, I think. From the Wikidata perspective, the batch size for purge jobs doesn't matter. You can set it to whatever you think is sensible.
I have thought a bit about ways to mitigate this. Here are three things I think could help:
- T178804: When processing changes to Wikibase SiteLinks on the client, only trigger updates for sitelinks that are actually shown in the sidebar. (doable in a weeks or two, if prioritized)
- T178806: Wikibase: Batch HTMLCacheUpdateJobs across changes (doable in a weeks or two, if prioritized)
- T178810: Wikibase: Increase batch size for HTMLCacheUpdateJobs triggered by repo changes. (doable now, it's a one line config change)
For the record:
I personally maintain the position that application logic should not be bound to an external API (circular dependency), and that the interfaces used by application logic should be as ideomatic as possible (no stringly typed interfaces, no amorphous interfaces).
@MaxSem @EBernhardson: Jon indicated you may have an opinion on the use of FauxRequest. Can you take part in the IRC discussion on Wednesday 2pm PDT? If not, can you explain your position here, in a comment?
Fri, Oct 20
This RFC has been scheduled for public discussion on IRC on Wednesday, October 25.
Last Call: as per the RFC discussion on IRC on October 18, this enters the Last Call period. If no pertinent concerns remain unaddressed by November 1st, this RFC will be approved fro implementation.
As per agreement in the IRC meeting (see above), T178538: Bump PHP requirement to 5.6 in 1.31 enters Last Call instead, and this RFC goes on the back burner for now.
Minutes auf the IRC meeting: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.html
Thu, Oct 19
Final schema version can be found at https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema and https://gerrit.wikimedia.org/r/#/c/378724.
I added tracking for the number of discarded recentchanges entries to the WikidataClient change handling dashboard, see https://grafana.wikimedia.org/dashboard/db/wikidataclient-change-handling-wikipageupdater?orgId=1
Ok, let's target November 1st then.
Oct 18 2017
@Samwilson TechCom is considering this RFC for public discussion next Wednesday, October 25, at 2pm PDT. Will you or someone else involved with this project be available on IRC?
Oct 17 2017
Oct 16 2017
@Ladsgroup which fix?
Oct 12 2017
Perhaps this can be implemented directly in the UsageAggregator.
Looking at things like https://commons.wikimedia.org/w/index.php?title=File:Vincent_Willem_van_Gogh_110.jpg&action=info it seems like we really should get this done ASAP.
@jcrespo I fully agree to use create© instead of altering tables. This has been part of the design all along, altering existing tables when introducing MCR was never the plan. We'll create new tables, copy information, and stop using some fields in the revision table. If we want, we can at some point drop these fields from the revision table. But it's no problem to just have them sitting around.
@eranroz I see no blocker, T151717#3675687 is only relevant for enabling per-property statement usage tracking, which has a separate feature switch. Avoiding X tracking when no statements are used, but only labels and/or sitelinks, would still be very helpful. There is potential for increasing the usage tracking table (because we may track L.de and L.en instead of just X), but I don't expect that increase to be explosive - and it should be offset by a dramatic reduction of inserts into recentchanges. We should have an eye on it, though.