Considering blocking tasks and task descriptions, it seems like we can add Echo, Thanks and Scribunto in time for the MW 1.32 release. They should be ready now.

For the other tasks, there are remaining blockers we probably can't resolve in time.

In T196650#4679588, @MGChecker wrote:

Considering blocking tasks and task descriptions, it seems like we can add Echo, Thanks and Scribunto in time for the MW 1.32 release. They should be ready now.

Have the Wikimedia development and maintenance teams involved agreed to the extra burden (longer deprecation processes, more support requests, etc.)? I guess Scribunto is Core Platform now so it's their time to direct as appropriate, but the other two are owned by the Growth team who might have other things on which they need to spend their time?

What do you mean with longer deprecation process? Afaik deprecation guidelines are the same for bundled and unbundled extensions.

Personally, I don't think "more support requests" is a reason to abandon extensions from bundling. What are you expecting anyway? Bugs are important to the WMF as well, and installation problems don't have much to do with Phabricator anyway.

In T196650#4689897, @MGChecker wrote:

What do you mean with longer deprecation process? Afaik deprecation guidelines are the same for bundled and unbundled extensions.

Not true.

Any code in core or bundled extensions reaching deprecated code should be rewritten/updated. Removal of code cannot be done unless it was hard-deprecated in at least one (two recommended) stable version.

Most production extension code isn't affected by this policy.

Personally, I don't think "more support requests" is a reason to abandon extensions from bundling. What are you expecting anyway? Bugs are important to the WMF as well, and installation problems don't have much to do with Phabricator anyway.

And yet, even for non-bundled extensions, we get loads of people asking for support across lots of of support channels (Phab, MediaWiki.org, direct e-mails, GitHub, IRC). This is easily US$Ks of staff time a month. Increasing this is a decision to be made by the people who have to justify the expenditure.

In T196650#4689982, @Jdforrester-WMF wrote:

In T196650#4689897, @MGChecker wrote:

What do you mean with longer deprecation process? Afaik deprecation guidelines are the same for bundled and unbundled extensions.

Not true.

Any code in core or bundled extensions reaching deprecated code should be rewritten/updated. Removal of code cannot be done unless it was hard-deprecated in at least one (two recommended) stable version.

After a bit of discussion with James on IRC, I clarified that those sentences are two separate ideas: https://www.mediawiki.org/w/index.php?title=Deprecation_policy&diff=prev&oldid=2931858

Given that rc.0 has now been cut, are we going to Resolve this and move the un-done work to a 1.33 task (or just Decline it)?

Given this decision, should we remove the tag MW-1.32-release in the unitary tasks and add MW-1.33-release?

Yes. I just made that change.