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

@Krabina: See discussion in T178349 instead

In T279842#7349142, @Jdforrester-WMF wrote:

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.

In T279842#7349944, @Tgr wrote:

In T279842#7349142, @Jdforrester-WMF wrote:

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.)

In T279842#7349965, @Jdforrester-WMF wrote:

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 :)

In T279842#7350004, @Tgr wrote:

In T279842#7349965, @Jdforrester-WMF wrote:

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.

In T279842#7350011, @Jdforrester-WMF wrote:

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.