[20:00:10] * DanielK_WMDE__ wibbles [21:01:19] #startmeeting RFC meeting [21:01:19] Meeting started Wed Oct 8 21:01:19 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:19] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:19] The meeting name has been set to 'rfc_meeting' [21:01:45] #topic RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:02:13] hello everybody! [21:02:20] hi! [21:02:31] is it ok with everyone to start with the LESS RFC, as Tyler requested on wikitech-l? [21:03:14] #topic Change LESS compilation library | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:03:22] #link https://www.mediawiki.org/wiki/Requests_for_comment/Change_LESS_compilation_library [21:04:06] * brion looks [21:04:22] is it office hours? :P [21:04:36] it's MediaWiki RFC meeting [21:04:47] ooh source maps and better feature parity [21:04:52] TrevorParscal: did you want to say something about this RFC? [21:05:03] functions will have to be converted, but that should be doable [21:05:11] or Dantman? [21:05:11] hi [21:05:20] brion: all the functions in core were removed recently [21:05:27] oh hey nice [21:05:59] and $wgResourceLoaderLESSFunctions is deprecated [21:06:02] Dantman: would you be implementing this? [21:06:39] I'm in support of updating this [21:06:49] I read the RFC about a week ago [21:07:01] doesn't seem like there's been any movement on the issues yet [21:07:12] TimStarling: Oh. :P [21:07:19] I've been working on things other than MW lately, so probably not. But the idea did come to me so I documented it in the RFC. [21:07:35] Though I think the biggest hurdle will probably be the license. [21:07:45] the performance comparison should at least be studied, but it's unlikely to be a problem unless it's crazy bad [21:07:45] hmmmm [21:07:53] Yeah [21:08:10] If Dantman does not do it, I might [21:08:20] what precedence is there in MediaWiki for apache in gpl? [21:08:29] Less_Parser has not seen updates for months from oyejorge, [21:08:37] My bet is that the actual performance issues are mostly bonus features that leafo/lessphp don't implement such as &:extend() being slow. [21:08:37] So I forked it with two other guys [21:08:47] I recall migrating some lib licenses from Apache to MIT when we realized or suspected there was an issue [21:09:18] Dantman: Yeah, extend seems to be the major issue [21:09:25] I wish I knew how to do this stuff; if I did I'd be willing to help out [21:09:31] CSSJanus, CSSMin claim to be Apache v2 as well [21:09:37] and we’ve got them in includes/libs [21:09:41] Note that we do have a copy of less.js which is Apache 2.0 sitting somewhere in the test directory. [21:09:43] Is patent protection the licensing issue? [21:09:49] well, with CSSJanus, it's a port of an already Apache licensed lib [21:10:14] CSSMin was originally authored by WMF staffers (could be changed with a series of +1's in gerrit) [21:10:20] we did this with VE early on [21:10:24] moved to MIT [21:10:28] we've always mixed licenses in core and extensions, but I'm not sure if we have a really good legal theory for that [21:10:30] #link https://www.apache.org/licenses/GPL-compatibility.html [21:10:47] I guess we can make a special note in the COPYING file [21:10:58] * DanielK_WMDE__ forgot how the bot works [21:11:07] yes, that is about what I recall, to make it compatible, we have to move MediaWiki to GPL v3 [21:11:17] which didn't seem feasible or easy at the time [21:11:21] basically the licensee needs to agree to follow the terms of all of the constitutent licenses [21:11:21] mehh [21:11:48] you can't just say "here is the GPL, follow it and you will not be violating anyone's copyright" [21:11:54] if we just pretend that mediawiki is “GPLv2 or later” at build time and GPLv3 at runtime, everything works ;) [21:12:01] lol [21:12:22] * brion is not a fan of gpl’s linking provision as it’s really fucking vague for dynamic languages [21:12:23] is the author of Less.php available [21:12:47] https://github.com/oyejorge/less.php/issues/168#issuecomment-55478059 it looks like it got forked? [21:12:50] often times people choose open source licenses for vague reasons, and are happy to dual license upon request [21:12:52] There's also composer to think about, now that it's better supported we don't actually have to put Less.php inside the GPLed core repo. [21:13:00] > lessc's original creator no longer has time for the project and most of the activity now appears to be maintenance.[1] [21:13:06] first wikipedia monument to be installed in poland ... http://armenpress.am/eng/news/779338/author-of-wikipedia%E2%80%99s-first-monument-is-armenian.html [21:13:09] could Less.php be dual-licensed under gpl2? [21:13:14] that would solve the problem [21:13:16] well, apache is generally less restrictive than GPL [21:13:26] TrevorParscal: https://github.com/oyejorge/less.php/issues/148 [21:13:35] * yurikR1 just realized its an RFC meeting, sorry [21:13:38] it could be dual licensed as Apache MIT (right) [21:13:39] so you would think that the author would be OK with dual licensing [21:13:40] ? [21:13:56] we don't know [21:14:14] Someone asked on the bug tracker and apparently got no response [21:14:18] Apart from someone trolling about Joomla [21:14:35] Looks like he is following less.js licensing [21:14:39] and if they change he will too [21:14:49] * aude waves [21:15:21] * brion waves back [21:15:44] looks like the issue at less.js is also at a standstill [21:15:46] can we distribute this with composer? [21:15:50] https://github.com/less/less.js/issues/1029 [21:15:52] so is licensing a blocker on this until resolved, or do we say ‘well it’s like stuff we already use so not a new problem'? [21:16:10] then we only have to have complex licensing for the tarball, which we presumably have already, not for the source repository [21:16:13] well, we do have a bit of waight to throw around. if we poke the right people... [21:16:13] yeah, the package name is "less.php/less.php" [21:16:23] https://github.com/Less-PHP/less.php/blob/master/composer.json [21:16:31] TimStarling: having them together in the same repo isn’t the problem iirc, it’s linking them into a single program at runtime (problem’s on the GPLv2 side) [21:16:40] you know we want to move to distributing all core libraries with composer [21:16:52] you know I don't believe in linking [21:16:55] :D [21:17:07] DanielK_WMDE__: I think you may be right, that we might have some pull [21:17:28] I think we should at least try and use it [21:17:34] should it exist [21:17:44] why didn’t we want to upgrade to GPLv3 anyway? /me doesn’t remember other than inertia [21:18:03] TrevorParscal: especially if we commit to contributing upstream. at least small stuff. [21:18:04] if we can get less.php dual with MIT (perhaps by also getting less.js to as well) then it will be an easy win [21:18:08] DWTFPL [21:18:12] yeah [21:18:33] brion: Wasn't it because some people thought there were a few extensions that were GPLv2 only? [21:18:33] well, "GPL v2 or later" is already effectively a GPLv3 dual-license [21:18:52] heh [21:19:14] how uniform is that in MW? [21:19:34] TimStarling: but does everything we use have the "or later" clause? it's optional, right? [21:19:41] That "or later" clause has always bothered me as the spouse of an attorney [21:19:44] if an extension is GPLv2 only, then distribute the extension under GPLv2 [21:19:59] afaik everything in MW proper was ‘gplv2 or later’ by default, but it’s possible something doesn’t/didn’t [21:20:17] bd808: true there’s always the ‘fsf becomes evil(er)’ scenario [21:20:25] anyway back to earth….. what’s our next steps here? [21:20:25] sounds like it may be easier to find and resolve the outliers of that then [21:21:03] If somebody could clarify, what is the license clash here? Can you not distribute Apache software inside of something GPL-licensed? [21:21:13] step 1: to resolve the licensing by either getting the less.php to become compatible, or rounding up and resolving all non "or later" uses of GPLv2 in our own software [21:21:24] parent5446: https://www.apache.org/licenses/GPL-compatibility.html (from DanielK_WMDE__) [21:21:34] Thanks [21:21:40] you can't just say "this software can be copied under the terms of GPLv2" if you have to also follow apache license for some components [21:21:41] parent5446: TL;DR Apache and GPLv2 are not considered compatible by FSF [21:22:14] parent5446: in short: gpl3 yes, gpl2 no, because of nitty gritty patent related stuff [21:22:16] step 2: have a mergable patch for less.php to restore custom functions (maybe offer it upstream) [21:22:16] you have to aggregate the rights of the authors and require users to comply with all of them [21:22:21] Ah kk just got the gist of it [21:23:01] So basically our only option is to move MediaWiki to GPLv3 in order to be compatible [21:23:17] I am not agreeing to that right now [21:23:23] (Which should be trivial considering, as mentioned, all contributions are GPLv2 or later) [21:23:35] looks like https://github.com/oyejorge/less.php/pull/115 merged in the custom function stuff already [21:23:36] TimStarling: Yeah didn't say we were settling, just saying that was what the option looked like [21:23:46] yes [21:23:53] but there are another two options [21:24:07] * bd808 votes for composer [21:24:21] so, step 2 is really just writing a patch that ports our use of the old custom function API to the new custom function API [21:24:27] one is to change the COPYING file etc. to say that MW can be distributed under GPL except for the LESS compiler which can be distributed under the apache license [21:24:32] TrevorParscal: Well, do we need to support custom functions? they were removed from core, and deprecated in 1.24, so we can remove them in 1.25... [21:24:41] the other is to not use the other LESS compiler or to force them to change their license [21:25:05] "convince" [21:25:17] the first of those two is possible because I don't believe in "linking" of PHP [21:25:20] "that's a nice library you have there, shame if something happened to it..." [21:25:48] legoktm: I'm speaking of extensions that /might/ use custom functions - if we want to wait for 1.25 to update, then we don't need to bother I guess [21:25:55] GPLv2 doesn't even mention linking [21:25:58] TrevorParscal: we're already on 1.25 :) [21:26:22] linking is only in the mythology surrounding GPLv2, not actually in the license [21:26:43] sorry, i was confused by your future tense of saying "so we can remove them in 1.25" [21:27:07] true, that’s actually ‘fsf interpretation of gplv2’ [21:27:16] * brion licensing is hard, let’s go shopping ;( [21:28:03] #info step 1: to resolve the licensing by either getting the less.php to become compatible, or rounding up and resolving all non "or later" uses of GPLv2 in our own software [21:28:14] #info step 2: have a mergable patch for less.php to restore custom functions (maybe offer it upstream) [21:28:30] #info bd808 votes for composer [21:28:38] next RFC? [21:28:51] Composer ftw [21:29:24] #topic Extension registration | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:29:28] Yeah, even without the license stuff I thought less should use composer from the start [21:29:33] #link https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration [21:30:25] woot [21:30:59] one thing that bothers me about JSON is that it doesn't support comments [21:31:17] I hate that about json [21:31:21] yaml? [21:31:23] * bd808 ducks [21:31:34] We could take the Symfony approach and support multiple formats [21:31:41] e.g., JSON, YAML, and XML [21:31:42] yuck [21:31:47] yuck yuck yuck [21:31:50] parent5446: well, I'd like to standardize on just one thing.... [21:32:13] solution: add comments to the JSON spec upstream [21:32:15] XML is ick, and JSON is installed by default, afaik YAML isn't [21:32:31] wait 10 years, win [21:32:34] Well it's not hard to standardize on multiple formats. In fact Symfony even has a Configuration component [21:32:39] Aaron made a comment pre-filter for his jobrunner config file [21:32:59] that is an interesting approach [21:33:03] So the file is json but with full line # comments [21:33:28] hm, that sounds reasonable [21:33:29] hmm, I would think JavaScript would be a more natural example to follow [21:33:35] :/ [21:33:56] well you can always use extra object entries and strings as comments, but it can be flaky [21:34:05] eek [21:34:12] // comments [21:34:12] parent5446: You brought up xml. This isn't worse that than. ;) [21:34:40] Yeah please let's use // instead of # if we're gonna put comments in JSON and regex them out [21:34:42] on the talk page, a concern has been raised that this approach might confict with the Composer approach. [21:34:47] if you only allow full-line comments, you don't have to parse strings [21:34:47] Because then at least syntax highlighting in editors will work [21:34:54] Honestly I don't really like XML, I was just hoping to use Symfony's Configuration component. :P [21:34:55] OMG /me hides from this thread [21:34:59] for writing and reading, yaml is best, and it's a suprset of json. but it's an extra dependency :/ [21:35:11] There is some precedence for JSON+comments [21:35:12] * bd808 notes that Aaron did do // comments [21:35:19] mglaser: we'll just need to update the custom installer for composer [21:35:22] the problem with yaml is that nobody can write a parser for it [21:35:35] heh [21:35:39] :P [21:35:40] https://github.com/kof/node-cjson [21:35:42] I've looked at two parsers and they were both pretty bad [21:35:42] i would avoid yaml, it’s very …. “there’s more than one way to do it” [21:35:53] which makes it hard to be consistent [21:35:55] legoktm : ok, good [21:36:02] let's use INI synatx ;) [21:36:13] * bd808 discloses his bias -- http://pecl.php.net/package/yaml [21:36:33] we are already use JSON for i18n [21:36:54] and composer, maybe other things? [21:36:55] Here's what Aaron did -- https://github.com/wikimedia/mediawiki-services-jobrunner/blob/master/redisJobRunnerService#L112-L114 [21:37:15] to be a bit blunt, are people's biggest issues with the RfC the choice of format and lack of comments? :P [21:37:31] bd808: right, so he did use // for comments [21:37:33] Also, I still maintain my position that this should not conflict with composer and that we should let composer handle autoloading rather than duplicating it here. [21:37:56] bd808: eek, that will fail horribly on // in strings! or am i missing somethings? [21:38:03] You're not [21:38:11] It's not general purpose [21:38:16] legoktm: yeah, ok, let's move along [21:38:20] parent5446: I think autoloading is a pretty small of this, and since we don't have a proper composer infrastructure for extensions in place, this should handle autoloading, and then move it over to composer after that RfC [21:38:23] bd808: like, for URLs :) [21:38:54] legoktm: OK, I think I can perceive a reasonable workflow for that [21:39:00] Sounds good to me then [21:39:33] I suggest we go for json. it sounds the most robust. we can start allowing yaml later, if/when that becomes feasible. [21:39:39] legoktm: How does this tie in with your ApiFactory stuff? Cause you recently changed VisualEditor.php to contain mode non-data code than it did before with that change [21:39:50] "Reading and parsing a JSON file will be slower than loading a PHP file due to APC and other factors. However, we can mitigate that by providing a script to "compile" all the required JSON files into their PHP equivalents." [21:39:51] adding support for comments seems a good idea, but we have to make sure to get it right [21:40:19] what about caching with apc_fetch() etc.? [21:40:41] legoktm: Another thing: ResourceLoader module registration should support something similar to what $wgExtensionNameResourceTemplate is used for right now (shared localBasePath and remoteExtPath between many modules) [21:40:42] TimStarling : do we take apc for granted? [21:40:50] TimStarling: and manually check against the file modification date? should work... [21:40:53] just skip caching if it is not available [21:41:03] yeah, check file modification date [21:41:15] APC is unconditionally available in HHVM and is really fast there [21:41:26] that is to say, apc_fetch() etc. is available [21:41:28] RoanKattouw: I'm not super sure on the specific implementations, but VE might have a custom registerer to do that, or something. [21:41:35] Right [21:41:57] I see a few places where we have fallbacks or computed values where we'd have to use a setup hok [21:42:07] maybe we could even cache the merged array? [21:42:10] Which is fine, but maybe there could be an example of what a setup hook would look like? [21:42:18] that was my dream from years ago for this [21:42:34] TimStarling: which merged array? [21:42:40] I'm not trying to be laser-focused on VE here, I'm just using its setup file as an example of a moderately complex setup file [21:42:45] TimStarling: sounds like something that would be useful not only for registration, but also for json based per-extension config [21:42:53] instead of one cache key per extension, put everything into one cache key [21:42:55] which we are about to start supporting, i think [21:42:58] (For computed values, I mean config defaults like $wgVisualEditorNamespaces = array_merge( $wgContentNamespaces, array( NS_USER ) ); ) [21:43:02] FYI, Symfony's Config component also already has the ability to cache [21:43:05] TimStarling: ah, yes. [21:43:07] e.g. have the whole of $wgAutoloadClasses [21:43:18] TimStarling: makes checking mtime more complicated, but would be doable [21:43:22] RoanKattouw: "For extensions that absolutely need to handle setup in PHP, a callback may be registered (using a "callback" key), that will be run after the rest of the info.json file has been processed. This would be different than extension functions, which are run after nearly all MediaWiki setup has occurred." [21:43:25] then there is less processing to do on startup, so it is faster [21:43:32] legoktm: Oh, I see [21:43:43] I saw that bit but didn't notice the detail was all in there after all [21:43:57] when I say APC is fast on HHVM, I mean O(1), from what I understand, it just takes a COW reference to shared memory [21:44:13] so you could load an array with 10,000 elements in a microsecond or two [21:44:19] neat [21:44:25] legoktm, RoanKattouw A fallback to PHP is good in some cases. I'm happy to see this will be taken care of [21:44:51] so it would be nice if we could take advantage of that by not doing any O(N) thing on large loaded arrays like $wgHooks [21:46:47] ah, but if you have merged arrays, that makes this syntax difficult: [21:46:51] wfLoadExtension( 'Math' ); [21:46:51] $wgMathSomeOption = 'bar'; [21:46:51] wfLoadExtension( 'SpamBlacklist', '/some/weird/location' ); [21:46:55] that is proposed in the RFC [21:47:54] that syntax is an interim measure while we still have global variables, once they're in the database (or wherever) we would load them all at once [21:48:17] could you also provide a batch load function, say wfLoadExtensions? [21:48:37] it's not clear to me how you would specify something to be *added* to a list instead of replacing that list [21:48:54] yeah, batch loading should be doable [21:48:56] I think it's important that the LocalSettings.php API be relatively stable [21:49:00] unless the code that merges the arrays has knowledge about the semantics of the individual settings [21:49:11] so we should provide a batch load API even if it is not efficient to start with [21:50:22] #info some discussion about comments in JSON, or other configuration formats that support comments [21:50:33] #info could you also provide a batch load function, say wfLoadExtensions? [21:50:52] DanielK_WMDE__: in $wgConf/SiteConfiguration, that's indicated by naming the setting '+wgOption' as opposed to 'wgOption' [21:51:03] I haven't really worked out a good way to do that in the new Config stuff [21:51:20] legoktm: that ould work i guess, though "wgOption[]" would be the more php-like choice [21:51:32] but there are no plus signs in the extension registration file, right? [21:51:43] presumably that would just know that you don't replace the whole of $wgHooks [21:52:04] TimStarling: i'd like to avoid that kind of knowledge in the merging code. [21:52:12] it will be a mess of 100 special cases :/ [21:52:30] i gotta run take care of some lease stuff, enjoy rest of meeting :D [21:52:50] it will be like i18n files presumably [21:53:02] which do have a lot of special cases to make authoring easier and less error-prone [21:53:09] but with more complex data structures [21:53:23] including about 6 different ways to merge arrays [21:53:37] DanielK_WMDE__: nearly everything on https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration/Schema is append, the only weird things are namespaces and permissions [21:54:52] legoktm: so, what if you want to add two hooks? it's merge, not append, if it's an array? but the hookd itself could be an array... [21:54:52] Yaml can merge arrays :) [21:55:23] bd808: knowing when to merge what with what is the problem though [21:55:31] DanielK_WMDE__: Why would the hook itself be an array? [21:55:39] We'd probably just have to special case hooks. [21:56:01] I am fine with having merging code in the core, I think that is better than having that complexity duplicated in every extension [21:56:01] DanielK_WMDE__: True. That logic is coded in the yaml file being parsed [21:56:05] legoktm: because that's how you specify a call to a static method: array( 'Foo', 'bar' ). [21:56:11] if it is complicated, that is an argument for factoring it out [21:56:15] DanielK_WMDE__: "Foo::bar" [21:57:15] legoktm: if that's all we need to support... yea, probably fine for the non-crazy cases :) [21:57:37] btw the i18n files do literally have 5 ways to merge arrays [21:57:44] hehehe [21:57:45] plus overwrite makes 6 [21:58:30] it will be similar for extension registration, I think [21:58:52] but like I say, I think that is alright, I think core is the right place for complex things, done once and done right [21:59:04] otherwise all extension authors will hate us [21:59:39] and note that both i18n and this new thing are extension registration systems [21:59:56] so i18n is a precedent that extension authors will be familiar with [22:00:21] I've got another meeting starting, so does bd808 [22:00:35] I haven't worked out how exactly it might work, but I think we might be able to include a shim file to support older MW versions like we did for JSON i18n [22:01:06] anyway, this is all about details, broadly, I love the idea [22:01:15] \o/ [22:01:29] indeed! [22:01:30] #info TimStarling says do it [22:01:32] :D [22:01:37] So what's the conclusion? It seems this is supported. [22:01:45] next step is a showcase? [22:02:12] next step is to clone legoktm so that someone has time to work on it :) [22:02:18] demos are always good [22:02:27] I thin 4 legoktm's should be enough for now [22:02:40] :) [22:02:41] yeah, I'll start working on a prototype/demo thing, and also trying to get resourcing for it [22:03:04] I'll try and get some feedback on the format by other extension devs [22:03:05] legoktm: you just have to decide whether it is libraryisation or editor performance [22:03:10] maybe editor performance [22:03:33] faster startup time = faster API requests = faster parsoid = better editor performance [22:03:44] heh :D [22:03:47] there you go, management sorted [22:04:18] and cleaner integration of extensions is good for the library work so double win [22:05:39] #action mglaser to try and get some feedback on the format by other extension devs [22:06:03] #action legoktm to start working on a prototype/demo thing, and also try to get resourcing for it [22:06:14] ok, thanks everyone [22:07:08] thanks! [22:07:21] next week we have pencilled in the following three RFCs which may be reduced to two before announcement: [22:07:30] https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables [22:07:39] https://www.mediawiki.org/wiki/Requests_for_comment/Removing_bad_database_abstractions [22:07:52] https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates [22:08:12] the meeting will be at the same time [22:09:03] #endmeeting [22:09:03] Meeting ended Wed Oct 8 22:09:03 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:09:03] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-08-21.01.html [22:09:03] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-08-21.01.txt [22:09:03] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-08-21.01.wiki [22:09:04] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-08-21.01.log.html