Another thing for attention by TechCom:
We need a robust and consistent way to determine whether a response should be (publicly) cacheable. We Seem to fail in both directions currently, in some edge cases. On a related note, we need more control over which responses are allowed to contain which cookies.
See discussion on https://phabricator.wikimedia.org/T264631
Am 07.10.20 um 10:30 schrieb Daniel Kinzler:
There is something I came across that I'd like to briefly discuss briefly during the meeting:
It would be nice if the updater could change default settings. This way, we could make some behavior the default for new wikis, while keeping old behavior for existing wikis. I envision an DefaultOverrides.php file that the installer would append to. It would be in .gitignore, but I'm not sure where it should be located.
Point in case: Wikis that share the user table should also share the actor table. But we haven't been doing that so far, and wikis that now already have a shared user table but per-wiki actor tables are rather ticket to migrate. So we could add the actor table to wgSharedTables per default, but tell the installer to override that for wikis that already have out-of-sync actor tables. See T243276#6519078. https://phabricator.wikimedia.org/T243276#6519078
Am 06.10.20 um 12:18 schrieb Giuseppe Lavagetto:
This is the weekly TechCom board review in preparation of our meeting on Wednesday. If there are additional topics for TechCom to review, please let us know by replying to this email. However, please keep discussion about individual RFCs to the Phabricator tickets.
Activity since Monday 2020-09-28 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/
https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
T264334 https://phabricator.wikimedia.org/T264334: Could the registered module manifest be removed from the client?
o
New task about the possibility of removing the huge module registry from the js sent to the client. The idea is being discussed.Committee board activity: Nothing to report, besides inbox
New RFCs: none.
Phase progression:
T262946 https://phabricator.wikimedia.org/T262946: Bump Firefox version in basic support to 3.6 or newer
o
Moves to P3 (explore)o
It is pointed out that we’ve dropped support in production for TLS 1.0/1.1 in january, so de facto only Firefox 27+ is able to connect to the wikimedia siteso
In light of that, it’s suggested that we might bump the minimum supported versions of browsers further.IRC meeting request: none
Other RFC activity:
T260714 https://phabricator.wikimedia.org/T260714: Parsoid Extension API.
o
Last call to be approved, that will end on October 7 (tomorrow)T487 https://phabricator.wikimedia.org/T487: RfC: Associated namespaces.
o
On last call to be declined, there is some opposition to the opportunity of marking it as declined on phabricator. Last call should end on October 7 (tomorrow)T263841 https://phabricator.wikimedia.org/T263841: RFC: Expand API title generator to support other generated data.
o
Erik asks if this is going to be generally applied to all generators or not.Cheers, Giuseppe -- Giuseppe Lavagetto Principal Site Reliability Engineer, Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation