Hi all, Here are the minutes from this week's TechCom meeting:
== RFC: Drop support for database upgrade older than two LTS releases == <https://phabricator.wikimedia.org/T259771> * New RFC * Moved from P1: Define to P2: Resource * TT: The “UPGRADE” documentation file has a warning about upgrading from certain older versions being unsupported. Maybe formalizing that in some way would be useful. Interesting that the install is mentioned as slow since it’s less than a second in CI as far as I know. * DK: It’s hard to reason about database updates, so there’s mental load involved. Unclear what to do with patches when changing database fields. There was an idea that maintenance scripts would run after the schema changes, but it doesn’t work in all cases, so now there are scripts that run at different points in the process, which introduces additional complexity. * TT: Right, running it mid-migration makes the state easier to reason about, but falls apart if it runs dynamic MW code that can’t/shouldn’t support running on an old MW schema. * DK: This is a question of MediaWiki as a product, which doesn’t have a clear owner. Who has the authority to make this decision? * TS: The people maintaining it are the most impacted, so it makes sense for them to make the decision since it is related to developer productivity. * TT: The RFC can help bring together different points of view on this, have teams weigh in on the costs from their perspectives. * TS: Two LTS releases sounds like a pretty short time compared to the current policy. * DK: I think two is reasonable (four years). One cost is testability; it’s hard to test this update logic. == Stable Interface Policy: Timeline for removing obsolete code == <https://www.mediawiki.org/wiki/Topic:Vrwr9aloe6y1bi2v> * Regarding a proposal to change wording on the talk page * DK: The stable interface policy didn’t change the deprecation policy. Things that aren’t used within the MediaWiki ecosystem don’t have to use the deprecation policy. The intention was to make it easy to remove obsolete code that isn’t used. So the question is if you make code obsolete and then remove usages, can you remove it? * TT: Hard deprecation is fine, not the same thing. * DK: Depending on the interpretation of the policy, we could remove anything if we remove all usages of it. * TT: It’s meant to include a requirement to email wikitech-l with a notice and justification. I think this made sense when there was an assumption of stable by default. If we intentionally create an extension for public use, I’m not sure why we’d need to bypass deprecation. * DK: There should be a clear, easy path for getting something into the ecosystem. * TT: Codesearch goes through external repositories as well. The process for adding things to this isn’t easy or transparent, which needs to be improved. The policy incentivizes the Wikimedia Foundation to make a choice to help third party users migrate or continue support for some time. As phrased now, the policy requires the code to no longer be used in the default branch, allowing for the code manager to reject the change. * TT: We can resolve within TechCom, but we should send a message to wikitech-l. == Introduce Authority objects to represent the user performing a given action == <https://phabricator.wikimedia.org/T231930> * DK: Strawman design for managing permission checks with an experimental patch. <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/582889/> There may be resourcing available to start working on this in the next few weeks. We could try to come up with a comprehensive design and submit an RFC or do it the experimental way and use it in one corner of the codebase. * TT: This is about making sure we can’t accidentally bypass permission checks for non-current users. Experimenting seems fine, if there’s a commitment to actively limit it to a narrow scope and not allow other features to adopt it. * DK: The authority is something that actually encapsulates the checks themselves, as opposed to a user. We’re missing a clean place to store state for IP addresses when checking for IP-address blocks. Also applies to OAuth sessions. This new idea partially supersedes permission manager, so there’s some sunken cost there. * TT: You might also want to talk to the AHT team about their experience with Block Manager. Similar issues. * DK: The tradeoff is more flexibility now and a commitment to clean it up later. Thinking about this as example-driven development. Trying to think through everything in advance tends to bring up important edge cases and problems, but it tends to change again during implementation. The goal is to provide more room for exploration and experimentation without losing the feedback process. * TT: Needs an RFC to be used outside of the narrowly-defined, experimental scope == Next week IRC office hours == No IRC discussion scheduled for next week You can also find our meeting minutes at <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. If you prefer you can subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> -- Alex Paskulin Technical Writer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
