Page MenuHomePhabricator

Expand the set of bundled extensions and skins in MediaWiki 1.37
Closed, DeclinedPublic

Related Objects

StatusSubtypeAssignedTask
OpenNone
InvalidNone
DeclinedNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedJdlrobson
ResolvedJdlrobson
InvalidNone
OpenNone
StalledNone
Resolveddemon
StalledNone
OpenNone
ResolvedUmherirrender
ResolvedUmherirrender
OpenNone
ResolvedLegoktm
StalledNone
OpenNone
Resolvedsbassett
Resolvedsbassett
OpenNone
ResolvedJdforrester-WMF
ResolvedPhysikerwelt
OpenNone
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedUrbanecm
DeclinedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
Resolvedmatej_suchanek
ResolvedDaimona
ResolvedDaimona
Resolvedmatej_suchanek
Resolvedmatej_suchanek
ResolvedPRODUCTION ERRORDaimona
ResolvedDaimona
OpenNone
ResolvedDaimona
ResolvedMarostegui
ResolvedBstorm
ResolvedDaimona
ResolvedUrbanecm
ResolvedMarostegui
Resolvedrook
OpenNone
OpenNone

Event Timeline

Is there a chance to bundle the chameleon skin? It is widely used in third-party MW installations: https://www.mediawiki.org/wiki/Skin:Chameleon

We're a few months late to be adding things now. In the end, nothing got added to the bundle for this release.

We're a few months late to be adding things now. In the end, nothing got added to the bundle for this release.

What is the deadline for adding something to the bundle? Quite often it's rather trivial to do so, it can have significant user impact, and it's not like adding something a month before the bundle is generated vs. right before it is generated makes any difference in testing.

We're a few months late to be adding things now. In the end, nothing got added to the bundle for this release.

What is the deadline for adding something to the bundle? Quite often it's rather trivial to do so, it can have significant user impact, and it's not like adding something a month before the bundle is generated vs. right before it is generated makes any difference in testing.

I would say at bare minimum the addition should be landed (and tested) a month before the cut, but more challengingly as there's no product owner for third party use of MediaWiki there's no clear basis on which to say what tradeoffs in engineering work, size, and complexity are worth it; I would expect a proper discussion to happen with announcement on wikitech-l before novel items are added into the bundle. (Adding a new skin to the tarball is equivalent to adding them to Wikimedia production in terms of quality expectations on all teams; a massive additional testing burden for dozens of teams and isn't something to decide lightly.)

I would say at bare minimum the addition should be landed (and tested) a month before the cut

What benefit would that have? In practice, adding something means listing it in make-release. That's not going to be used until a release is actually made, so something spending an extra month there doesn't really make any difference in terms of testing.

Adding a new skin to the tarball is equivalent to adding them to Wikimedia production in terms of quality expectations on all teams; a massive additional testing burden for dozens of teams and isn't something to decide lightly.

That makes sense. Should we add that (starting a discussion, in the case of extensions which aren't in Wikimedia production) to the checklist?

(Also, I'll plug T290464: Bundle DiscussionTools extension with MediaWiki which is already in production so all the cost of adding it would be a rather trivial change to the installer :)

I would say at bare minimum the addition should be landed (and tested) a month before the cut

What benefit would that have? In practice, adding something means listing it in make-release. That's not going to be used until a release is actually made, so something spending an extra month there doesn't really make any difference in terms of testing.

The run up to the branch point is frequently when new quality requirements get added, e.g. we recently decided that phan must be installed in tarball repos. I'd really not want to spend the time trying to get an extension or skin up to the new quality level when instead we should be spending that time looking at new scary features/config settings, finishing promised deprecations/removals or incomplete migrations, etc..

Adding a new skin to the tarball is equivalent to adding them to Wikimedia production in terms of quality expectations on all teams; a massive additional testing burden for dozens of teams and isn't something to decide lightly.

That makes sense. Should we add that (starting a discussion, in the case of extensions which aren't in Wikimedia production) to the checklist?

Yeah, good idea.

(Also, I'll plug T290464: Bundle DiscussionTools extension with MediaWiki which is already in production so all the cost of adding it would be a rather trivial change to the installer :)

Yes, but though it'd be very easy for me, putting alpha-model code that can change radically every few months into the tarball is not very respectful for third party sysadmins, and would be a pain for the development team. Generally if they think it's stable and good to ship we'd expect them to push it.

The run up to the branch point is frequently when new quality requirements get added, e.g. we recently decided that phan must be installed in tarball repos. I'd really not want to spend the time trying to get an extension or skin up to the new quality level when instead we should be spending that time looking at new scary features/config settings, finishing promised deprecations/removals or incomplete migrations, etc..

That makes sense, thanks for explaining.

Yeah, good idea.

Added, feel free to tweak.

Yes, but though it'd be very easy for me, putting alpha-model code that can change radically every few months into the tarball is not very respectful for third party sysadmins, and would be a pain for the development team. Generally if they think it's stable and good to ship we'd expect them to push it.

I think talk pages are such a clear pain point in MediaWiki that sysadmins would very much prefer volatile but high-UX-standards code to nothing, and there is long-term value in establishing DiscussionTools as the standard solution as opposed to having half a dozen comment extensions around, most of which aren't very high quality. I won't push the point further though.