[12:49:51] hey everyone :) [14:58:11] hashar: [14:58:26] hashar: sorry, will be a few minutes late for CI meeting [15:00:15] #startmeeting CI weekly checkin [15:00:16] Meeting started Thu Nov 19 15:00:15 2015 UTC and is due to finish in 60 minutes. The chair is hashar. Information about MeetBot at http://wiki.debian.org/MeetBot. [15:00:16] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [15:00:16] The meeting name has been set to 'ci_weekly_checkin' [15:00:53] #link https://plus.google.com/hangouts/_/wikimedia.org/ci-weekly?authuser=0 Google Hangouts [15:01:15] #link https://www.mediawiki.org/wiki/Continuous_integration_meetings/2015-11-10/Minutes Last week minutes [15:02:21] #link https://www.mediawiki.org/wiki/Continuous_integration/Meetings/2015-11-19 Agenda [15:02:42] jzerebecki: not sure whether the hangout works properly [15:02:57] #topic Zuul cross repo dependencies [15:03:20] it seems you don't hear me [15:03:36] #info https://lists.wikimedia.org/pipermail/wikitech-l/2015-November/084075.html wikitech-l announcement of Zuul cross repository dependency feature [15:05:00] #topic MediaWiki extension gate [15:06:12] #info https://gerrit.wikimedia.org/r/#/c/251138/ adding wikidata to the extension gate [15:06:44] blocked on mediawiki-extensions-qunit [15:07:31] #link https://phabricator.wikimedia.org/T117886 [15:09:17] aim is to get all the extensions from mediawiki/release/make-wmf-branch [15:12:04] maybe next year :-} [15:12:12] not in november december for sure [15:12:19] looking at last week minutes https://www.mediawiki.org/wiki/Continuous_integration_meetings/2015-11-10/Minutes [15:14:13] #topic mw-set-env-mw-selenium and headless [15:14:20] from last week [15:14:20] AGREED: make the browser tests jobs to use "export HEADLESS_DISPLAY=$((70 + EXECUTOR_NUMBER % 20))" just like mw-set-env-mw-selenium (hashar, 15:27:42) [15:14:42] priority lowered [15:15:18] https://phabricator.wikimedia.org/T117561 updated priority [15:15:19] :) [15:16:42] #topic Additional Zuul merger [15:17:00] New instance on scandium.eqiad.wmnet [15:17:10] old one on gallium.wikimedia.org, still running for n ow [15:17:25] merger:merge [15:17:29] a gearman function [15:18:00] zuul-merger attempt the merge then reply back with a ZUUL_URL parameter [15:18:01] ie: [15:18:05] git://scandium.eqiad.wmnet [15:18:06] or [15:18:12] git://gallium.wikimedia.org [15:18:23] and in Jenkins [15:18:31] we use git clone $ZUUL_URL/$ZUUL_PROJECT [15:22:18] #info soonish will migrate zuul scheduler to another machine [15:23:00] #info ideally want a few jenkins maters to avoid having jenkins as a spot. But we need to puppetize Jenkis [15:27:42] #agreed next meeting on Tuesday Nov 24th 3pm UTC / 4pm CET [15:27:44] #endmeeting [15:27:44] Meeting ended Thu Nov 19 15:27:44 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [15:27:44] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-15.00.html [15:27:44] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-15.00.txt [15:27:44] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-15.00.wiki [15:27:45] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-15.00.log.html [15:29:05] minutes updated https://www.mediawiki.org/wiki/Continuous_integration/Meetings/2015-11-19#Meeting_minutes [15:29:08] published [15:29:10] whatever [19:00:02] #startmeeting Reconnecting with the shared hosting community [19:00:02] Meeting started Thu Nov 19 19:00:02 2015 UTC and is due to finish in 60 minutes. The chair is gilles. Information about MeetBot at http://wiki.debian.org/MeetBot. [19:00:02] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [19:00:02] The meeting name has been set to 'reconnecting_with_the_shared_hosting_community' [19:00:14] #link https://phabricator.wikimedia.org/T113210 [19:00:34] hi everyone, I'm gilles from the wmf performance team, for those who might not know me [19:00:45] * twentyafterfour waves [19:00:49] o/ [19:01:11] Howdy [19:01:27] I've had the idea for this meeting because I'm trying to break down the "shared hosting problem" into smaller issues [19:01:36] and I think this is a softball one to brainstorm about [19:02:31] I'll start with a couple of ideas/questions of my own to bounce off of everyone and we can go from there [19:03:04] #topic How to bring shared hosting users "back into the fold" [19:03:34] gilles: are you going to use the meetbot machinery, or just link to the wm-bot log? [19:03:45] ^ OK! :) [19:03:58] #info https://phabricator.wikimedia.org/T113210 [19:04:18] first, has the idea of opt-in automatic reporting of errors/crashes to a central server ever been considered? [19:04:55] \o [19:04:59] ignoring practical issues like how noisy it would be, etc. just the general idea of doing this [19:05:28] as in third-party installs sending crash reports to a WMF-hosted machine? [19:05:31] There's been talk of setting up an opt-in ping server, but not much conversation around errors specifically. [19:05:33] mobrovac: yes [19:05:35] gilles: how would you capture enough information about the environment to make it useful? [19:05:57] https://phabricator.wikimedia.org/T56425 [19:06:07] I don't think so, but plenty of people will just paste tracebacks on [[Project:Support desk]] [19:06:09] I guess it would be useful for statistical purposes but not sure about actually fixing any bugs that it would point out [19:06:12] we can ask microsoft what they collect twentyafterfour :D [19:06:15] twentyafterfour: I don't know, I think figuring out the details how to do this in practice would take more than an hour to figure out :) [19:06:30] gilles: indeed [19:06:43] mobrovac: /me invites microsoft to the next meeting [19:06:46] gilles: do you see crash reporting as the biggest issue on shared hosting? [19:06:52] is there an agenda? there's a specific point i'd like to raise [19:07:02] crashes especially would be hard. they would really need PHP/HHVM binary support [19:07:26] gwicke: not at all, but we're not here to discuss what's wrong with shared hosting in general, I'd like to stay on the topic of reconnecting with the installs and the users of shared hosting [19:07:31] * gwicke is interested in an agenda as well [19:07:37] do we have some data about trends in shared-hosting? as in, what percentage, is it increasing / decreasing, etc? [19:07:46] mobrovac: don't be silly [19:07:50] that's crazy talk [19:08:00] we have really strong feelings tho [19:08:03] Getting something like T56425 (install ping) would be really nice for a better idea of how many wikis are out in the world [19:08:09] ori: ah i see [19:08:09] I hear geocities is considering a comeback [19:08:19] lol [19:08:19] bd808: +1 [19:08:38] #link https://phabricator.wikimedia.org/T56425 [19:08:48] mobrovac: we really don't even track tarball download stats well today [19:08:49] What would collecting this information be useful for? Knowing what issues MediaWiki is having on shared hosts? [19:09:00] by shared hosting do we mean specifically people running on a site where they have zero sysadmin/root access? [19:09:00] @mobrovac https://phabricator.wikimedia.org/T113210#1722738 [19:09:06] or just anyone that isn't a wikifarm? [19:09:08] cheers [19:09:10] A few comments from individuals working at shared hosting companies. [19:09:20] ckoerner: yes, if we consider that those users are unlikely to jump through the hoops of reporting them. right now we rarely see bug reports from shared host users [19:09:46] ckoerner: we (wikimedia foundation staff) don't know what value working on third-party users concerns has [19:09:48] twentyafterfour: it comes in very different flavours, but that's the general idea, yes. not being root [19:09:50] gilles: do you plan to discuss distribution / packaging in this meeting? [19:10:06] it's a moral value for some of us, but you can't force a moral value on everyone, so the best way to get buy-in is to demonstrate value with numbers [19:10:14] Got ya. [19:10:29] gwicke: not today, I'll run more office hours for those. there might be 3-4 of them total, maybe more [19:10:31] That's good to know [19:11:22] ckoerner: thanks for that link, that is very good perspective [19:11:22] gwicke: unless you think that distribution and packaging can make shared hosted users more likely to report bugs, contribute code, etc. [19:11:24] it's not that anyone thinks that improving the software is a bad idea; it's just that it's very hard to know how to prioritize work relative to other things that we could be doing (and which may be wikimedia-specific) without having some sense of what the impact would be [19:11:31] I think ideally that installers and patch tools would be a shared MediaWiki the FLOSS project concern and not a WMF concern directly. [19:11:54] But the WMF should work closely with that community to make sure we don't botch things up for them [19:12:32] Right, isn't shared hosting just one of the symptoms of the tension between WMF and movement priorities and third-party users? [19:12:39] shared concern sure, but for tactical reasons you want to find a way to engage WMF staff in that work, because they represent the biggest pool of available labor [19:12:42] Not in a negative sense of 'tension', but just in that it exists. [19:12:49] exactly, and what I'd like us to do here is come up with ideas on how we can connect with that community better [19:13:07] gilles: I'm interested in third party users in general, not just shared hosting users; based on the feedback we have on your task & in many discussions around https://phabricator.wikimedia.org/T87774 it seems clear that most users care about ease of use and lack of "server administration" overheads, and aren't wedded to shared hosting as a solution. [19:13:22] wikiapiary is really useful, who runs that? [19:13:31] because of this, I think it would be more productive to re-focus the discussion on third party use in general [19:13:39] and is s/he / are they here today? [19:13:39] I can only speak for myself, but this is meeting is a really good step. Being willing to listen and talk. [19:13:44] gwicke: that's true, but I'm considering the here and now, and we have thousands of people using mediawiki that way, surely running into problems, and not reporting back to phabricator [19:13:58] ckoerner: :) [19:13:58] that's a problem worth solving, because it would still exist with other platforms like containers [19:14:16] Jamie Thinglestad runs Wikiapiary. He is not present. [19:14:42] besides ckoerner do we have anyone who isn't a WMF employee here? [19:14:45] especially for non-technical folks, one thing I've noticed is that from mediawiki itself it's pretty hard to figure out where to go. consider a person that doesn't even know "mediawiki" is the name of what they're running [19:14:59] to them, they've just picked the "wiki" option on their point and click host's installer [19:15:00] * ori sends ckoerner a hiring packet [19:15:09] :) [19:15:35] especially if you consider how generic a name "mediawiki" is, it might not sound like an actual product name to non-technical users [19:15:50] bd808: it's the right question to ask, though, because ventriloquating such users ("surely they must think that.. ") is unconvincing [19:16:07] so, the obvious way they can find out about phabricator is to click on the tiny logo at the bottom of their wiki, which they have to guess to be clickable [19:16:08] gilles: that's a simpler case, as commercial providers can and do custom packaging [19:16:14] as do wiki farms [19:16:15] then they land here: https://www.mediawiki.org/wiki/MediaWiki [19:16:21] ori: yeah. I was hoping for some first hand testimony [19:16:27] can you spot the link to phabricator on that page? took me a while [19:16:30] So, I don't want to come across as tooting my own horn here, but the MediaWiki Stakeholders' Group did put together a little survey and some results: https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey [19:16:48] #link https://www.mediawiki.org/wiki/2015_MediaWiki_User_Survey [19:16:48] This might be helpful to bring some data, and people, into the conversation. [19:17:06] ckoerner: toot away! the rest of us are talking to shadows on the cave wall [19:17:08] ckoerner: wow, that's really useful. i'm embarrassed that i didn't know about it. [19:17:24] Yeah, our marketing guys sucks [19:17:31] [19:17:33] :) [19:17:46] Current status of MW on shared hosting is that it works but you don't get VisualEditor and any service ending in "oid". What is upcoming that will make the shared hosting situation worse? [19:18:08] the demise of shared hosting in general, I suppose [19:18:29] but it'll be replaced with something else, and if users of that shiny new thing are as silent as shared hosting users, we still have the same problem [19:18:50] sure, they might use a closer architecture to our own, but if they don't report bugs, we'll still have to think on their behalf [19:19:05] it is already possible to run MW from docker images in two lines, without us having done anything: https://phabricator.wikimedia.org/T92826#1804775 [19:19:23] Amazon and others now let you run docker images with a couple clicks [19:19:29] spagewmf: I think the biggest "threat" to shared hosting is the lack of pure PHP implementations of new features that are developed for Wikimedia as external services. [19:19:43] and are docker users who run into problems specific to that platform engaging with us? [19:20:06] we don't provide anything to them right now [19:20:09] apart from tarballs [19:20:48] right, but what I'm saying is, are you seeing more engagement from people who use that? on mailing lists, phabricator, on wiki [19:21:04] spagewmf: that lack today exists in the form of parsoid+restbase being required for the latest VE integrations [19:21:10] or is it another black hole like the tarballs, publishing them and then rarely if ever hearing from users [19:21:27] cscott: is there a well-written summary of RMS's position about the moral obligation one has to report bugs upstream? [19:21:32] gilles: having a lot of problem reports on mailing lists should count as a negative ;) [19:21:37] I don't think tarballs are a blackhole, we hear from those users pretty frequently on mediawiki-l and other support places [19:21:38] So the definition of what MediaWiki is to a third-party user is a big odd-shaped question. Is it just MW core and a few extensions? Or is it the experience they'd have on a WMF-led wiki (with VE, Echo, Flow, etc.)? [19:21:47] robla: let me see [19:21:56] Then you have the entire SMW arena. [19:22:01] It's tricky. [19:22:01] spagewmf: I am wondering how PHP 7 support will pan out on MediaWiki supporting it or if it will become exclusively HHVM. [19:22:03] oh, did i miss a meeting on shared hosting? [19:22:11] gilles: but, I agree that having code contributions etc are good, if they align with our goals [19:22:14] Trela: it won't become exclusively HHVM [19:22:25] cscott: you're soaking in it :-) [19:22:33] i'll have to read some backlog [19:22:40] has anyone mentioned node-php-embed yet? [19:22:52] it's too new for us to tie the future of mediawiki to the future of the hhvm platform [19:23:02] ckoerner: actually SMW is a good example of something that seems to thrive outside of the WMF sphere. [19:23:22] it's very important to retain the ability to jump ship to zend php if it becomes better (either because it is improved, or because hhvm is neglected) [19:23:22] the fact that hhvm doesn't support x86 could be an issue [19:23:42] cscott: how so? [19:23:55] cscott: no mips support, either [19:23:58] ckoerner: re: "The general consensus of respondents is positive. MediaWiki is a prefect fit for many individuals and organizations. The software is robust for most needs and the many extensions make customization approachable.", I could help but think that the selection bias makes the result not as useful as it could be. Can you think of a way to get in touch with people who decided to migrate away from MediaWiki, or found it [19:23:58] unsuitable? [19:24:16] gwicke: but it does support ARM :P [19:24:20] right. PHP is written in plain old C, can run on anything. a bunch of odd users would come out of the woodwork if we moved to HHVM. [19:24:29] however, these will seem increasingly antique as time goes on [19:24:50] so i bet by the time we'd really consider dropping PHP support it won't be a big issue. it probably will be a little issue, though. [19:24:59] Sounds sensible. I am pushing for PHP 7 at my organization by the middle of 2016. [19:25:00] Hmm, folks who left MediaWiki. [19:25:05] gilles: so, your focus for this meeting is getting in contact with third party users in general? [19:25:06] Gosh, I can't think of a good way. [19:25:16] right, I mean we don't support running on Atari, there's a point where some processor instruction sets are too old to support. we'd have to get an idea of the market share of x86 [19:25:39] ori, ckoerner: good point! could be confluence users, e.g. [19:25:41] robla: rms has a collection of essays somewhere, i can't seem to find it right now though. [19:25:50] gilles: i bet PHP would compile on linux/atari. [19:25:59] it's pretty much straight C code [19:26:03] unlike HHVM [19:26:10] gwicke: yes [19:26:14] let's stop talking about HHVM because it's not relevant; even if we very selfish only take the WMF into consideration, i don't think we'd want to lose portability. [19:26:22] Right, in the context of third-party usage of MediaWiki, shared hosting is the bottom rung. Folks running on VPS, private servers, etc. would be above the rising requirements. [19:27:20] (cscott, last thing i'll say on the matter: right now we have two software vendors (zend and facebook's hhvm team) competing with each other on performance and features, it's the best possible situation for us.) [19:27:28] the relative adoption of Confluence (and other software) _seems_ relevant to me. https://www.google.com/trends/explore#q=%2Fm%2F05nyz0%2C%20%2Fm%2F01vw7p&cmpt=q&tz=Etc%2FGMT%2B8 [19:27:35] bd808: VE is not going to change. Some admins of existing hosted wikis are OK with no VE judging from T113210. Can we leave it up to shared hosting providers (Google showed ads by arvixe.com, webhostingbest10.com and siteground.com) to offer a "sign up with us, because VisualEditor works with our shared hosting!" ? [19:27:52] so no one has mentioned https://phabricator.wikimedia.org/T114457 yet? [19:28:04] ori: oh, i totally agree re: competition [19:28:13] ori: it's why javascript is so healthy right now. [19:28:27] I love the competition that has come around. Great for the community as a whole. [19:28:30] cscott: since you asked, I think it must be a fun toy for you but in general is a horrible idea [19:28:38] it seems like there's a little bit of fork pressure between zend and hhvm, i hope that doesn't get out of hand. [19:28:51] ckoerner, zabien: could we somehow compare the list of mediawiki installations on wikiapiary from a year ago to today and see which of those hosts currently has another wiki/cms software installed? [19:29:04] why isn't running on node shared hosting a reasonable option? [19:29:20] because the core software product is PHP? [19:29:21] I've been to two SMWCons this year. Probably the closest thing we have to a MediaWiki-specfiic conference. Both SMWCons struck my as incredibly interesting looks into how folks are using the software. I'd encourage you to attend one if only to see what's going on in the community. [19:29:25] so, does https://www.mediawiki.org/wiki/MediaWiki look usable from a non-technical user's perspective? it's comprehensive but I feel like it's trying to do too many things at once for a portal [19:30:03] #action ask the UX research team to evaluate usability of https://www.mediawiki.org/wiki/MediaWiki [19:30:27] I think its main problem is the target audience [19:30:35] there was an OPW project to redesign the home page, but I don't think it went anywhere, /me finds link [19:30:36] it's doing a good job at being the front page of an open source project [19:30:41] I think most shared hosts don't allow process like node.js to run in the background. [19:30:54] but a non-technical user doesn't care about that, they just want to get help or find information [19:31:03] cscott: from my point of view, nodejs is an add-on needed for VE. Making it the center stage platform and PHP look like a leftover concern is unbalanced. [19:31:03] ori: interesting, i'll note it down, so we can have a look at it (the stakeholders' group) [19:31:30] bd808: that point would be more interesting to discuss, but is OT for this meeting, I think [19:31:31] bd808: i think your point of view is inaccurate. i think apache is the center stage platform. [19:31:37] php doesn't even provide an http server. [19:31:52] #link https://www.mediawiki.org/wiki/MediaWiki/Homepage_redesign [19:31:54] #link https://phabricator.wikimedia.org/T653 [19:32:00] thanks legoktm [19:32:11] realistically, going forward, mediawiki is a platform build of multiple pieces of software, including a database, a web server, and PHP. [19:32:27] i think it's starting off on the wrong foot to assume that the PHP side of that platform is somehow priviledged [19:32:38] * robla notes what my successor at Linden Lab said about MediaWiki vs Confluence http://wiki.secondlife.com/wiki/User:Oz_Linden/Office_Hours_Archive_2010-06-09 [19:32:40] cscott: uh, sure it is [19:33:05] I guess all the business logic is jsut accidentally in PHP? [19:33:16] cscott That's history working in PHP's favor I think. [19:33:27] bd808: there is a large section of "mediawiki installation" which describes how to program [19:33:30] the PHP side of the platform is absolutely privileged, it exists [19:33:43] the SQL side of the platform is also priviledged [19:33:44] cscott: How does MW running on Nodejs bring shared hosting users "back into the fold"? [19:34:06] exactly, I think that switching technologies won't solve that problem [19:34:19] spagewmf: i'm just saying that, realistically, "running PHP" means running a stack of software. the question should be "how to efficiently set up that stack" (esp for small wikis) [19:34:28] not focused short-sightedly on the PHP part of that stack [19:34:43] we have precious few non-WMF stakeholders present and we WMFers are doing a shitty-ass job at listening to them IMO [19:34:53] i'm not really "adding node", i'm just replacing apache with express. all the other components are just the same. [19:34:56] After debating this for many years, I'm personally itching to actually do something about the main pain points people have been raising repeatedly; To me, the most urgent one is the distribution question, and I think we can make some progress there with relatively modest effort. [19:35:14] cscott: I think your point is sinking into my thick head. You are saying that nodejs can provide an http container for PHP to execute from and that is not different than apache/nginx/etc [19:35:14] in particular, node-php-express is an SAPI just like mod_php [19:35:26] bd808: right. [19:35:34] cscott: fine but that isn't the topic of this meeting, unless shared hsoting providers are offering 1-click install of Nodejs packages. [19:35:48] bd808: and that if our larger model is "looser collections of services, communicating with http", we need to start paying attention to how the http part interoperates [19:35:51] and even if they were, users wouldn't know they're using node [19:35:56] spagewmf: they are [19:36:06] like they're probably unaware of using apache, php or even mediawiki [19:36:18] gilles: right. i totally agree. [19:36:20] I'm rather interested in how shared hosting users upgrade (if they do at all), according to https://wikiapiary.com/wiki/Statistics 68.23 % of known wikis are using unsupported versions. And if people aren't upgrading to newer versions, they're not getting newer features, which seems like less of an incentive to stick with MW. [19:36:29] * gwicke has heard the phrase "I'm listening" a bit too much recently [19:36:32] So shared LAMP-stack hosts are a dime a dozen. Relatively easy to get one and run. Every addition (or replacement) creates more friction in getting a fleshed-out MediaWiki installation up and running. [19:36:39] that's why i'm objecting to the "javascript"/"node" part of the objection. we need to be thinking about the big picture, how does the user get their wiki running. [19:36:49] ckoerner: yeah, LAMP stacks are a pain. [19:36:51] gwicke: cynical misuse does not mean listening is unimportant [19:36:55] this is classic second system syndrome [19:37:00] I know most shared hosting providers include a 1-click installer, but does that also come with a 1-click upgrader? [19:37:00] Heck, I run a dedicated host inside my org and getting security and server to review the idea of installing node.js took me a few weeks! [19:37:02] :) [19:37:05] ckoerner: as it turns out, you need more than just "LAMP", mediawiki has a bunch of other packages which are required [19:37:13] ori: listening shouldn't be an excuse for inactivity, though [19:37:13] apache is so clunky, let's just have a super-thin SOA app container written in node [19:37:23] something else I was pondering about is whether there would be value to integrating the support desk and/or phabricator on their wiki directly (as an option, of course). I'm just thinking about reducing the navigation path to interacting with us to its absolute minimum [19:37:28] if you had ten million dollars and a team of fifty i'd say go for it [19:37:41] legoktm: the one-click I used at 1&1 in the past did not. To get a newer version you had to backup the db, uninstall the wiki and install it again [19:37:55] but something you hack on in your spare time won't enjoy the same kind of support [19:38:22] anyway, i'm not really advocating for one approach or another at the moment, i'm just saying that we need to be looking at the big picture, including the http server, the db, and all the other required packages. [19:38:23] legoktm: it seems like in the survey linked to earlier people mostly upgrade "when they need to", I think that sounds like they would only do it if a new feature interests them or something along those lines [19:38:27] there are 57,127 questions on stackoverflow tagged 'apache' [19:38:54] to me, this discussion of node vs. apache vs. php seems to miss the point completely [19:38:54] bd808: what does "uninstall the wiki" entail? [19:38:56] ori: So there's a funny segue. Is third-party support of MediaWiki a 'spare time' thing or is there any interest in dedicating resources to it? [19:39:17] #action investigate upgrade experience for one-click installs [19:39:18] gwicke: why? what do you think is the point? [19:39:19] people don't care about which tech is powering it; they care about having something that works with the least amount of effort [19:39:34] giles: or that the upgrade process is daunting and they'd only do it if needing new features/security. [19:39:35] gwicke: yeah, i agree with that. [19:39:49] ckoerner: spare time. There is no strong buy-in across the org. Some people think it's a misuse of time. [19:39:57] bd808: they do now I believe, plesk in general has gotten better in teh last few years (since I had to use it too) just fyi [19:39:58] gi11es: I had to encourage and support a few people to upgrade their wikis this year already when they found out they needed to support updated extensions. Most of them where on MW 1.19. [19:40:05] robla: http://www.gnu.org/philosophy/imperfection-isnt-oppression.html, but that's not quite right. [19:40:08] ckoerner: that said, some of the strongest and most prolific developers are very strongly committed to it, so it's not marginal [19:40:12] legoktm: as I recall (its been a long time) it was a button click. Then a second click to install and then a very manual process of putting my content back in the new db that was created [19:40:19] ckoerner: right, the effort/reward ratio isn't great [19:40:48] #info 1-click installers don't provide 1-click updaters. legoktm: the one-click I used at 1&1 in the past did not. To get a newer version you had to backup the db, uninstall the wiki and install it again [19:40:59] we don't actually have a product from an end user's perspective [19:41:05] Trela: on what kind of hosting platform were they? [19:41:13] according to https://www.mediawiki.org/wiki/Hosting_services only two shared hosting providers offer VE. [19:41:39] gilles: Mostly shared hosting. Some had SSH and/or FTP access. [19:41:53] gilles: I suppose the next question is, are we doing a good job promoting our new features, and is that reaching shared hosting users? The installer has an option to subscribe to mediawiki-announce, but do shared hosting users get that option if they use a different installer? [19:42:04] Trela: did they have to do the upgrade manually? [19:42:22] gwicke: I think that we sell MediaWIki short. It's a great platform and with some of the work that's happened recently it's a really good platform to use. [19:42:25] legoktm: that's a great point, there's no built-in "new version, new features" nag [19:42:48] so they probably don't even know that they're running something outdated [19:42:51] gilles: In these cases, yes. [19:43:13] ckoerner: my point about the product is that it's not packaged as a product; others are building actual products on top (one-click installers, wiki farms), but we do not offer this ourselves [19:43:17] #idea find (better) ways to advertise new versions/new features to shared hosting users [19:43:39] spagewmf: by the time of the dev summit, every node shared hosting provider should be able to offer VE. ;) [19:45:00] robla: i searched google for "cornered in an elevator by richard stallman" and found rms/esr slash fiction [19:45:28] #info After debating this for many years, I'm personally itching to actually do something about the main pain points people have been raising repeatedly; To me, the most urgent one is the distribution question, and I think we can make some progress there with relatively modest effort. [19:46:09] so several people have brought up custom installers, etc. how much do shared hosts/one-click hosts customise mediawiki? [19:46:16] cscott: thanks! the "imperfection isn't oppression" article gets the point across that I was trying to make earlier. let's get "third party users" filing bugs, and then let's help *them* fix them! :-) [19:46:40] So one of the groups that is most impacted by the transition to services (-oids and what not) are users of MediaWiki on shared hosts. Getting those folks to upgrade involves encouraging those hosting companies to provide better paths for updages (or making something ourselves hosting companies can use). [19:46:43] #idea https://phabricator.wikimedia.org/T114457 lets you replace apache with node, which might help with the "http configuration" part of a mediawiki install (especially if multiple services are involved) [19:46:54] Getting folks to update also goes a long way for a positive image of MediaWiki [19:46:57] are they just building around it, or are some actually going as far as stripping the logo, for example? which would remove the single entry point to mediawiki.org [19:47:20] gilles: I used to run one of those, and part of my added value was in customizations [19:47:27] I know for a long time (and even to this day) the WordPress community struggles with WP getting a bad rep for being insecure due to old installs. [19:47:55] I will add a link to [[Software_bundles]] to https://www.mediawiki.org/wiki/Manual:Installation_guide . Should our crack Marketing department to get container providers to promote their offerings there? [19:48:43] ckoerner: there is definitely something to be done about nagging to do security updates [19:48:49] spagewmf: I find the warning about web host auto-installers to be humorous given the conversaiton. [19:48:56] on that page [19:49:03] ckoerner: my Wordpress installation has one-click updater, and as I recall you can even opt-in to automatic updates [19:49:21] spagewmf: we don [19:49:30] spagewmf: Yep. [19:49:42] * gwicke pulls back fat finger [19:50:23] spagewmf: we don't have official images for anything yet at this point; once we have those (docker, AMI etc), then we should definitely list them there [19:50:58] spagewmf: I updated the Hosting_services page. Gamepedia is actually a wiki farm. [19:50:59] robla: i've been making the "wmf can't do it all" argument at https://office.wikimedia.org/wiki/User:CAnanian_(WMF)/Strategy_thoughts#Community_ownership_and_the_role_of_the_Foundation as well [19:52:37] the thing is, if something else than the foundation has to take care of non-technical installs support, it has to be funded appropriately to fulfil that mission [19:53:06] Ultimately, I think WMF needs to define what we *are* going to do wrt third party users, and what we *won't*. Priorities don't always align, and we should be clear where we will compromise, and how many resources we are willing to spend. [19:53:14] otherwise it'll be the same issue of it being a free time project for whoever this lands on, and as we know, the situation can stay idle for years when that's the case [19:53:30] gwicke: +1 [19:53:43] I agree [19:54:50] I tried to push pretty hard on that question a year ago, but I haven't brought it up since Damon left really [19:55:14] I think it'd be premature to cut off support officially, because I don't feel like we've really tried to get the real value we can from 3rd-party installs in the wild, which is an amount of bug reports, security reports, code contributions, proportional to the install base [19:55:36] we have 6 minutes left. It feels like the conclusion is the same as other meetings: Core MediaWiki remains shared-hostable but if you want VE and other new features you need something else, and there are lots of options. [19:55:37] Is there an opportunity to work with the community to define that support, communicate it, and then if there is work to be done outside, find resources to accomplish the things non-WMF and core movement folks need/want? [19:55:42] since we're doing a poor job squeezing what's useful for us out of those mediawiki installs, it appears to bring little value to us [19:55:59] * subbu is skeptical about getting code contributions from shared hosting installs [19:56:44] subbu: There are folks in other open source communites (like WordPress) that work at shared hosts and contribute code, feedback, etc. [19:56:50] spagewmf: i agree with your summary of current status, but i think we also need to look longer-term. [19:56:53] oh, from shared hosts. [19:56:53] We need to form those relationships [19:57:12] subbu: I don't think we'd get much code contributions either. But I think we'd get a decent amount of feedback, bug reports, etc. that we'd get from any MW user. [19:57:19] i misunderstood. [19:57:19] so from shared hosting providers yes. [19:57:38] Who's making that outreach? Who has that on their plate? [19:57:47] The Stakeholders' are trying and are happy to help [19:57:50] (at least I am) [19:57:52] from shared host users probably anecdotal but not impossible, some people pick shared hosting for the cost/power ratio it offers [19:58:00] doesn't mean they can't code and contribute code [19:58:25] are we claiming that docker and or AWS installations are "shared hosting"? [19:58:26] ckoerner: you're saying "we" need to do this, but then you seem to be implying "you guys need to" [19:58:32] ckoerner: how would we reach out to shared hosting users? in practical terms [19:58:44] robla: Both. All of us. [19:59:01] Those that are third-party and involved workign with WMF and Wikimedia to pull more folks in. [19:59:07] gilles: in terms of cost / benefit, do you have indications that extra effort to support shared hosting is worth it in terms of potential contributions? [19:59:09] cscott: that's why I rephrased the big task for the dev summit as "non-technical installs", the tech in question is less relevant [19:59:28] gwicke: I feel like we can't gauge that before we've tried reaching those people [19:59:30] ckoerner: you're also saying "help" as if you're waiting to be led [19:59:32] giles: perhaps we go a level higher and talk to the hosting companies. [19:59:44] ckoerner: yeah that'd probably be a good start [19:59:58] gilles: right. so folks who use a docker image, say, have all the dev tools they like available, and they can customize their wiki, contribute code, etc. [19:59:58] #action reach out to shared hosting providers about outreach to users [20:00:00] For updates and support, can we built into core MediaWii a parser tag and in the default install it is on the default Main_Page? [20:00:07] gilles: you seem to be setting up a catch-22 there ;) [20:00:08] gilles: maybe we could get the new partnerships group to reach out the hosting companies? [20:00:10] robla: Hmm. That wan't my intent. I'm not here to ask for a handout. [20:00:19] it's the "old" model of shared hosting, where there's no shell available, where contributions from users back upstream to us are made difficult. [20:00:29] gwicke: not quite, if we do our best to reach out and don't get any value, then we know it's a one-way street [20:00:30] But to figure out something where we can all work toward a mutually benificial goal. [20:00:56] spagewmf: Special:Version would be a good spot to have a "New Version Available" indicator for logged in admins. [20:00:58] gilles: can we figure this out without making the investment? [20:01:02] As a third-party user, I would like to know that the platform is stable, and to know that I can influence that [20:01:06] spagewmf: probably Special:CheckForUpdates would be better, with default permissions only viewable by admins [20:01:06] in time & money [20:01:11] (I don't know if that makes sense) [20:01:15] alright, thanks everyone, we're out of time. there will be more IRC office hours about shared hosting/non-technical installs :) [20:01:15] spagewmf: but a link on the main page is fine [20:01:16] ckoerner: I'd be thrilled if you led this. what help do you need? [20:01:19] #endmeeting [20:01:21] Meeting ended Thu Nov 19 20:01:20 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [20:01:21] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-19.00.html [20:01:21] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-19.00.txt [20:01:21] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-19.00.wiki [20:01:21] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-19.00.log.html [20:01:44] feel free to keep chatting, though, I just have to jump into another meeting, so my attention might be laggy [20:01:53] gilles: how do i find out about future shared hosting office hours? i just stumbled into this one. [20:01:57] * robla has to go too [20:02:04] or rather, got pinged by robla [20:02:08] Robla, perhaps we could talk more later? [20:02:14] cscott: I'll advertise them on the usual mailing list as well as the big dev summit phab task [20:02:40] I was waiting to see how that one went before scheduling more [20:02:43] ckoerner: sure...just ping me in #wikimedia-tech later [20:02:46] ok, i'm subscribed to the phab task, i'll have to pay more attention to phab mail. thanks. [20:02:50] cscott special page works too, and the default Main_Page can transclude {{Special:CheckForUpdates}} [20:02:51] Will do [20:03:26] i think i saw the announcement on some email list for sure .. i cannot find which one it was. [20:03:40] I think I sent it to wikitech, wmfall, engineering [20:04:13] gilles: probably not your fault, i'm just drowning in email [20:04:24] yeah right, email volume has been high... [20:04:27] very interesting meeting, everyone. Thanks Gilles for organizing this [20:04:55] * subbu 's thunderbird filters probably sent it to a place where he cannot find without search [20:04:59] legoktm: this is where your AI implant spits out a link to the existing Phab task for "implement a Check for updates" :-) [20:05:00] spagewmf: might be interesting to have a cron job hit a special page that would mail the wiki admins when a critical update was available. [20:05:37] a phab-searching irc bot would be nice [20:06:02] spagewmf: I swear it exists, but I spent 5 minutes looking for it and couldn't find it [20:06:26] * legoktm searches bz instead [20:06:47] legoktm: how can I support you for the CTO job if your lookup rate is only 96% ?! [20:07:01] oh [20:07:05] congratulations legoktm !!!!!! [20:07:22] heh [20:07:45] now lets port everything to python including browser side code [20:08:31] spagewmf: aha https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting [20:09:00] I'm pretty sure someone (TimStarling ?) hacked a PHP-only web server for MediaWiki. [20:09:42] hashar: I switched my CTO vote from you back to legoktm :) This election is too close to call :) [20:10:51] legoktm: thanks, MarkAHershberger wrote that. I'll create a Phab task linking to it [20:11:38] I use/used a maintenance task locally that looks at Gerrit to see if any installed extensions are out of date, download them, and stage them for commit into the local repository. Basically a Composer/Packagist for MediaWiki extensions. The base functionality of that, version checking, would be nice to have as part of update checking. [20:15:11] Trela: I'd love it if on Special:Version it showed the current version of my extensions, but also the most recent release. A small baby step toward what you're describing. [20:15:18] spagewmf: look at maintenance/dev/ . It uses php -S ( Run with built-in web server. ) introduced in 5.4 iirc [20:15:21] Trela: have you looked at the `vagrant git-update` command implementatioN? https://phabricator.wikimedia.org/diffusion/MWVA/browse/master/puppet/modules/mediawiki/templates/run-git-update.erb [20:16:14] spagewmf: I have not, will do. [20:16:15] spagewmf: the idea is you can run php listening on a port and using it s own server and have it load mediawiki :-} [20:16:25] ckoerner: neat idea, phab it™ [20:16:44] ckoerner: although for many extensions the latest version is nothing but localization udpates [20:17:53] hexmode wrote https://www.mediawiki.org/wiki/Version_check_and_opt-in_site_reporting , wish he was here [20:26:53] cscott for future meetings, https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours [20:29:10] but often people don't add to that. There are also Events and Meetings pages floating around that get even fewer updates [20:30:30] spagewmf: please cc me on the phab task you file :) [22:31:16] marxarelli: https://etherpad.wikimedia.org/p/Group_communication [22:43:56] join #wikimedia-labs [22:47:15] quiddity: ;-) thank you for disclaiming. I did have second thoughts pasting out of Loomio...