Calling out this one point in particular so it doesn't get lost:

In T137926#2412821, @brion wrote:

It may be that extension features are even more popular and I've no idea what they need; since Wikimedia Foundation doesn't make any attempt to survey feature usage of MediaWiki installs, we're kinda shooting in the dark here. :)

See also: T56425: Provide an opt-in ability to register the user's MediaWiki installation. We've wanted to this for some time, nobody's had the time to implement it though. There's lots of useful stats that we could gather about feature usage and support. That could help guide these sorts of decisions with real data.

Interesting data and analysis at http://mtdowling.com/blog/2013/05/02/requiring-curl-in-your-php-library/. Includes some analysis of presence of php-curl bindings by default at a number of shared hosting providers.

Yeah, be nice to have firmer data, and I think we should def do another push on T56425. Just knowing curl is available at various big hosts is a help for now though!

Ok, so updated outcome choices replacing the hard dependency with a soft dependency:

1. no change (advocated most recently by @Florian in T137926#2384514)
2. drop non-curl path for MWHttpRequest, add clear error messaging & install-time doc for features that use MWHttpRequest or MultiHttpClient on non-curl hosts (advocated most recently by @demon in T137926#2412673)
3. keep non-curl path in MWHttpRequest, create alternate non-curl implementation of MultiHttpClient (advocated most recently by @Krinkle in T137926#2412298)

Any objection to going into tomorrow's discussion with those choices ready on the table?

In T137926#2412821, @brion wrote:

Offhand, I think that InstantCommons would be the primary user-visible core feature on small installations that requires an HTTP client and does not currently require curl.

Also image sharing between wikis of the same farm, and SpamBlacklist (bundled with the tarball) fetching the blacklist from meta.

In T137926#2412996, @brion wrote:

Ok, so updated outcome choices replacing the hard dependency with a soft dependency:

1. no change (advocated most recently by @Florian in T137926#2384514)

I think a soft dependency would be a good compromise, too, as long as the standard functions of MediaWiki are still working (ok, now we would need to define "Standard functions") :)

In T137926#2405969, @RobLa-WMF wrote:

@Jdforrester-WMF - would you be available to discuss this RFC this coming Wednesday (at E224)? If so, excellent, this may be our choice for that time slot!

Sure.

Also image sharing between wikis of the same farm, and SpamBlacklist (bundled with the tarball) fetching the blacklist from meta.

Its technically optional for image sharing on same farm (If you disable sharing image descriptions). SpamBlacklist is another area that I think would be highly like to affect unsophisticated users, who would be most troubled by dropping curl support.

In T137926#2414152, @Jdforrester-WMF wrote:

In T137926#2405969, @RobLa-WMF wrote:

@Jdforrester-WMF - would you be available to discuss this RFC this coming Wednesday (at E224)? If so, excellent, this may be our choice for that time slot!

Sure.

Excellent! Let's use this time to see if we can figure out a good answer to Brion's multiple choice question posed at T137926#2412996

Change 294259 abandoned by Jforrester:
[DO NOT MERGE] PHPVersionCheck: Require curl to be installed

Reason:
Per RfC discussion, we're not going to require this yet, just shout from the rooftops that you really /really/ should install it.

https://gerrit.wikimedia.org/r/294259

Last-call proposal:

• Not require curl;
• Keep existing non-curl path;
• Add non-parallel MultiHttpClient fallback,
• Provide environmental warnings about missing curl (and other things?) on Special:Version.

In T137926#2416368, @Jdforrester-WMF wrote:

• Provide environmental warnings about missing curl (and other things?) on Special:Version.

That page already suffers from information overload. Maybe a good time to start a new special page which could eventually become some sort of site admin status panel? Missing packages, disabled optimizations, uninstalled security upgrades etc., like Drupal's status report panel.

In T137926#2421294, @Tgr wrote:

In T137926#2416368, @Jdforrester-WMF wrote:

• Provide environmental warnings about missing curl (and other things?) on Special:Version.

That page already suffers from information overload. Maybe a good time to start a new special page which could eventually become some sort of site admin status panel? Missing packages, disabled optimizations, uninstalled security upgrades etc., like Drupal's status report panel.

Possibly. For this to serve the intended purpose, it would need to be viewable and easily findable by:

1. Non-admin users of the site, so that they can pester the site admins in charge of the setup
2. By people providing MediaWiki support (e.g. people on Freenode MediaWiki-General) who are trying to help a site admin figure out what is wrong with the site

Special:Version is traditionally where this type of information has gone, and it seems like it should at least be an easily findable hyperlink away from Special:Version if it's not included inline.

I think its reasonable to put this in the Installed Software section. We already include the version of libicu the intl extension is compiled against, so we could just add curl + version of curl to that list.

Change 494630 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] Remove various references to cURL in code comments

https://gerrit.wikimedia.org/r/494630

Change 494630 merged by jenkins-bot:
[mediawiki/core@master] Remove various references to cURL in code comments

https://gerrit.wikimedia.org/r/494630

Now that things work without cURL, including for the MultiHttpClient. Does it still make sense to output a warning? There is no degraded feature set.

There is certainly potential in terms of performance, but we don't output warnings for other such potentials either.

That's traditionally been exposed at install/upgrade time instead. We currently does this for diff3, apcu, and intl, for example.

Low priority, not ready to be worked at this point

not ready to be worked at this point

@CCicalese_WMF: Does that mean this task is technically blocked? (On the subtask here?) If yes, its status should probably be stalled?

That should probably have stated, "we (Core Platform Team) don't have the resources to work it at this point, but will get to it soon". It is no longer blocked, so we put it in our Next queue.

@CCicalese_WMF: Thanks for clarifying! That means that a potential contributor could work on this, I guess. (That was the underlying question I had in mind.)

We (Core Platform Team) are reworking our workboards. This task is still tracked by the Core Platform Team, but we are no longer using the Next tag. Removing the tag does not imply any change to the status of this task.

This is blocked by T202352

Change 533983 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] [WIP] Remove MediaWikiServices dependency from MultiHttpClient

https://gerrit.wikimedia.org/r/533983

Wow. Amazing work. I am surprised that it's worth the effort to remove just one dependency. I am supporting this as suggested in T232948#5499371.

The only patch linked here needs a manual rebase (cc @BPirkle), so I'm gonna move this out of code review needed column back into backlog.

Needs rebase.