HomePhabricator

ArchCom RFC Meeting W26: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office)
ActivePublic

Hosted by daniel on Jun 29 2016, 9:00 PM - 10:00 PM.

Description

Meeting summary
  • LINK: https://phabricator.wikimedia.org/E224 (robla, 21:03:37)
  • LINK: https://phabricator.wikimedia.org/T137926 (robla, 21:04:00)
  • list of 3 options listed at https://phabricator.wikimedia.org/T137926#2412996 (robla, 21:05:07)
  • question discussed for the first 10-15 minutes: is having a fallback worthwhile at all? (robla, 21:13:22)
  • James_F clarifies this RFC is about requiring MultiHttpClient, rather than curl specifically (robla, 21:22:41)
  • <James_F> robla: Well, no. The impending requirements are for MultiHttpClient which we're standardising on. The curl requirement for that requirement is what we're discussing, I think. (robla, 21:23:43)
  • James_F finds "Example of expected heavy MultiHttpClient use in core": T111588 (robla, 21:30:20)
  • <brion> so recommend: keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version ? (robla, 21:41:11)
  • <bawolff> Can we put the env warnings on both Special:Version and installer (brion, 21:42:38)
  • <TimStarling> maybe it is time to revisit the idea of a pingback from the installer for statistical purposes (robla, 21:43:46)
  • "keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version " goes to last call (robla, 21:46:43)
  • brion wants to make sure we have a plan for an installer beacon (robla, 21:50:42)
  • ACTION: brion, robla discuss beacon at E225 (robla, 21:54:02)
People present (lines said)
  • brion (96)
  • SMalyshev (32)
  • robla (27)
  • James_F (27)
  • TimStarling (25)
  • ostriches (20)
  • bawolff (18)
  • Reedy (8)
  • stashbot (5)
  • wm-labs-meetbot` (3)
  • subbu (3)
  • tgr (1)
  • bd808 (1)
  • Scott_WUaS (1)
Full log

121:02:57 <robla> #startmeeting ArchCom RFC Meeting: Require 'curl' PHP extension for MediaWiki?
221:02:57 <wm-labs-meetbot`> Meeting started Wed Jun 29 21:02:57 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:02:57 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:02:57 <wm-labs-meetbot`> The meeting name has been set to 'archcom_rfc_meeting__require__curl__php_extension_for_mediawiki_'
521:03:10 <brion> yummy curl!
621:03:12 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
721:03:36 <James_F> Heya.
821:03:37 <robla> #link https://phabricator.wikimedia.org/E224
921:03:42 <robla> James_F: hi!
1021:04:00 <robla> #link https://phabricator.wikimedia.org/T137926
1121:04:02 <brion> ok, so we have a rough proposal to require the PHP curl extension, at least for HTTP-using stuff
1221:04:06 <brion> couple of possible options
1321:04:45 <brion> no change (meaning some of out internal interfaces like MultiHttpClient which is curl-only will be unavailable when not using curl, but things using MWHttpClient will still work)
1421:05:07 <robla> #info list of 3 options listed at https://phabricator.wikimedia.org/T137926#2412996
1521:05:25 <brion> or we could require it for MwHttpRequest / Http::get() etc as well, removing the old non-curl paths which are harder to maintain
1621:05:45 <brion> another possibility is to provide a non-curl implementation of MultiHttpClient as well, even if it's a dead-simple one
1721:06:13 <brion> in the case where we start requiring curl for more bits, we'd probably want better error reporting / failure cases
1821:06:29 <brion> eg, either "don't break the wiki when using InstantCommons but curl is not present" or "break the wiki in a very clear, easy to fix way"
1921:07:07 <brion> we don't have a *real* clear picture of how commonly available the php curl extension is, but anectdotally it's on a number of major shared posting providers
2021:07:28 <brion> and if you run your own server it's trivial to make sure it's installed (which also means we can easily make sure our debian packages etc depend on it)
2121:07:29 <SMalyshev> brion: do we have features in MultiClient that are impossible to do without curl?
2221:07:34 <SMalyshev> or very hard
2321:08:02 <brion> SMalyshev: IIRC it's a fairly simple API, you pass a number of URLs in and it runs them simultaneously, then returns an array mapping of responses
2421:08:16 <brion> which means you can make a crappy back-compat very easily by running serial instead of parallel
2521:08:19 <SMalyshev> brion: so what happens if it runs them sequentially instead?
2621:08:22 <TimStarling> there is maxConnsPerHost
2721:08:24 <SMalyshev> right
2821:08:25 <brion> or a fancy back-compat using stream_select, but only on newer PHP
2921:08:39 <brion> SMalyshev: slower, but satisfies the API contract
3021:08:39 <James_F> brion: Newer than 5.5 which we already require?
3121:08:40 <Scott_WUaS> Hello All :)
3221:08:45 <TimStarling> so a b/c version that runs them serially would be equivalent to configuring maxConnsPerHost=1
3321:08:46 <brion> James_F: right iirc
3421:08:56 <brion> *nod*
3521:09:07 <SMalyshev> not even stream_select, beggars can't be choosers, just bare bones functionality - I think we can do it rather easily? if so, I'd lean towards doing it
3621:09:16 <brion> James_F: secondarily, creating a 'proper' back-compat path just adds to our complexity and maintenance/security surface.
3721:09:22 <James_F> Yup.
3821:09:37 <bawolff> Yeah, i suspect the bare bones version would be like 5 lines
3921:09:53 <James_F> Well. We already have some of this complexity. The RfC was about admitting that it doesn't work well and isn't tested or used in production, so we were going to remove it.
4021:10:09 <TimStarling> are there bug reports about it not working well?
4121:10:10 <James_F> If we're keeping it and making it "cool", fine, but… someone has to keep looking after it.
4221:10:23 <brion> TimStarling: iirc we saw problems with SSL certs and InstantCommons
4321:10:23 <SMalyshev> right... so if we can make super-simple super-dumb implementation that still works, I think we should. If it's complex or missing features - then we should fail early and let people install curl
4421:10:32 <James_F> TimStarling: More "not well" as in "90% of uses don't have the back-compat".
4521:10:34 <brion> work was done to make sure openssl got initialized properly on the back-compat path
4621:10:50 <brion> but that's only one thing, might be more work next time
4721:10:53 <bawolff> But since that's been fixed, it works well now
4821:10:55 <James_F> I can't speak to the security side of this stuff, but bawolff I guess is OK with it?
4921:11:08 * bawolff has not looked at the code recently
5021:11:16 <bawolff> But I fixed a bunch of stupid things a while back
5121:11:16 <SMalyshev> with curl, I had issues with servers using SSL and certificate auths that are new or exotic... figuring out how to add cert auth is non-trivial IIRC
5221:11:30 <SMalyshev> but that is probably true for any other way of doing it too
5321:11:52 <brion> in general i'm leery of maintaining an HTTP client in MWHttpRequest's PhpHttpRequest subclass forever, libcurl does that job for us
5421:12:01 <TimStarling> there is T102566
5521:12:02 <stashbot> T102566: InstantCommons broken by switch to HTTPS - https://phabricator.wikimedia.org/T102566
5621:12:11 <brion> eventually we'll have to update it for http/2 etc, or else throw it out then :)
5721:12:25 <bawolff> But T102566 was broken both with curl and non-curl
5821:12:25 <stashbot> T102566: InstantCommons broken by switch to HTTPS - https://phabricator.wikimedia.org/T102566
5921:12:41 <James_F> bawolff: In different ways, so it needed two fixes, or the same issue?
6021:12:42 <SMalyshev> can't http/2 fallback to regular http?
6121:13:00 <James_F> SMalyshev: Some of our client UAs already report HTTP2-only accept headers.
6221:13:06 <bawolff> The main issue was it was configured to not follow redirects
6321:13:19 <bawolff> so redirects didn't work on both implementations (as it should)
6421:13:22 <robla> #info question discussed for the first 10-15 minutes: is having a fallback worthwhile at all?
6521:13:25 <brion> SMalyshev: we don't know for sure what the future will bring; at the least i expect someone will evnetually want persistent connections for something
6621:13:38 <SMalyshev> James_F: that's... aggressive. But yeah, I don't want to maintain php http/2 library :)
6721:13:42 <brion> bawolff: oh fun :D
6821:14:17 <James_F> SMalyshev: Agreed.
6921:14:21 <bawolff> There was some additional problems with https in the fallback config. I think in some configs it thought all certs were invalid or something. It was a while ago. Those issues are fixed
7021:14:42 <brion> so another possible outcome of this discussion is "let's actually survey availability of php-curl before changing"
7121:14:52 <SMalyshev> brion: right... maybe have some way of asking http client if it supports certain features? OTOH, if we do have such features I'd just take the plunge and drop the fallback
7221:14:55 <brion> which i didn't think to capture on the task comments earlier
7321:15:37 <brion> but surveying is hard when we don't know we can reliably reach affected users who don't upgrade frequently, are on obscure hosts, etc
7421:16:28 <James_F> <troll> If they don't upgrade they won't notice the change…
7521:16:43 <brion> :D
7621:16:55 <James_F> This is a common issue in support for third parties; very few voices, very little data.
7721:17:03 <brion> danger is if they do, they'll tableflip in anger at how nothing works anymore
7821:17:11 <brion> but we probably broke their site in 10 other ways if that's the case :(
7921:17:19 <brion> so that isn't the worst additional breakage :D
8021:17:27 <James_F> They'll also do that when the tarball-bundled editor requires curl, which is ~ a year away.
8121:17:29 <James_F> So…
8221:17:30 <SMalyshev> but if we just tell them "install curl" isn't not that bad?
8321:17:42 <SMalyshev> curl is pretty widely supported I think
8421:17:49 <brion> it is pretty widely supported yes
8521:18:04 <brion> but not everyone has root on their system, and not everybody is a professional or hobbyist sysadmin
8621:18:13 <brion> what's trivial to us is not trivial to everyone
8721:18:25 <SMalyshev> right, but most shared hosts I'd expect to have curl
8821:18:32 <brion> yep
8921:18:44 <SMalyshev> same for university etc environment - it's part of almost every prepackaged setup
9021:18:48 <brion> so it's a balance between large pain to small group, small pains to large group, etc
9121:18:53 <SMalyshev> unless it's insanely stripped down
9221:19:10 <brion> i suspect that 'tearing the band-aid off' is going to be net win
9321:19:25 <brion> since down the road we'll want to just have curl handy
9421:19:36 <brion> i just wish i had more data!
9521:19:58 <SMalyshev> we could keep the fallback but still require curl e.g. in composer. This way if you don't have curl you could remove the require and hope for the best
9621:20:16 <SMalyshev> at least for now until we add http/2 and http/3 support :)
9721:20:20 <brion> hehe
9821:20:28 <bawolff> I'm not sure I see what the down-the-road usecases are. What are we actually planning to add that requires this?
9921:21:17 <James_F> bawolff: Parsoid HTML reading. VE as the tarball editor. Non-wikitext wikis.
10021:21:22 <brion> bawolff: 'requires' is a tricky thing. technically, nothing. but it's nice to not maintain an http client, and it's nice not to have to create a second implementation of the multiplexing parallel client wrapper.
10121:21:56 <James_F> bawolff: Also, 'requires' MultiHttpClient rather than curl specifically.
10221:22:09 <TimStarling> it looks to me like it's not that hard to support non-curl installations, it's just that nobody could be bothered to do that small amount of work
10321:22:41 <robla> #info James_F clarifies this RFC is about requiring MultiHttpClient, rather than curl specifically
10421:22:45 <TimStarling> T102566 and [[InstantCommons#HTTPS]] say "just try installing curl and see if it works"
10521:22:46 <stashbot> T102566: InstantCommons broken by switch to HTTPS - https://phabricator.wikimedia.org/T102566
10621:22:49 <SMalyshev> I think it's not hard to support now, but we don't know long-term - maybe it stays not hard, and maybe it becomes hard (e.g. if everybody moves to http/2)
10721:23:01 <TimStarling> the bug with non-curl is not isolated, nobody could be bothered
10821:23:17 <brion> oh yes, it's trivial to add a non-curl api-compatible single-threaded implementation
10921:23:18 <James_F> robla: Well, no. The impending requirements are for MultiHttpClient which we're standardising on. The curl requirement for that requirement is what we're discussing, I think.
11021:23:24 <brion> and moderately more work to make a proper implementation.
11121:23:31 <brion> so the question is, do we do that *and* continue to maintain them?
11221:23:31 <TimStarling> and like bawolff said previously, you could do MultiHttpClient with non-curl with 5 lines of code
11321:23:32 <bawolff> TimStarling: That bug referenced on InstantCommons is fixed afaik, the help page was just never updated
11421:23:43 <robla> #info <James_F> robla: Well, no. The impending requirements are for MultiHttpClient which we're standardising on. The curl requirement for that requirement is what we're discussing, I think.
11521:23:53 <SMalyshev> TimStarling: I think that's what we should be doing first - i.e. if somebody has http problems, we should tell them to install curl. If they can't, then it becomes interesting, but we should start with it by default
11621:25:00 <TimStarling> SMalyshev: that doesn't sound right to me, have a solution which is not tested or maintained, just a trap for new users
11721:25:11 <tgr> TimStarling: the non-curl bug is about installations which don't have the right certs, there is no bug in the MediaWiki stream wrapper implementation per se
11821:25:31 <bawolff> I'd note, if you look at the git log, overall there's been very little maintenance needed for the php stream fallback implementation all and all
11921:25:34 <TimStarling> presumably PHP doesn't bundle its own authority list
12021:25:37 <SMalyshev> TimStarling: well, it is tested now I think. But eventually if the main MultiHttpClient changes it may become stale
12121:25:42 <robla> we've talked about "strongly recommending" curl; do we have a clear idea of what "strong recommendation" means?
12221:25:54 <TimStarling> so it would have just been a matter of configuration
12321:25:54 <brion> so if we don't object to continuing to maintain the non-curl MWHttpRequest path, it's fairly trivial to make a single-threaded wrapper for api compat and not lock the non-curl folks out of future features
12421:26:07 <TimStarling> or maybe installing the right cert list package
12521:26:19 <SMalyshev> TimStarling: the question is - what's better, having some code that may work or have no code at all for non-curl? I'm honestly not sure here
12621:26:24 <bawolff> Currently we tell php to use the system cert directory
12721:26:28 <brion> and indeed it may not be a huge amount of work. maybe we never will care about http/2 client on it, or by the time we do it'll be definitely no big deal to go curl-only
12821:26:34 <bawolff> which will work for non-windows hosts
12921:26:38 <bawolff> mostly anyways
13021:26:45 <bd808> robla: if the argument for "strong recommendation" is less tested code then I guess it would be similar to mysql vs any other db backend
13121:26:52 <SMalyshev> TimStarling: no, php relies on OS AFAIR. Distros may do it though
13221:27:14 <bawolff> I think its rather unlikely we'll need to support http/2 any time soon
13321:27:18 <brion> bd808: similar, but with a very different bug surface i think
13421:27:29 <bawolff> I have a very hard time imaging any sites will be http/2 only any time soon
13521:27:33 <brion> DBs are much more fragile with weird APIs that are tweaked a bajillion ways
13621:27:40 <TimStarling> in an ideal world, we would have automated testing that runs with both curl and non-curl
13721:27:43 <brion> HTTP 1.1 is complex but much less so
13821:27:49 <TimStarling> that is the usual solution to developer laziness
13921:27:52 <brion> and our usage of it is mostly very simple
14021:27:59 <brion> :D
14121:29:07 <brion> any strong feelings on the maintenance question?
14221:29:18 <James_F> TimStarling: Example of expected heavy MultiHttpClient use in core is https://phabricator.wikimedia.org/T111588 (finally found the damn link)
14321:29:25 <brion> if we're not in fact that concerned about it then we can concentrate on the narrow question of MultiHttpClient
14421:29:30 <ostriches> I'm kinda indifferent on the whole thing now.
14521:30:12 <brion> James_F: that's a good one! heavy api-fetch usage is very possible there and parallel's a huge win
14621:30:20 <robla> #info James_F finds "Example of expected heavy MultiHttpClient use in core": T111588
14721:30:20 <stashbot> T111588: [RFC] API-driven web front-end - https://phabricator.wikimedia.org/T111588
14821:30:49 <bawolff> James_F: That seems like a rather far-in-the-future proposal
14921:31:05 <subbu> this is a slightly tangential troll-y question .. but what is our threshold for how far we are willing to go to support shared host wikis? i.e. is there a development / maintenance threshold at which point we say features X, Y, Z may not be available on those platforms?
15021:31:30 <ostriches> What subbu said ^
15121:31:37 <brion> subbu: excellent question which has never been answered adequetly :D
15221:31:41 <James_F> It keeps coming up, though.
15321:31:43 * subbu hasn't read the scrollback yet .. so jumping in the middle.
15421:32:01 <James_F> And Parsing and Services both have to consider it a lot in some of their work.
15521:32:19 <brion> at this point though it sounds like we're not so concerned with dropping our non-curl path that it's going to be an issue on the narrow question
15621:32:55 <brion> eg, it sounds like nobody wants to kill non-curl path and we'll be deciding between 'make a single-threaded MultiHttpClient fallback path' and 'make a fancier non-curl parallel MultiHttpClient fallback path for versions of PHP that support it suitably'
15721:33:20 <brion> so, it does go into 'are we willing to do that extra work?'
15821:33:33 <TimStarling> subbu: I'm fine with answering that on a case-by-case basis
15921:33:37 <brion> it mighta ctually be we don't require newer php, now that i look at it. stream_select on the raw tcp streams should already be available
16021:33:49 <subbu> TimStarling, that is reasonable.
16121:33:55 <TimStarling> I've found in the past that a lot of imagined conflicts between WMF and shared hosting don't really eventuate in practice
16221:34:07 <robla> perhaps we can officially deprecate non-curl intentionally breaking it now?
16321:34:31 <robla> er..."without intentionally breaking it now"
16421:35:12 <SMalyshev> brion: the question is do we really want to deal with http over stream_select?
16521:35:21 <TimStarling> sure, there are stream functions, and there are HTTP libraries that work on top of them that we could import
16621:35:23 <SMalyshev> we may spend a lot of time for very small reward
16721:35:47 <SMalyshev> unless we have a ready-made library of comparable power
16821:35:53 <brion> exactly, it's more work to do the proper implementation (or to find and import another library)
16921:36:01 <brion> but it's very easy to do the simple back-compat
17021:36:16 <TimStarling> I remember there was one in PEAR, years ago, no doubt it still exists
17121:36:26 <brion> and as robla suggests we _could_ deprecate it without breaking it, as an implicit warning that folks should use curl when available
17221:36:32 <SMalyshev> PEAR would mean it's probably old...
17321:36:57 <brion> yeah, i can't recall if we thought about migrating to it but hated the code, or migrated from it to our own ;)
17421:37:31 <brion> i think there's no need to _actively_ break non-curl unless UI becomes dependent on parallel fetches for reasonable performance
17521:38:06 <brion> and it's easy even then to say 'well it might be slowing on your config, but enable curl if you can'
17621:38:23 <robla> if we deprecate, perhaps we could also come up with a way for a novice user to know when they are running in a deprecated environment
17721:38:33 <brion> that's a good point
17821:38:37 <TimStarling> there's the environment check page in the installer
17921:38:42 <brion> *nod*
18021:38:52 <brion> the installer's one place, but i'd love to have something visible on maybe special:version
18121:39:14 <brion> someplace you can check on your live installation, that you'd already be directed to check for other environmental things in a help-debug session
18221:39:30 <SMalyshev> special:version sounds good
18321:39:35 <robla> Special:Version has the added perk that users of the site can know, and use the info to prod the admin
18421:39:41 <brion> yeah :D
18521:39:57 <brion> ok i think we've got something coming together
18621:40:43 <brion> so recommend: keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version ?
18721:41:04 <James_F> WFM.
18821:41:05 <brion> any objections or alternate proposals?
18921:41:10 <brion> woohoo
19021:41:11 <robla> #info <brion> so recommend: keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version ?
19121:41:41 <brion> this leaves open the possibility of adding a parallel non-curl path but does not commit us to doing so
19221:42:10 <brion> and also leaves open possibility of fully deprecating non-curl but does not force it
19321:42:18 <bawolff> Can we put the env warnings on both Special:Version and installer
19421:42:20 <brion> (eg later if we find we really need to)
19521:42:22 <brion> on yeah def
19621:42:38 <brion> #info <bawolff> Can we put the env warnings on both Special:Version and installer
19721:43:01 <ostriches> Yeah, that makes sense ^
19821:43:09 <TimStarling> maybe it is time to revisit the idea of a pingback from the installer for statistical purposes
19921:43:12 <ostriches> We don't actually do environmental warnings on Special:Version yet, but I think we should
20021:43:22 <ostriches> TimStarling: +1, brion and I talked about that yesterday
20121:43:45 <TimStarling> every time this sort of thing comes up, we have no idea of what our users' installations look like
20221:43:46 <robla> #info <TimStarling> maybe it is time to revisit the idea of a pingback from the installer for statistical purposes
20321:43:59 <ostriches> Time for new-new-installer :D
20421:44:05 <robla> lol
20521:44:25 <brion> yes def
20621:44:26 <Reedy> does that count as volunteering?
20721:44:26 <James_F> There's already an environmental warning about curl in the installer, BTW.
20821:44:34 <brion> a pingback that probably will use MWHttpRequest... ;)
20921:44:40 <SMalyshev> isn't that what wikiapiary is doing?
21021:44:40 <James_F> brion: Tsk. :-)
21121:44:49 <TimStarling> I proposed it once on wikitech-l but I was shouted down by the libertarians
21221:44:52 <ostriches> And might know have curl to tell us :p
21321:44:55 <TimStarling> as if they're not all using facebook by now
21421:45:02 <brion> lol
21521:45:03 <ostriches> lmao
21621:45:17 <James_F> TimStarling: For some things, just implement and ignore the wails. :-)
21721:45:23 <ostriches> TimStarling: I think last time we seriously talked about it like 2-3 years ago the consensus had been "as long as it's opt-in"
21821:45:23 <SMalyshev> privacy issues are... touchy. Maybe do the opt-in?
21921:45:34 <brion> SMalyshev: do they have an auto-report widget you can add to your site or do they just crawl & make stats from that?
22021:45:36 <James_F> TimStarling: For people with real security needs, they'd be installing it inside an air-gapped machine anyway.
22121:45:38 <brion> (wikiapiary)
22221:45:49 <ostriches> With, of course, a glaring option to turn it on during install time.
22321:45:58 <SMalyshev> brion: I have no idea, I haven't looked into how they work.
22421:45:59 <ostriches> (we want to encourage it to be on :))
22521:46:05 <robla> is "keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version " what we should put in last call?
22621:46:10 <TimStarling> I think a prominent checkbox enabled by default would be good enough
22721:46:18 <brion> robla: I think we're good to go on that yeah
22821:46:20 <James_F> robla: Yes.
22921:46:27 <brion> put it in last call and let any final objections come in on list
23021:46:43 <robla> #info "keep existing non-curl path; add non-parallel MultiHttpClient fallback, and provide environmental warnings about missing curl on Special:Version " goes to last call
23121:46:47 <brion> feels good, we made a decision \o/
23221:46:51 <SMalyshev> I think if we just have checkbox or button saying "send anonymous statistics about your install to MediaWiki devs" it's fine
23321:47:35 <brion> TimStarling: did you want to revive the rfc for the installer beacon? or shall i put it on my todo list?
23421:47:37 <Reedy> Would it be useful to do something like that from update.php?
23521:47:54 <ostriches> James_F: Thanks for filing the RfC. Wasn't the outcome we thought of when we discussed it weeks back, but I think the outcome is good :)
23621:48:03 <brion> or can we foist it on someone else :D
23721:48:29 <brion> i don't want it to get lost though if we get caught up in our other big things
23821:48:33 <ostriches> Reedy: I think we should trigger a pingback on any install/upgrade, yeah
23921:48:53 <ostriches> Ideally more often than that, but we don't really support a "has config changed" hook (yet)
24021:48:55 <Reedy> I guess we set a global based on install time preference....
24121:49:22 <TimStarling> SMalyshev: let's continue this discussion on facebook
24221:49:26 <Reedy> But question of what we do about "current" installs... Ask them nicely to add the global to their localsettings?
24321:49:28 <robla> we also had T136866 penciled in here if we had time, but I think we can wrap up on brion's question
24421:49:28 <stashbot> T136866: Improve the per-programming-language listings for our tools - https://phabricator.wikimedia.org/T136866
24521:49:57 <ostriches> Reedy: We could prompt for the new setting in update.php
24621:50:10 <ostriches> Ideally, we should actually do that anyway (somehow) to call out important config changes.
24721:50:16 <ostriches> "This setting is new and you might wanna change it"
24821:50:20 <Reedy> mmm
24921:50:24 <ostriches> Or "This setting doesn't do what you think anymore..."
25021:50:31 <brion> heh
25121:50:42 <Reedy> I wonder if we could reuse the environment type notifications on Special:Version too
25221:50:42 <robla> #info brion wants to make sure we have a plan for an installer beacon
25321:50:50 <Reedy> "reuse" in a loose sense
25421:51:08 <ostriches> Reedy: We could abstract them a bit further to make them portable I'm sure.
25521:51:20 <brion> Reedy: yeah don't dupe the code & messages if they're common checks ideally
25621:51:22 <ostriches> They're already pretty well isolated, just in a "weird" place for Special:Version to want them
25721:51:29 <James_F> ostriches: Sure!
25821:52:00 <brion> ok if nobody grabs the beacon rfc today i'll just add it to our agenda to discuss at the archcom prep meeting next week :D
25921:52:05 <Reedy> well, if it's installer messages... they'll be duped :)
26021:52:26 <robla> thanks brion! that sounds like a good plan
26121:52:35 <brion> excellent :D
26221:53:12 <brion> ok that pretty much locks us up for this week i think
26321:53:15 <brion> thanks everybody!
26421:53:40 <robla> thanks all!
26521:53:46 <robla> ending in a few seconds
26621:54:02 <robla> #action brion, robla discuss beacon at E225
26721:54:15 <robla> #endmeeting

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

RobLa-WMF renamed this event from ArchCom RFC Meeting: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting: <topic TBD> (2016-06-29, #wikimedia-office).Jun 22 2016, 11:25 PM
RobLa-WMF updated the event description. (Show Details)

With the summer travel season (plus Wikimania and associated travel), this is going to be a rough week to get everyone together at this time.

Still we have a couple of options that may be worth discussion:

  • T137926 - Require 'curl' PHP extension for MediaWiki
  • T136866 - Improve the per-programming-language listings for our tools

Thoughts?

RobLa-WMF updated the event description. (Show Details)Jun 24 2016, 11:00 PM
RobLa-WMF updated the event description. (Show Details)Jun 24 2016, 11:18 PM
Jdforrester-WMF invited: ; uninvited: .Jun 29 2016, 10:43 AM

Thanks @Jdforrester-WMF ! Given the time is just about upon us, I'll keep both on the agenda, but we can give T137926 as much time as it needs.

RobLa-WMF renamed this event from ArchCom RFC Meeting: <topic TBD> (2016-06-29, #wikimedia-office) to ArchCom RFC Meeting: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office).Jun 29 2016, 7:46 PM
RobLa-WMF updated the event description. (Show Details)Jun 29 2016, 10:07 PM
RobLa-WMF mentioned this in Unknown Object (Event).
RobLa-WMF renamed this event from ArchCom RFC Meeting: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office) to ArchCom RFC Meeting W26: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office).Jul 22 2016, 12:15 AM
daniel renamed this event from ArchCom RFC Meeting W26: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:43 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W26: Require 'curl' PHP extension for MediaWiki? (2016-06-29, #wikimedia-office).