Thu, Apr 2
MW should have the lowest limit, because it can deliver the nicest error messages. So I would increase the php-fpm CPU limit from 180s to 201s, not 200s, matching the WT limit. The idea is that the MW time limit will expire first and will deliver a nice error message, and it has 1s of grace to do the error message delivery.
Tue, Mar 31
Mon, Mar 30
Wed, Mar 25
I agree with @Krinkle, I don't think rights should be used in this way. There were no objections to closing this in the TechCom meeting, but I note that we didn't have a quorum, so I'm closing the task on my own authority.
Sounds good. Feel free to do a global search and replace -- I think that's an easier way to update the auto-generated interfaces than running the script again.
Tue, Mar 24
Thu, Mar 19
Tue, Mar 17
I looked at the logged keys again. The top key from 20:13 by request rate was WANCache:t:arwiki:gadgets-definition:9:2 (by a small margin). This key appeared very rarely in log messages from another day. It's just a timestamp key, but it's fetched using getWithSetCallback() with a check key, which means that the timestamp key and the value key would have been requested together with getMulti(). The value would have been 82658 bytes, consistent with the chunk size above.
We do have detailed statistics for the memcached instance, which shows that the traffic originated from memcached, not redis.
I tried pulling out the top 100 keys by error rate from that second, but nothing really stood out. So I tried multiplying the request count of those keys by their current size in memcached, but it was still uninspiring.
Mon, Mar 16
I used admin requests to verify that out of 10 selected log entries from 20:10:36, all 10 were associated with mc1030, consistent with saturation of its outbound networking at the time.
There was a spike in network transmit rate on mc1029 and mc1030 at the time in question. The other servers did not show such a spike. So it may be a small number of keys with large values being frequently requested.
Sun, Mar 15
OK, let's not do type hints just yet.
Fri, Mar 13
Thu, Mar 12
It is intentional. Sorry, I should have used different classes for the type declaration and the instantiated class to make this clearer. Let me just use the names from the actual test failure:
Wed, Mar 11
Tue, Mar 10
The ES clusters which are not currently being written to have read-only mode enabled in MariaDB, so you can't modify them in any way. They also don't have replication running. So ES is managed by the DBAs as an append-only cluster, a strategy which is enabled by the restricted API presented by MediaWiki. Presenting ES as an append-only store provides some flexibility for implementation options which would not be there if we allowed deletion and update.
Mar 6 2020
I suppose we also need type hints, not just doc comment types. The RFC did promise "strong types". I'll add something about that. I think we can just say that every documented class type also becomes a type hint.
Mar 4 2020
Mar 2 2020
I added Polishdeveloper to the mediawiki group in Gerrit.
Your question was a bit of a rabbit hole. I think I will file a separate bug about general refactoring of file deletion and undeletion.
Feb 28 2020
Feb 26 2020
For T240307 I really need a list of every inappropriate reference parameter. Ideally this would be indicated by some special syntax in hooks.txt, like [&]$editPage instead of &$editPage.
Feb 13 2020
Feb 11 2020
Feb 5 2020
Jan 30 2020
Make Action::factory() and Action::__construct() take an Article as a parameter instead of a Page. Codesearch suggests that only Flow will be broken by this, requiring a simultaneous update.
Jan 29 2020
Jan 23 2020
In a meeting, @daniel convinced me that there's not much to gain by making SelectQueryBuilder be a value object as opposed to having IDatabase act as a factory. It's likely that anything that constructs a SelectQueryBuilder will also need access to an IDatabase, at least for addQuotes(). If IDatabase is a factory, then SelectQueryBuilder can potentially be extended in future with expression builder functions that depend on addQuotes() etc.
Jan 21 2020
Is it easier to accept a context-sensitive useIndex() function if you consider it to be effectively appending to a query string?
Jan 20 2020
A goal I have is to try to put table options close to the tables they serve. So far, I have formal parameters:
We could always have an interface that returns a partially filled SelectQueryBuilder, with empty conditions. I'm not sure if it's worth worrying about right now. The low hanging fruit is one-off queries that aren't part of any larger query building system, and direct callers of Database::select() like QueryPage::reallyDoQuery(). I mentioned getQueryInfo() because it's a good analogy, I'm not planning to get rid of it immediately. The point of introducing SelectQueryBuilder is to split a useful concept out of ApiQueryBase so that it can be used in pure backends.
Jan 17 2020
Jan 15 2020
There is https://pecl.php.net/package/re2 . It was written for PHP 5 and was never updated after its initial release in 2011, but we have the skills to update it for PHP 7 and review it for security. If we believe in RE2 then we shouldn't be afraid to invest in it.
Jan 8 2020
Task description edit: I came up with a pretty neat and simple hook deprecation system, slightly different to what I proposed in the comment above. See what you think. It doesn't need core to be aware of the deprecation chain, it just needs a list of deprecated hooks.
Task description edit: remove the term "listener" and move hook interfaces into the namespace of the caller.
Jan 7 2020
Dec 17 2019
Dec 16 2019
Dec 12 2019
apcu_fetch() copies the data out of shared memory instead of referring to it. So it's slower than opcache or HHVM's APC. Large arrays are especially slow since allocator calls are needed for each array element.
Dec 11 2019
It's true that the performance implications would be concerning if the plan was to migrate all extension hook classes to use DI without splitting them up. I think existing massive hook classes in extensions could initially continue to use MediaWikiServices::getInstance() but switch from static functions to non-static functions with interfaces. That way, they get documentation and strong typing, they just don't get DI for now.
Dec 10 2019
That change weakened the rationale for having a centralized HookRunner class for all core hooks, do you think I should reconsider that?
Dec 6 2019
Dec 4 2019
I mean, you could just directly contact your local friendly Gerrit admin. If that admin is me, I don't really need a task, I'm happy to just act on an email or IRC message, as I did in this case. For other administrators, whether a task is needed would depend on their workflow. In Gerrit-Privilege-Requests we now have a workboard in which you can flag tasks as being ready for administrator action. That would probably be a good workflow for this project as well. But for onboarding, it's potentially slow.
Dec 3 2019
Done. Note that the "expedited process" states that it is not necessary to file a Phabricator task. I would not recommend filing a task.
VisualEditor logs the failure response from RESTBase, e.g. https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-mediawiki-2019.12.03/mediawiki?id=AW7JwbdXKWrIH1QRemDK&_g=h@44136fa
Nov 28 2019
As I wrote on Gerrit, the proposed fix may not be ideal: delaying the scroll causes visual flicker even in browsers unaffected by the bug, and the time before scroll may need to be very long to be reliable.
keys.txt only has my 2008 and 2009 keys, since that's when I was doing MediaWiki releases.
I strongly disagree with the idea of forking an extension just because the sole maintainer went away. That's not how open source projects are meant to work. The open source license grants the rights to continue to work on a project. I think the MediaWiki community in general owns MediaWiki extensions and should not need permission from the original author to continue work. The idea of a "chain of trust" is the exact thing I was arguing against when I made the new Gerrit privilege policy, since I don't trust existing maintainers to properly review the bona fide status of proposed new developers.
Nov 26 2019
I'll reply to @AlexisJazz by private email.
Nov 25 2019
In the course of backing out these changes for T232563, I confirmed the full-width, superscript parenthesis and S-repeat attacks against IE 6 and confirmed that they do not affect IE 8.
Nov 22 2019
The big unsolved question here was what to do about request context access from hooks, AbuseFilter being the most intractable example. I think the answer is to just let them call RequestContext::getMain(), without any FauxRequest. Most access to RequestContext is just for the user and IP address, which is correct for all web callers. If we need to have editing from the job queue or some other CLI request, the context user can be faked as necessary. The session manager documentation suggests using SessionManager::getSessionById() for authenticated jobs.
Nov 21 2019
Yes, looks correct to me. Ignoring an If-Match header is not compliant with RFC 7232: "An origin server that receives an If-Match header field MUST evaluate the condition prior to performing the method." If If-Match support is really needed for correctness, a strong ETag should be used, since the only difference between a strong and a weak ETag is that a strong ETag may pass If-Match.
Nov 20 2019
Should be done now.
Never mind, I found https://www.mediawiki.org/wiki/Extension:Wikidiff2/Release_process
I haven't made a tarball for wikidiff2 before and I can't find any documentation of how that is meant to be done. It looks like wikidiff2 is the only PHP extension that is released in this way. I assume I just do a git archive and sign it with gpg, then upload it to releases1001:/srv/org/wikimedia/releases/wikidiff2 ? There's no other procedure to follow or script to run? I don't need to be in that wikidiff2 group because I have root.
Nov 19 2019
Nov 18 2019
Per my previous discussion with @eprodromou , the preferred transform is a thumbnail or poster which would be displayed on the image description page, or an icon thumb if there is no other thumbnail image. To do this, you will need to duplicate some of the logic from ImagePage::openShowImage(). In particular, around line 415:
PS1 of my logging change showed it failing due to worthRefreshPopular() returning true. Since the times are mocked, the chance of this happening should be a constant 1/825. To me, it seems like it's failing more often than that, like almost always. SamplingStatsdClientTest calls mt_srand(0), so maybe the exact right number of mt_rand() calls are done between SamplingStatsdClientTest and WANObjectCacheTest.
Deployed now. The link in the task description now returns quickly.
I'm going to deploy it now.