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 sites >> >> o >> >> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- > Daniel Kinzler > Principal Software Engineer, Core Platform > Wikimedia Foundation -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
