Former Wikimedia staff member, still a volunteer (but on wikibreak)
Oct 21 2021
Aug 27 2021
I note that the sniffs themselves don't actually require sebastian/diff, its only the Gerrit-specific report formatter that does. To better support reuse of the sniffs by third parties, you might consider moving that report formatter to a different repo so those of us who don't need it don't have to be constrained by its dependencies.
Jun 1 2021
May 28 2021
Feb 26 2021
Feb 2 2021
Another option might be to make the trait stuff protected rather than private, so we can subclass the relevant tests and override them.
Jan 26 2021
Oct 26 2020
Oct 19 2020
Oct 16 2020
Thanks! I'll resubscribe myself now to the ones I just filed, and any I happen to decide to pay attention to in the future.
All of them, please.
Jul 31 2020
Jul 7 2020
Jun 17 2020
May 18 2020
May 3 2020
Apr 10 2020
I don't have any new ideas, T220353#6045847 is a good summary.
update.php is supposed to have run maintenance/migrateComments.php to populate that data. That would have happened at any time with MediaWiki 1.30 if you set $wgCommentTableSchemaMigrationStage to a stage indicating that the comment table should be used, or in 1.33 if you never set $wgCommentTableSchemaMigrationStage to such a stage.
Apr 9 2020
You said in T245310#5991274 that you weren't sure if you were supposed to move it out of CPT's "icebox" when a patch needed review, I was telling you that you can and should.
Next step is to determine the limits and implement them for Wikimedia sites in a patch similar to rOMWC8274bc4f3b29: Add PoolCounter configuration for Special:Contributions.
Seems likely, the stack trace looks the same.
Apr 8 2020
Moving to "Doing" because there's a patch with unaddressed reviews.
Most likely the same issue with cookies for wikisource.org itself versus subdomains setting cookies with domain=.wikisource.org described in T145545.
@valerio.bozzolan: FYI, in HTTP/2 "set-cookie" is the canonical casing of the header field, and it turns out the change is the result of an upgrade to new software using the HTTP/2 semantics. More details are available in T249680: Clients failing API login due to dependence on "Set-Cookie" header name casing.
The LinkRenderer service currently violates the best practice that a service must only depend on the wiki and its site-wide configuration. Specifically, it must not logically vary by information from the current web request.
There was no change to MediaWiki with respect to output of Set-Cookie headers. For that matter, MediaWiki does not directly output the Set-Cookie headers at all, it simply calls PHP's setcookie function and PHP handles the output.
Apr 7 2020
If this gets to the point where there's a plan for the system to identify revisions that need caching, feel free to poke it back into the Platform Engineering inbox for further discussion. At the moment it seems someone has to figure out the appropriate heuristics first.
@daniel pointed out that MW_SERVICE_BOOTSTRAP_COMPLETE comes after Session setup, which probably needs various services to work. We could still emit a warning if it's called before ExtensionRegistry->finish() though.
This task is about the API reporting NeedToken when a token was supplied but the session was lost. Session loss may be caused by cookie handling issues, but this task isn't about that.
Eventually, LoadExtensionSchemaUpdates should be deprecated. It should be replaced by either a completely declarative interface (e.g. a JSON file registered in extension.json) or a functional interface, in which the extension is only called when it is safe to directly perform conditional updates, or two distinct interfaces serving both styles.
This is the practice currently recommended by https://www.mediawiki.org/wiki/Manual:Configuration_for_developers#Configuration_using_extension.json_(recommended). Extensions aren't supposed to use the core Config object to access the extension's configuration, and any doing so are taking advantage of behavior that isn't guaranteed to continue working in the future. But many extensions are probably just continuing to assume global variables instead of going through Config at all.
Apr 6 2020
The "misleading" case occurs when the session is lost, resulting in a new token being created. While this is historical behavior, it's probably about time to change it. It's much more likely that the client is having a bug in cookie handling than that there was a transient session loss on the server side.