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