[15:26:47] Hello all [21:01:18] ok, RFC meeting about to start... [21:01:22] do we have a meetbot? [21:01:25] #startmeeting [21:01:26] DanielK_WMDE__: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [21:01:34] #startmeeting TechCom RFC meeting [21:01:35] Meeting started Wed Sep 6 21:01:34 2017 UTC and is due to finish in 60 minutes. The chair is DanielK_WMDE__. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:35] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:35] The meeting name has been set to 'techcom_rfc_meeting' [21:01:37] yay. [21:01:53] #topic Separate "application" and "project" concerns by moving most of MediaWiki within a /core folder [21:02:07] #link https://phabricator.wikimedia.org/T167038 [21:02:40] o/ [21:02:57] hey there! [21:03:22] here [21:03:38] davidwbarratt: oh, excellent! I what just about to go looking for you! [21:03:57] I should have contected you directly last week, and failed to do so. sorry about that. [21:04:10] no problem! [21:04:36] so, what are the main questions you would like to have answered in today's meeting? [21:05:29] ...and can you explain what you mean by "project" concerns? [21:05:55] uhh, well I know that this needs to become an on-wiki RFC, so this is more of dipping the toes in before we get there. [21:05:59] and yes... [21:06:20] so a project concern would be your own project, not the application [21:06:33] on-wiki rfc pages are no longer needed. you are already knee deep in the process now :) [21:06:40] LocalSettings.php is an example, but if you are running a custom Skin or a custom Extension, those would be in your projecct as well [21:07:00] DanielK_WMDE__ oh boy! well that is news to me. [21:07:06] hehe :) [21:07:48] legoktm has mentioned that a lot of people already have MW core in a /core directory, alongside /extensions, /skins, etc. [21:08:04] so, it seems to me that most things are already separated that way. but the root folder has a mix of configuration and entry points. [21:08:23] I gather what's different about this is the idea that you should use composer to get the core? [21:08:57] ideally yes. Although you can argue that the entry points are part of your project (and shouldn't change very often if ever) [21:09:07] and also suppoorting more than one directory for extensions and skins [21:09:20] i.e. if I download the tar the extensions should be in /core/extensions [21:09:27] but I should have my own extensions directory as well [21:09:36] in that case, i'd suggest to create a new repo that contains just a wrapper, and pulls in core via composer. i.e. don't change the old repo, make a new one that somehow pulls in the old structure in a sub-folder [21:09:51] DanielK_WMDE__ that is one way we could do it [21:10:18] and is not too dissimilar from what I proposed here https://www.drupal.org/node/2385387 [21:10:26] it would provide full backwards-compatibility for the unwashed long tail of gazillion of private wikis... [21:10:35] but it has been said that we don't want to have extensions installable with composer, right? [21:10:39] <_joe_> davidwbarratt: I have one fundamental question: are we talking about production deployments of MediaWiki and ease of upgrade of those, or about people doing development on top of it? [21:10:45] TimStarling that's a different issue [21:10:45] the RfC (on Phab) is pretty clear about what should be done but very vague about why it should be done [21:11:05] IMO that makes it hard to have a productive discussion [21:11:05] _joe_ I'm not thinking of WMF so any "user" [21:11:23] you would have core installable by composer but not extensions? [21:11:26] tgr hmm, ok, I can tighten up the reasons why [21:11:35] <_joe_> davidwbarratt: I'm not talking about WMF, I am asking: do you want to make the life easier for sysadmins or developers? [21:11:46] TimStarling you would, but I'm saying that's a different Phab ticket. :) [21:11:54] <_joe_> or better, which of these groups is your main focus? [21:11:59] I think there are wins in terms of user friendliness of separating files that a sysadmin edits/maintains (LocalSettings, images/, etc.) from the directory structure of MW (core+extensions+skins+vendor, etc.) [21:12:11] _joe_ both? I mean I am a developer so maybe devops? [21:12:13] having classic use case like "as a wiki admin on a shared host I want... because..." would make the discussion more focused IMO [21:12:33] legoktm: i agree. but i don't like thinking of entry points as "project" files like configurables... [21:12:41] tgr: +1 [21:12:58] btw, everyone is encouraged to make liberal use of #info and friends [21:12:59] DanielK_WMDE__: +1, I don't think they should be. sysadmins should not be editing entry points [21:13:11] DanielK_WMDE__ what would this wrapper be called if we went that way? certainly not "wrapper" [21:13:18] DanielK_WMDE__ maybe "project"? [21:13:26] or "app"? [21:13:32] <_joe_> legoktm: in terms of what a sysadmin has to do when upgrading MediaWiki, that's a minor annoyance (non-existent, I'd say) compared to having to check all settings to upgrade/add between versions [21:13:41] davidwbarratt: mediawiki-webapp or some such, probably [21:13:53] DanielK_WMDE__ kk [21:13:56] <_joe_> that's why I am asking, if the focus is on wiki admins, I think this is the wrong problem to solve [21:13:58] ...we already have mediawiki-vendor, though that's wmf only [21:14:16] #info prior to extension.json, extensions could be in any directory you wanted. Now there is a requirement that they're all in the same directory ($wgExtensionDirectory) but they can still be symlinked in or something [21:14:47] legoktm could we have 2 directories? [21:14:51] separate bundled extensions from own extensions (in different directories) would be great [21:14:59] <_joe_> most people that want to use git for deployments will use git submodules [21:15:01] _joe_: I disagree, setting up MediaWiki so it can be easily upgraded could be way more inconvenient than it is now [21:15:04] _joe_: It's definitely not non-existent due to people running into this issue when upgrading :) [21:15:14] Vulpix: why? [21:15:38] #info instead of changing the structure of the mediawiki repo, we could introduce a new repo that has the new top level structure, and would pull in the mediawiki (core) code in a sub-folder [21:15:53] _joe_ I would rather use Composer than git submodules. :) [21:16:14] legoktm: when upgrading, it would be easier to unpack the whole tar and then it's clear which extensions I have to move from the old folder to the new without overwriting the bundled ones [21:16:17] this is not nearly the biggest discomfort sysadmins face when upgrading, but that's no reason to stop someone from working on it ) [21:16:32] with a wrapper, using compser makes semantic sense - the "app" depends on core, and on skins, and on extensions. [21:16:34] in general i would vote for the composer-based solution, to fit into the php ecosystem with things people would expect. [21:16:46] DanielK_WMDE__ exactly [21:16:52] mediawiki core pulling in extensions via composer does not make sense, because the extensions depend on core, not the other way around. [21:16:56] it's currently possible to load MW as-is with composer, isn't it? [21:16:56] DanielK_WMDE__ or we would need to make a subtree split [21:17:05] (works for me, in testing anyway) [21:17:06] I don't really see tarballs as being the future of distribution, so the idea of an extension bundled in the core tarball seems anachronistic [21:17:15] samwilson right, we'd just make an official starting point [21:17:17] #info separate bundled extensions from own extensions (in different directories) would be great legoktm: when upgrading, it would be easier to unpack the whole tar and then it's clear which extensions I have to move from the old folder to the new without overwriting the bundled ones [21:17:23] managing versions with composer would also be nice, because i can't tell you how many times someone posts to the CirrusSearch help page with a problem, and its a version mismatch between Cirrus and MW core [21:17:34] samwilson and we need to allow for another extensions/skins directory. [21:17:58] davidwbarratt: the current workaround for that is the 2nd parameter to loadextension() [21:18:02] why another? just use the top one [21:18:22] note that shared hosting without shell access can't install using composer ;) [21:18:33] samwilson which is? [21:18:53] Vulpix: if they don't have shell they cant use git submodules either then really. Most likely they would have to build locally (git, composer, whatever) and push. Should be about the same [21:18:58] davidwbarratt: the full path to the extension [21:19:02] TimStarling: regardless of whether it bundled in a literal tarball, I think it's better for users if we provide popular base extensions along with main MediaWiki. Especially with things like SpamBlacklist, that just work out of the box once enabled [21:19:11] i use it for some composer-loaded extensions [21:19:28] samwilson interesting, that's good to know, I guess the tar doesn't enable extensions out of the box anyways [21:19:36] have a top level installer which uses git to pull core and a standard set of extensions [21:19:51] do want to reopen the composer discussion? in the last rfc there was consensus that composer is not a good way to manage extensions, the reasons given there seem still valid [21:19:56] #info have a top level installer which uses git to pull core and a standard set of extensions [21:19:56] <_joe_> Vulpix: they can, and I argue everyone should just use composer to create what they deploy, not run it in "production" [21:20:06] tgr "manage" is different from "download" [21:20:30] or do we think that composer is better than nothing until a decent installer/extension manager comes into existence? [21:20:35] tgr: davidwbarratt has some same things to say about the composer installation topic :) [21:20:46] *sane things [21:20:54] git seems better than composer to me, you can do local patches [21:21:01] <_joe_> ^^ [21:21:05] composer can install via git [21:21:08] TimStarling using --prefer-source you get a git clone. :) [21:21:17] _joe_: that would make sense, yes, except that people may not have a PHP development environment on their PC (Windows users usually) [21:21:24] I think composer is tangential to this whole discussion, tgr said on phabricator "IMO some of the proposed changes are useful, for reasons completely unrelated to Composer." which I agree with [21:21:25] TimStarling and composer patches plugin will apply patches for you [21:21:31] tgr: the situation is a different if the context that pulls in the extensions is a "project", not core itself. core does not depend on the extensions. but your website does. [21:21:47] legoktm++ [21:21:50] legoktm: which changes? [21:22:02] #info I think composer is tangential to this whole discussion, tgr said on phabricator "IMO some of the proposed changes are useful, for reasons completely unrelated to Composer." which I agree with [21:22:15] (Appreciating panelist and Wikimedia technologist Magnus Manske's vision in Wikimania 2030 here - https://www.youtube.com/watch?v=Gdr2F8aB9y0 - from Aug 11 2017 suggesting bringing together MediaWiki projects for a variety of reasons looking into the future, or which today's Wikidata office hour topic seems relevant) [21:22:18] <_joe_> Vulpix: ok, those users need an install/upgrade wizard, that's way beyond the topic of today's discussion IMHO [21:22:50] DanielK_WMDE__ that's the downside of making a wrapper, it doesn't really benefit anyone other than Composer people. :( but I can update the ticket with all the pros / cons [21:23:04] TimStarling: as a wiki admin I like the changes which make it easy to swap out core [21:23:12] TimStarling: separating stuff like LocalSettings.php and images/ which have local wiki content and the rest of the directory structure that should not be touched [21:23:54] davidwbarratt: btw, if we can't move entry points, we can move config files. LocalSettings.php doesn't need to liove in the root directory. IMHO it shouldn't. the only reason to haave it there is that it's easy to find. But a config/ folder would work just fine [21:24:05] ie. I have directories like /usr/lib/mediawiki/1.29 and /usr/lib/mediawiki/1.30 and then the upgrade mostly just consists of changing a symlink [21:24:17] so you can just replace the entire directory when upgrading instead of the current process of unpacking over the directory structure, which leaves deleted files behind [21:24:17] <_joe_> DanielK_WMDE__: +1 [21:24:21] and if it goes badly rolling back is easy [21:24:29] ok, so you would move them to ../images and ../config/LocalSettings.php? [21:24:33] #info if we can't move entry points, we can move config files [21:24:41] TimStarling: that sounds good to me [21:24:47] you can do that with the current structure but have to set up lots of separate symlinks [21:24:58] TimStarling: yes, exactly that [21:25:16] <_joe_> tgr: yeah, less symlinks would be good [21:25:25] i would like to go back to what tgr asked in the beginning: [21:25:37] what is this proposal trying to fix? [21:25:46] what problem does it solve, and for whom? [21:25:47] #info ok, so you would move them to ../images and ../config/LocalSettings.php? [21:26:01] yeah setting up symlinks or a bunch of config just to get things working is no bueno [21:26:04] note that when we introduced the web installer under /config, people complained that it conflicted with some hosting dashboard, so we moved it to /mw-config [21:26:23] haha, wow [21:26:26] of course we can tell anyone who is still using that to get a life [21:26:43] or to not put mediawiki in the docroot :) [21:27:08] DanielK_WMDE__ ++ but probably way way out of scope. :) [21:27:08] well, ordinary people don't have that option [21:27:12] TimStarling: even ../LocalSettings.php would work I think [21:27:38] <_joe_> TimStarling: you mean people using hosting services? [21:27:43] davidwbarratt: the other thing I would like to see in the phab discussion is a discussion of BC. What will wiki owners need to do if the next release comes with the new directory structure? what happens if I am not aware of the changes and just do a git pull and try to test my updated wiki? [21:27:50] I made a wiki outside the docroot a few months ago, it was a bit complicated [21:28:19] i was thinking of a subdirectory, not totally elsewhere [21:28:19] tgr if none of the entry points change... nothing should happen I assume? [21:28:28] tgr but I'll make a note of that [21:28:52] entry points do change over time [21:29:03] e.g. thumb.php is probably going to be rewritten soon [21:29:37] is there any thought of moving all web entry points to one file? [21:29:42] tgr true, I mean the logic inside the entries points should be moved out of them and into /core so the entry point is extremly thin. [21:29:48] legoktm: "so you can just replace the entire directory when upgrading instead of the current process of unpacking over the directory structure" --> this is already discouraged in the upgrading manual [21:29:49] samwilson ++ [21:29:49] tgr: we can just have a stub in the top directory. but outside of scope I would think. [21:30:02] it's not just the entry points, you also have to alias /resources into the web root since images are not delivered via RL [21:30:06] <_joe_> DanielK_WMDE__: well there is value in having the code completely outside the docroot [21:30:19] same with /extensions, you have to alias it in to deliver images [21:30:27] DanielK_WMDE__: except then you lose the ability to have your MediaWiki installation elsewhere [21:30:36] _joe_: true. there's also value in having the entire web app in one directory. [21:30:39] Vulpix: right, because if you did it today bad things would happen. But if this proposal was implemented as I imagine, it should be possible to replace the entire directory properly [21:30:59] TimStarling well that's wqhat I'm saying, we need to remove the assumption that it's in /extensions and instead assume /core/extensions and /extensions (i.e. we have to first determine _where_ the extension is relative to the entry point [21:31:03] tgr: could use en environment variable. but i see your point [21:31:37] davidwbarratt: I previously said I don't believe in having two extensions directories [21:31:54] DanielK_WMDE__: can be solved, sure. I am just saying, I would like to see this more clearly laid out in the RfC [21:31:55] TimStarling then we shouldn't package extensions with the tar [21:32:02] that's what I said, yes [21:32:12] there's already a tarball that's provided with no extensions in it [21:32:13] TimStarling kk, well I agree with that then. :) and it's easier. [21:32:25] samwilson: "is there any thought of moving all web entry points to one file?" -- kind of -- https://phabricator.wikimedia.org/T104755 [21:32:32] legoktm I'm saying we shouldn't have any "core" extensions [21:32:33] we could package extensions with the tar of mediawiki-app, separate from core [21:32:35] at all [21:32:35] note that tarball is the only way to install mediawiki on crappy shared webhosts [21:32:40] /core (for core) and /local (for local extensions, skins...) [21:32:55] separating the application scaffolding from the code of the software sounds like a good idea anyway [21:32:59] (which doesn't mean it has to be a single tarball, but it does make things more comfortable) [21:33:35] davidwbarratt: I think losing bundled extensions will be a setback in the usability of stock MediaWiki. [21:33:35] tgr: what do you think of an app tar, instead of a core+x tar? [21:33:46] I mean we could jsut assume no "core" extensions, if there are some in the tar, then that's just for convience [21:33:49] none of them are "core" [21:33:49] it would include core + default skins/extensions [21:34:13] yeah what are "default" skins and and extensions [21:34:17] isn't that what we are doing now? [21:34:18] are they part of "core" or not? [21:34:24] yes it is [21:34:34] the official name is bundled extensions, I think [21:34:48] don't package extensions with tar, don't package core with tar either [21:34:53] <_joe_> well once you distribute them toghether, they're part of the same software package, and you expect them to be upgraded toghether [21:35:15] if we really need to support shared hosting, have an installer that takes the FTP username and password, it can download everything with git and upload it via FTP [21:35:38] _joe_ which then they should be in a /core directory and shouldn't be modified by the user (i.e. upgraded independently) [21:35:40] TimStarling: e.g. that's what wordpress does [21:35:53] samwilson: where do you think I got the idea? ;) [21:35:58] :) [21:36:04] but omg we need to support uploading via web interface! :P [21:36:12] hahaha [21:36:17] <_joe_> yeah if we target the shared hostings, what WordPress does is really nice :) [21:36:37] MaxSem: yup, but it's also avoided on all those shared hosts that allow the web server to write app files directly [21:36:48] I'd just be happy if we wrote the LocalSettings.php for the user, but I digress. [21:36:49] an installer would be nicer, also more work [21:37:07] tarballs seem like a reasonable compromise [21:37:25] having the web app overwrite itself sounds scary and very insecure [21:37:30] although a user survey would be really nice on issues like this [21:37:41] for the pure tarball use-case (if it really exists) something could be built in Cloud Services that gives a web interface to pick things to put in the tarball and then generates it on the fly [21:37:46] maybe 90% of our userbase doesn't even recognize the word 'tar' [21:37:47] Vulpix: yup, that sounds like wordpress [21:37:54] it's a very linux thing afterall [21:37:57] regardless of redoing the entire installer, I think there's still a win in letting ../LocalSettings.php work, and maybe changing the default to ../images/ [21:38:24] I have all my mediawiki files owned by root, nobody can change them [21:38:31] #info if we really need to support shared hosting, have an installer that takes the FTP username and password, it can download everything with git and upload it via FTP [21:38:52] bd808: dokuwiki does that, let's you pick any extensions any bundles them all up [21:39:18] bd808: it would be not-difficult to extend ExtensionDistributor to support that [21:39:20] the compromised wordpress installation is a cliche at this point, the security of wordpress is catastrophic [21:39:26] <_joe_> Vulpix: I think composer is an utterly insecure package manager, if we want to talk about security... having the web application be able to dowload, check that the tarball is properly signed, and decompress itself is /not/ a security risk in an environment that allows the web user to write to the docroot anyways [21:39:46] #info < bd808> for the pure tarball use-case (if it really exists) something could be built in Cloud Services that gives a web interface to pick things to put in the tarball and then generates it on the fly [21:39:47] <_joe_> TimStarling: the security issues with WordPress are not linked to the installer though [21:40:22] web-writable source trees are a big security vulnerability [21:40:28] and that is linked to the installer [21:40:33] just to clarify, bundled extensions ought not be upgraded independently of MediaWiki correct? [21:40:39] _joe_: I don't allow php to write to my document root, to begin with. But I guess that's a choice every sysadmin have to make [21:40:41] TimStarling: clearly did not prevent Wordpress from being very successful though [21:41:08] no rw webroot, no web installer [21:41:13] <_joe_> Vulpix: I am talking about shared hostings, that usually readily allow the web app to write to its docroot [21:41:25] yes, MW might not be so popular, but at least there are not armies of compromised MW hosts DDoSing the rest of the internet [21:41:27] yeah, i think from the end-admin-user's point of view it's great [21:41:32] <_joe_> because of course I expect no sysadmin to have a writable webroot [21:41:50] taking a step back, is there anyone against letting ../LocalSettings.php work out of the box (while continuing to support it in the same directory for b/c) [21:42:14] <_joe_> legoktm: wasn't it ../config ? [21:42:28] legoktm: checking both pathes on every request is a potential performance issue - at least for wmf [21:42:56] if we check ../ first, that's where wmf should have the file. [21:42:58] it's OK for WMF, we check lots of paths on every request [21:42:58] DanielK_WMDE__ yeah file_exists doesn't cache non-existtant files if I remember correctly [21:43:15] DanielK_WMDE__: I don't think adding one extra stat() is going to be that bad with HHVM's statcache and ideally Wikimedia's would be in the first lookup [21:43:27] and shouldn't. but we can emulate that by caching in local ram [21:43:40] <_joe_> yeah, we can just make it so we fall in the first lookup [21:43:59] <_joe_> legoktm: I wouldn't tie us to a particular feature of HHVM though :) [21:44:04] we don't need to roll our own stat cache just for this one thing [21:44:17] legoktm: adding a configuration parameter for location of MW core which defaults to __DIR__ but is set to __DIR__.'/core' in new installations would be a nice way forward [21:44:35] you could also let the user modify the entry point [21:44:42] _joe_: zend hsa a stat cache too [21:44:43] tgr: but you have to find and load your config first ;) [21:44:45] or have a common file that points to the config file [21:44:48] that is user editable [21:44:53] tgr: where would you configure it, in LocalSettings.php? :P [21:44:56] _joe_: specific directory name of ../config vs not can be bikeshedded after? just trying to see if anyone is against allowing that file to be out of the main core directory [21:45:13] <_joe_> legoktm: ok! [21:45:16] Vulpix in the entry point itself, or a common file that all entry points use [21:45:34] davidwbarratt: the common file is...LocalSettings.php? [21:45:34] tgr: could be an environment variable, though [21:45:42] probably an env var, yes [21:45:44] or an ini setting even [21:45:51] there's already MW_CONFIG IIRC [21:46:09] that's a PHP define [21:46:26] legoktm ha, yeah I mean whatever. or just `config.php` that then does a require_once to LocalSettings.php [21:46:27] just pull the value from getenv [21:46:34] twelve-factor app and all that [21:46:38] T115432 [21:46:38] T115432: Get MW_CONFIG_FILE from env to facilitate virtual hosting - https://phabricator.wikimedia.org/T115432 [21:46:40] legoktm and you can change it to `../LocalSettings.php` (or whatever you want [21:46:40] so that? [21:47:02] legoktm I like env [21:47:03] 15 minute warning [21:47:11] we have drifted pretty far from the original rfc [21:47:27] are we still talking about moving things into a core/ folder? [21:47:36] or are we discussing moving other things elsewhere?... [21:47:39] DanielK_WMDE__: I think moving LocalSettings.php and related out of core directory is still in scope. It's just viewing it in the opposite direction :) [21:47:55] it's in scope, sure! [21:48:18] i'm asking whether the rfc should be changed to propose that approach, as opposed to the current one [21:48:23] we have MW_INSTALL_PATH [21:48:41] an environment variable that is checked on startup [21:48:56] ahh, that one [21:49:52] as far as the RFC goes, I've made a lot of notes, I'll update the description and hopefully answer some of these questions (or at least provide the options we have) [21:49:55] but that may be used to construct pathes that shoudl actually point to core code, not editable files [21:50:50] maybe we can continue to discuss LocalSettings.php fallback sequences in gerrit [21:50:53] davidwbarratt: do you want to stick with the rfc as proposed (move things to core/), or do you plan to change it to propose something different (move stuff into settings/ or create an mw-app repo that acts as a wrapper)? [21:51:27] I'm not quite ready to say "merge whatever you want" [21:51:48] DanielK_WMDE__ I can list the pro cons of both approaches, but I think the former might be better. [21:52:23] DanielK_WMDE__ I guess there is also a third option [21:52:51] which is that we move things into /core and make that a completely seperate repo (and the entry points would be in the wrapper) [21:53:21] well... if we think the entry points are user-editable [21:53:36] In terms of practicality I don't think moving most of core into a separate repo is worth it [21:53:36] if they are not then they could go in "core" but really then "core" is just the webroot [21:53:47] davidwbarratt: to me that sounds like leaving stuff in core, and creating a wrapper from scratch [21:53:48] I think we will pick the bits we like out of this RFC and the surrounding discussion [21:53:51] legoktm nor do I, a subtree split seems easier. [21:53:58] but we're not going to implement it as proposed [21:54:12] TimStarling with the hammer [21:54:34] #info I think we will pick the bits we like out of this RFC and the surrounding discussion but we're not going to implement it as proposed [21:55:04] legoktm: do you agree with that? [21:55:18] TimStarling I just think it was rude is all. :) [21:55:24] yes [21:55:47] +1 [21:55:53] TimStarling: "we" is who? [21:56:18] collective we [21:56:40] i see :) [21:57:32] but legoktm is keen to implement some bits [21:57:39] davidwbarratt: was the discussion helpful for you? do you have anything we should discuss in the remaining minutes? [21:58:14] I am :) [21:58:24] davidwbarratt: You're familiar with XY problems? [21:58:27] so was that a "no" or a "refine the rfc"? [21:59:01] wrt having a core directory [21:59:28] DanielK_WMDE__ yeah, like I said I'll go back and update this ticket to hopefully give all of the reasons and potential solutions [21:59:58] then we can rediscuse if we want to. [22:00:00] tgr: refine and potentially take some ides out of the discussion and discuss/implement separately? [22:00:09] works for me [22:00:45] ok then, thank you all! [22:00:48] #endmeeting [22:00:48] Meeting ended Wed Sep 6 22:00:48 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:48] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-09-06-21.01.html [22:00:48] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-09-06-21.01.txt [22:00:48] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-09-06-21.01.wiki [22:00:48] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-09-06-21.01.log.html [22:01:20] [17:10] the RfC (on Phab) is pretty clear about what should be done but very vague about why it should be done <-- Seems very XY-y to me. I don't think it's very surprising people are wary of a solution without better understanding the problems. [22:01:35] Esther and no I am not [22:01:37] The actual problems presented seem to have clearer and more reasonable solutions. [22:02:12] ah [22:02:18] yes, I wrote that in my notes [22:02:25] http://mywiki.wooledge.org/XyProblem && https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem [22:03:24] Like Lego pointed out the annoyance of having LocalSettings.php in the root directory, and that has a more straightforward remedy, probably. [22:03:27] Just my two cents. [22:03:48] Esther: I think there are valid reasons to do it. Whether they are good enough will be easier to see when they & the costs are fleshed out more. [22:04:26] Agreed. I think people are unconvinced of the cost–benefit. [22:04:33] That was my read of the chat, anyway. [22:10:20] ah