[21:01:47] * legoktm waves [21:02:31] #startmeeting RFC meeting [21:02:31] Meeting started Wed May 13 21:02:30 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:02:31] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:02:31] The meeting name has been set to 'rfc_meeting' [21:02:54] #topic Improving extension management | RFC meeting | Wikimedia meetings channel | 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:10] hello! [21:03:14] https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management [21:03:32] minutes from last time are at https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-02-18-21.00.html [21:03:50] woah I talked a lot last time [21:04:29] o/ [21:04:51] I made a few changes to the RfC since then: 1) dropping support for the web interface for initial implementation 2) change how core support is stated [21:05:10] heya jzerebecki! [21:06:03] I mainly want to talk about and discuss the new way to specify which versions of core are supported and the branching strategy: https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management#Dependencies_upon_MediaWiki_core and the proposed tardist service to update ExtensionDistributor for these changes: https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist [21:07:36] legoktm: should we also discuss depdendencies between extensions? [21:07:51] i'd like to chime in to note that this strategy might not (yet?) support using the composer autoloader setting in extensions [21:07:55] seems like that ties into the core version dependency thing [21:08:06] DanielK_WMDE_: and why they are a terrible idea? ;) [21:08:07] o/ [21:08:20] previously you had "supports": ["1.23", "1.24", "1.25"], [21:08:32] now "supports": ">=1.23,<1.26" [21:08:35] DanielK_WMDE_: we could, but I don't think people's positions have changed since last time and I'd like to get something actually done. Last time there was general support for specifying core support in extension.json, so I'd like to move forward with implementation on that [21:08:47] bd808: but not always avoidable. especially soft/options dependencies. [21:09:18] legoktm: sure [21:09:54] bd808: is what jzerebecki said correct? we can't use composer with libraries and extensions that use composer's autoloader mechanism? [21:10:16] TimStarling: yup. the new syntax would allow for supporting a minimum wmf branch and point releases if core patches are backported [21:10:32] DanielK_WMDE_: compser-merge-plugin doesn't support merging/managing autoloader [21:10:54] It wasn't the minimum viable product [21:11:04] but votes to implement that are piling up [21:11:18] and we'd use the composer code to parse the string and check that it matches [21:11:22] bd808: yay :) [21:11:27] I'm a bit concerned that this sounds like another home-grown packaging system [21:11:46] we talked about that composer-merge-plugin issue during the CI weekly meeting. The issue is at https://github.com/wikimedia/composer-merge-plugin/issues/18 been passed to greg-g [21:12:11] DanielK_WMDE_: it would work only if you install the extension via composer(-merge-plugin), not if you install it otherwise and then use composer-merge-tool on the extensions [21:12:45] gwicke, what's the alternative, though? [21:12:58] My understanding is that stock Composer just won't work for our use cases. [21:13:06] my not so detailed understanding of this proposal is that it does not instal the extensions via composer [21:13:11] there are other packaging systems outside the PHP world [21:13:14] legoktm: is that correct? [21:13:36] gwicke: if we ignore extensions for now, just specyfing support of core versions is just taking what we had in PHP entry points and also using it in extension.json [21:13:50] jzerebecki: yes. [21:14:18] legoktm: yeah, versioned dependencies is a feature that's pretty standard in other systems too [21:14:20] But the part about extensions isn't really set in stone and I don't think it makes much sense to discuss it since it's basically going to be rehashing what we talked about last time. [21:14:27] legoktm: how do we avoid extensions using conflicting libraries, then? i thought that would be done via composer? [21:14:50] gwicke: For extension => extension dependencies and other features like what extension.json does. [21:15:00] DanielK_WMDE_: the composer merge plugin takes care of that. [21:15:12] legoktm side note: are there PHP/Python/JS libraries supporting this versioning spec? I imagine various clients will want to parse extension.json [21:15:21] matt_flaschen: to me settings management sounds like the most interesting area; versioned dependencies aren't very unique to MW [21:15:22] DanielK_WMDE_: running composer after the extensions are installed with merge tool [21:15:27] legoktm: ah, right. i think i understand the autoloader issue now [21:16:18] spagewmf: it's the same format as composer, so PHP yes. I haven't looked at whether Python or JS libraries exist yet, but I'm pretty sure they do. [21:16:23] which are the most difficult settings-related requirements that we need to support? [21:16:44] legoktm: re: conflicting versions: how does that work? E.g. core has one lightncandy version, while extensions/OOUIPlayground's composer.json specifies another. [21:17:05] spagewmf: the composer-merge-plugin would ideally handle that. [21:17:17] But really, I haven't thought much about extensions, and really don't want to implement that anytime soon. [21:17:56] spagewmf: after composer-merge fed that to composer, composer will complain [21:18:14] can we enforce a common/global set of dependencies ? So that we know what we are deploying and have all extensions to be tested/deployed against that common set? [21:18:25] legoktm: is there anything in this proposal about settings management? [21:18:37] gwicke: like configuration? no? [21:18:44] cause I don't see how we can run two versions of the same lib in php [21:19:09] hashar, we can't. If the dependencies actually conflict, it won't be installable. See what jzerebecki said. [21:19:11] jzerebecki legoktm: hmm, well right now I have vendor/zordius/lightncandy in core and in core/extensions/OOUIPlayground. [21:19:13] hashar: you can make a run with all extensions installed. composer will complain if there are unresolvable conclicts. [21:19:24] legoktm: what is the motivation for writing our own? [21:19:41] so how do we catch the conflicts before deployment? [21:19:47] (or cuting a release) [21:19:48] However, things like Extension:A depending on lightncandy 1.5.* and Extension:B depending on 1.* are obviously resolvable. [21:20:09] I was assuming that we have special requirements that aren't well covered by existing packaging systems [21:20:20] hashar: also you could add another set of dependency declarations like the openstack doc regarding global dependencies outlined [21:20:21] hashar, I think legoktm said that is out of scope for now. [21:20:29] gwicke: to do the things we need when installing extensions, on top of managing library dependencies. like config, db setup, registering hooks, etc [21:20:39] at least that's my understanding [21:20:46] spagewmf: the "first" autoloader that provides a class will win in that case. Probably the version from core [21:20:49] hashar: however i would recommend to only do the run with all extensions, that already prevents missmatches [21:21:04] #link https://github.com/openstack/requirements#global-requirements-for-openstack-projects OpenStack global requirement system [21:21:14] DanielK_WMDE_: if I understand legoktm correctly, that's out of scope [21:21:44] it's already implemented. [21:21:51] gwicke: "work on all platforms where MediaWiki works" is the implicit package management requirement that I see [21:22:05] I think the reason we are doing our own thing is because composer is our preferred technology and we are using it to the limit of its capabilities [21:22:12] so we end up with a composer-based system [21:22:16] gwicke: well, we also need an "install plugin" mechanism. that's not the same as "pull in dependencies". composer doesn#t do that. i don't know of a nice tool that does this for php. [21:22:20] rather than, say, apt/dpkg which is not composer-based [21:22:28] right, this would be building on top of composer [21:22:43] I don't think we'd have a large amount of code on top of it [21:23:18] I see a large cost in building a separate system for PHP, and I'm not clear about the justification for this cost [21:23:21] legoktm: so, what are the open questions? [21:23:43] gwicke: what would you do instead? [21:24:03] gwicke, would you propose just using apt, or what? [21:24:15] DanielK_WMDE_: the questions i'd like to get resolved: 1) Is everyone ok with "supports": ">1.23<1.26" in extension.json and can I begin implementation?, and 2) Are people ok with the tardist service and can I begin implementation? [21:24:20] DanielK_WMDE_: I think we should look carefully at what we could do with existing, more general packaging systems [21:24:46] such as? [21:25:08] apt, rpm, docker would be the most obvious ones [21:25:20] legoktm: can you clarify if the syntax in the supports statement is exactly the same as the one supported by composer for dependencies? [21:25:36] legoktm: can some of your work end up being upstreamed to composer ? I guess some features might be of interest to upstream [21:25:36] apt and rpm are right out. The are linux distribution specific [21:25:44] rpm probably doesn't make sense since we don't have as much institutional knowledge. [21:25:48] jzerebecki: yes. I wrote "Any type of version contraint supported by composer should work." in the rfc [21:25:53] thx [21:25:59] Docker might be too much isolation, not sure? [21:26:05] bd808: do we have a hard requirement for Windows support? [21:26:17] docker is linux only plus limits the underlying virutlaization options for the host [21:26:21] gwicke: do we not? [21:26:30] gwicke: deb / rpm is a dead end imho for dev. It is up to the distribution to deal with the packaging work imho. And I don't see us doing the integration work with whatever distributions can ship has dependencies. [21:26:32] I wouldn't assume so [21:26:45] Docker is also linux kernel only [21:26:47] hashar: I'm not sure what would need upstreaming, I'm mainly imagining MW specific code on top of composer, but I am in contact with one of the composer maintainers about it [21:26:50] I don't think this is a big enough win to justify dropping Windows support. [21:27:09] the big win is that we can actually package MW with parsoid etc [21:27:10] legoktm: [21:27:13] legoktm: sold :-] [21:27:16] matt_flaschen: you are saying we should use apt? [21:27:17] gwicke: Are you ready to tell all the MediaWiki users in the world that we are not supporting the #1 commercial operating system used by businesses? [21:27:26] bd808: on the server? [21:27:32] yes on the server [21:27:41] TimStarling, no, not really, since what about rpm distros, and Windows and BSD, etc. [21:27:41] gwicke: Parsoid isn't an extension. [21:27:42] Windows! [21:27:56] legoktm: it's part of the MW + VE experience [21:28:15] composer may well evolve into something similar to python's packaging system [21:28:16] so we should properly package it [21:28:18] Presumably that's why node (npm) and Ruby (gem/bundler) both made their own non-system level systems. [21:28:18] heh, windows.. [21:28:26] gwicke: it's very convenient for (especially front end) developers to be able to run mediawiki under windows. a vm would work, but makes debugging annoying. [21:28:38] python's packaging system can generate debs, rpms, etc. [21:28:51] but that package management discussion get out of scope of this meeting isn't it? legoktm seeks approval for two questions [21:28:52] so, what about Pear? [21:28:53] gwicke: sure, but my current RfC doesn't address services at all, and I don't think it really makes sense to. [21:29:12] I would love to have statistics on behind-the-firewall installation base to inform conversations like this [21:29:15] legoktm: what do you propose for a longer-term solution? [21:29:22] DanielK_WMDE_: Pear is a dead end but I guess you were joking :-D [21:29:34] gwicke: ... the RfC I wrote? [21:29:44] hashar: half way. Pear *should* have been what we need. I guess it isn't. [21:29:59] Apparently someone at microsoft installed mediawiki on a few thousand Azure instances when they were testing their buildout... So I think we do have users :) [21:30:02] gwicke: I don't really understand, I don't really have an opinion on services. [21:30:23] azure is running linux too [21:30:41] csteipp: are you sure they even used windows? [21:30:50] legoktm: can you explain the branching strategy, and how it ties into tardist? when exactly would branches be created for extensions? [21:31:18] legoktm: my concern is that a custom solution will basically integrate with nothing outside of MW core [21:31:21] legoktm, I have no objections to the 2 points you mentioned aboe (version syntax and tardist). [21:31:41] TimStarling, interesting. I didn't know that about the Python system (generating deb and rpm). [21:31:44] and will divert efforts from more general integration [21:32:12] gwicke, it integrates with Composer, Composer libraries, and extensions, no? [21:32:12] if there is a clear roadmap to auto-generate debs or rpms, then that could maybe be solved [21:32:33] DanielK_WMDE_: sure! right now we create branches whever we branch core, which kind of works, but plenty of extensions maintain compatability in master for older core, so it doesn't really work. Going forward with say 1.26, we'll stop creating extension branches. When an extension decides to drop support for 1.25, they will create REL1_25 branch at the commit before that. the tardist service will read extension.json to see which core versions [21:32:33] should get master, and which fall back to branches. Also we'll be able to use tardist to display info like authors, description, license info on Special:ExtensionDistributor [21:32:33] matt_flaschen: that's a small world [21:32:46] gwicke, do the Debian and Red Hat, etc. maintainers actually use the auto-generated DEB and RPM from those systems that can do so? [21:32:49] gwicke, my guess would be no. [21:33:00] They build their own (or don't, for less popular gems, eggs, whatever). [21:33:02] no, but we can offer our own repo [21:33:22] if we value timely updates over coming-with-Debian-stable [21:33:37] or RH enterprise [21:33:46] composer to deb script: https://github.com/RobLoach/composer.deb [21:34:24] well, maybe that is not quite what we want [21:34:34] if that works well enough, then I could be convinced [21:34:59] it looks pretty basic [21:35:05] Isn't that just to install Composer itself? [21:35:07] it just installs composer itself, sorry [21:35:28] TimStarling: that is a composer debian package, not a composer-managed2deb [21:35:31] I was looking through https://github.com/composer/composer/issues/3125 and just posted a link that looked relevant from the ticket description before reading it [21:35:59] legoktm: how would the branching be triggered? a commit hook? [21:36:24] no, manual [21:36:29] legoktm, I'm a little concerned about dropping the REL1 branches. [21:36:32] but yes it is possible to create something that translate a composer package to deb, but the question with these things is always who will do the work? [21:36:37] DanielK_WMDE_: I'm unsure about the specifics. Right now I was just thinking about manual, but it could be automated [21:36:53] legoktm, maybe that should be opt-in, so if extension developers don't know how it works and annotate their core support it keeps working as it does now. [21:37:19] anyway, to have debs for mediawiki extensions, we would presumably first need to have a deb for mediawiki core [21:37:23] If the default is to assume it supports all core, that could be problematic, vs. the current default of assuming ext REL1_26 supports core REL1_26. [21:37:24] legoktm: manual doesn#t happen :P [21:37:25] which I understand we don't have [21:37:43] jzerebecki: we have several Debian developers on our staff; the main thing is that we'd need to set aside some time to make it happen [21:37:56] we already have packages for several services like Parsoid [21:38:12] TimStarling: the problem would be to make a distro-neutral deb, i guess [21:38:18] matt_flaschen: the current assumption is usually wrong because the majority of extensions aren't touched outside of i18n updates. If extension maintainers aren't updating what core it supports, there's a very good chance it doesn't support current master :P [21:38:37] yeah, generating from generic metadata is probably the way to do it [21:39:08] we don't want to have a mediawiki/core/debian directory, debian hate it when you do that [21:39:15] we have something similar for node projects, also an automated docker image build script [21:39:17] I mean, not checked into git [21:39:29] DanielK_WMDE_: heh :P I see no reason why it couldn't be automated with a commit hook or something. [21:39:42] legoktm, if you drop the extension branches, it's even less likely to Just Work (for developers not understanding this new system). At least now, it gets automatically cut so it will miss later backwards-incompatible changes. [21:40:18] (Changes to the extension) [21:40:19] matt_flaschen: when someone makes a backwards-incompatible change, it's their responsibility for updating extension.json to indicate the new level of core support. [21:41:00] TimStarling: debian developers only matter if we plan to push this into Debian proper [21:41:10] instead of offering our own repository [21:41:42] so unless that's a priority for us I wouldn't worry too much about it [21:41:46] legoktm, some developers are not going to do that, especially at first. So the question is whether to keep auto-cutting branches for them, or just push people hard to adopt this new system. [21:42:24] gwicke: I think you underestimate the amount of work required to ship and maintain stuff in Debian. And our Debian developers are ops, not devs with us not planning to use .deb packages for deployment. So imho it is good idea on the paper but I don't see us going to maintain deb packages. [21:42:45] hashar, I think he's saying to use our own repo, rather than trying to update actual Debian. [21:42:46] matt_flaschen: yep, I think it will take time. Maybe aiming for 1.26 isn't reasonable and we should create branches for people who haven't migrated for a while. [21:42:49] hashar: I'm not proposing to maintain this 'in Debian' [21:43:11] I agree that Debian proper would be a lot of work, for little gain [21:43:40] matt_flaschen: if no 'support' is in extension.json, create the branch when core is branched. We'll also have to do that anyways for extensions that aren't converted to extension.json. [21:43:49] there were some criticisms previously about socialisation of the introduction of extension.json [21:44:04] even if we had our own, we have a lot more to deal with such as making defining dependencies and ensuring ext + core works well together. [21:44:06] legoktm, yeah, that's what I was proposing. [21:44:24] hashar, that's exactly what we're talking about right now, especially the 'ext + core' part. [21:44:27] hashar: yup, which is what this RFC is proposing [21:44:42] we should probably think about how we are going to communicate this change [21:44:50] bd808, jzerebecki: seems we're not using the composer-merge-plugin functionality. Right now 27 extensions ship composer.json and I run composer in each extension's directory, and end up with e.g. extensions/{Flow/vendor/Pimple,OOUIPlayground/vendor/pimple}, no warnings, and randomly one wins at runtime. Is that because core's composer.json doesn't yet have the "merge-plugin": { "extensions/*/co [21:44:56] mposer.json" } stanza yet? [21:45:10] spagewmf: yes [21:45:30] spagewmf: if it had you would only run composer once in the core root [21:45:32] TimStarling: yeah. I think the biggest problem is that we duplicated extension.json and the PHP entry point for a while, and different things were reading different ones and it got confusing. [21:45:35] you could locally add that to your composer.local.json [21:45:42] TimStarling: well, first I'd like to get it approved ;) [21:45:43] legoktm: so I think one important requirement is to keep the metadata fairly universal, so that we can extract the dependency version and use it in auto-generated packages [21:46:00] TimStarling: getting in touch with the WikiApiary folks (I see here that they have two mailing lists: ) seems like a good way to socialize it [21:46:18] gwicke: I think adopting what composer is using is "fairly universal" [21:46:24] well, can we have consensus with caveats? [21:46:50] sure [21:46:56] gwicke: matt_flaschen so my point. Lets deal with defining deps and once done look at providing deb/rpm packages :-] [21:47:15] I am not ready to endorse with caveats; I think more work needs to be done to rule out existing package manifest formats [21:47:31] legoktm: the syntax "supports": ">=1.23,<1.26" doesn't mention the version of *what* [21:47:31] I share gwicke's concern that this is going to be another homegrown solution full of MediaWiki-specific idiosyncracies [21:47:40] legoktm: so it's implicitly tied to mw core? [21:47:53] that makes me uncomfortable... [21:47:57] DanielK_WMDE_: "supports" means core. maybe it should be called "supports-core"? [21:48:34] legoktm: should this be mediawiki specific at all? wouldn't it be better to make this a generic plugin mechanism, that kones nothing about mw? [21:48:36] ori, but if we adopt, e.g. .deb as the canonical package manifest format, what about Windows and BSD? [21:48:41] what is proposed is to move core dependencies from a runtime hack (wfUseMW() etc.) to JSON metadata [21:48:53] (I'll just assume RPM users will use alien, but not sure that's realistic either) [21:48:59] depends: { 'mediawiki-core': '>=1.x.x', 'foobar': '~2.5.6' } [21:49:09] I would not have thought that would be opposed on the basis of inelegance [21:49:10] legoktm: so extensions would also need to specify what they extend. "extends": "mediawiki"? [21:49:15] matt_flaschen: I wasn't suggesting .deb [21:49:23] gwicke, for 'foobar', isn't that just a Composer library dependency (already supported, IIRC)? [21:49:25] ori: so far I've written my RfCs with the premise that by not introducing any extra dependencies or requirements of sysadmins, that would make it easier for them to be approved and implemented. The alternate ideas are things like deb, rpm, and docker. [21:49:25] yea, what gwicke said [21:49:39] obviously we can't package extensions as debs when nobody at WMF even cares to package the mediawiki core as deb [21:49:53] ori, so do you have an alternative, or want more time to research? [21:50:14] DanielK_WMDE_: I'd much rather have something that works for MW and can then be extended into something general rather than writing some generic plugin system that no one ever uses besides MW. [21:50:18] want more time to research, but I think the onus ought to be on the RfC writer too -- you should survey the field as part of due diligence [21:50:47] composer's local installation is a less invasive solution than deb [21:50:53] ori, I think he did. That's why it extends Composer. [21:51:01] TimStarling, legoktm: re communication: on mw.org extension.json redirects to https://www.mediawiki.org/wiki/Manual:Extension_registration . examples/BoilerPlate doesn't have an extension.json yet. The general "How to write an extension" pages don't mention this nor does it mention a bunch of other changes like new globals config. [21:51:06] composer's job is to assemble a source tree [21:51:11] matt_flaschen: if that happened, then it would be great to document that [21:51:18] that source tree can then be packaged however you want [21:51:18] Just to be clear, extension.json is explicitly MW-specific, so extends: 'mediawiki' should not be necessary. [21:51:24] spagewmf: right, I think there are bugs open for that which I plan to do before 1.25 is out. [21:51:29] legoktm: do you have any pointers to alternatives you evaluated? [21:51:40] legoktm: yea, but if avoiding assumptions is cheap, let's do it. i like gwicke's proposal: supports: { 'mediawiki-core': '>=1.x.x', 'foobar': '~2.5.6' } [21:52:22] DanielK_WMDE_, what would 'foobar' be? If it's a library, should be handled by composer.json, no? [21:52:24] there are some useful discussions from when the commonjs folks were dealing with the same dillema at http://wiki.commonjs.org/wiki/Packages/A , http://wiki.commonjs.org/wiki/Packages/1.1 . [21:52:36] gwicke: I evaluated using composer directly at and decided to build on top of it. Things like deb/rpm/docker weren't evaluated as they didn't meet the requirements of not introducing other external dependencies [21:52:54] DanielK_WMDE_: like matt said, what's 'foobar'? [21:53:04] legoktm: why is that a hard requirement? (not introducing external dependencies) [21:53:08] matt_flaschen: i'm proposing to not make extension.json mw-specific in the first place. [21:53:15] seems not much i needed to avoid that [21:53:27] could be used by other things, wordpress or whatever. [21:53:30] DanielK_WMDE_: it's already mw specific? [21:53:32] DanielK_WMDE_, it already is since it does MW-specific things like hook registration. [21:53:44] legoktm: wondering the same, especially considering composer isn't even packaged for mainstream distros [21:54:10] (and as such is an external dependency) [21:54:11] ori: "so far I've written my RfCs with the premise that by not introducing any extra dependencies or requirements of sysadmins, that would make it easier for them to be approved and implemented." [21:54:13] extension.json is totally MW-specific [21:54:23] legoktm, matt_flaschen: yes, but that doesn't mean we can't keep the syntax of the meta data file neutral. [21:54:24] gwicke: That's a strawman argument and you know it [21:54:27] gwicke: composer was discussed and approved in a different RfC. [21:54:51] legoktm: " It's important to note that extensions are not libraries. Libraries typically just require an autoloader, whereas extensions need an autoloader, but also need to register hooks, special pages, API modules, and much more." -- looking at https://packagist.org/explore/ , three of the top five packages are symfony components [21:54:57] but then, maybe the abstraction isn't worth the pain. as i said: if it's cheap. if not, well, then it's mw-specific. [21:55:30] bd808: it's a consideration that does affect our users [21:55:38] and pertains to the argument about dependencies [21:55:45] legoktm: do you have plans to version the manifest format itself? [21:55:50] the way, e.g., chrome extensions do? [21:55:52] gwicke: composer is alpha, why would anyone use that, much less in production, much less package it for a distribution? [21:56:04] ori: those *are* libraries, they're meant to be used in PHP code. [21:56:24] jzerebecki: the web moves fast and having a technological edge is often prized more than security and stability [21:56:25] ori: do you mean versioning the schema used by extension.json? [21:56:32] legoktm: yes [21:56:41] jzerebecki: dunno, maybe to make it reasonably easy to use, demonstrate its maturity? [21:56:46] that would give us room to iterate and even possibly converge with another standard eventually [21:56:51] I am a bit frustrated with this discussion to be honest [21:56:53] ori: I don't have any plans for doing that, but it seems like a good idea. [21:56:53] ori, and symfony itself is a framework, AIUI, not a user-facing thing like Wordpress. [21:56:59] Or MediaWiki. [21:57:04] TimStarling: how come? [21:57:16] it seems like some participants have started it not even knowing what composer is, what extension.json is [21:58:05] TimStarling: don't mistake criticism for not knowing [21:58:18] gwicke: to demonstrate its maturity upstream would first need to think of it that way, and perhaps start making proper release, encourage user to use releases instead of nightlies [21:58:32] jzerebecki: maturity is not the end-all-be-all [21:58:36] (hi heatherw) [21:59:44] to me composer doesn't look like a very future-proof solution, but it could be a stepping stone towards a more general packaging solution [21:59:47] anyways, versioning the schema for extension.json and giving it a formal specification (in JSON Schema) strike me as prerequisite to adoption / endorsement [21:59:57] ori: it already has a formal schema [22:00:13] ori: i'm not saying that, i'm simply arguing from what gwicke said. but the releases thing would be useful, however as you said having a technological edge is often prized more than security [22:00:18] https://github.com/wikimedia/mediawiki/blob/master/docs/extension.schema.json [22:00:45] legoktm: oh, cool. that is not linked to from the rfc, is it? [22:01:04] ori: no, because extension.json was introduced in a different RfC, and this one is just about adding properties to it. [22:02:01] legoktm: what is your estimate for the effort required to build the custom tooling for this? [22:02:36] this is not a good RFC on which to express your disdain for composer [22:02:50] gwicke: I have prototypes for both, so whenever I have free time, and i don't know when that is or how often. [22:02:58] the ship sailed on composer years ago [22:03:13] yes [22:03:16] if you want to turn it around and use something else, that is a massive effort and a different RFC [22:03:40] So really I'd like consensus on 1) moving wfUseMW --> "supports": "whatever" (bikeshed on property name), 2) the tardist service which we didn't really get to discuss. [22:03:59] +1 from me [22:04:04] we now extensively use composer in core and extensions [22:04:18] legoktm: so less than a quarter? [22:04:25] to now criticise every RFC that attempts to use that established framework on the basis that you don't like composer seems a bit ridiculous [22:04:33] gwicke: I really don't know. [22:04:49] legoktm: sorry if I missed this part of the discussion, but why not put the MediaWiki version dependency as part of the "depends" field? [22:04:52] legoktm, +1 (supports-core), conditioned only on good communication, updating the formal schema, and keeping back-compat branching strategy for extensions that don't use supports-core (for a couple core releases at least). [22:04:59] i.e. why add a separate "supports"? [22:05:14] ori: that was discussed months ago [22:05:17] this meeting is out of time [22:05:20] OK [22:05:41] ori, what depends field? [22:06:02] Oh, the one for extension dependencies. [22:06:05] yeah [22:06:11] please make action items [22:06:16] i assumed this was up for debate because the discussion started with I made a few changes to the RfC since then: 1) dropping support for the web interface for initial implementation 2) change how core support is stated [22:06:21] Which I notice is not in the formal schema yet. [22:06:31] legoktm: i guess we should have started with tardist... [22:06:33] (depends, I mean) [22:06:35] ori: it's a bit weird to think that extensions depend upon core, and a few other people (I think DanielK_WMDE_) also brought that up in the last time when discussing the composer implementation [22:06:47] matt_flaschen: right, that's the point of this RfC ;) [22:06:55] ori: we did discuss it earlier; I proposed something similar to what you are saying [22:07:03] legoktm, I know this is proposing supports/supports-core, didn't think it was proposing depends as well. [22:07:10] so no objections to "supports" (bikeshed on name) in core? [22:07:11] re: action items [22:07:14] spagewmf had a few [22:07:15] TimStarling, legoktm: re communication: on mw.org extension.json redirects to https://www.mediawiki.org/wiki/Manual:Extension_registration . examples/BoilerPlate doesn't have an extension.json yet. The general "How to write an extension" pages don't mention this nor does it mention a bunch of other changes like new globals config. [22:07:37] ori: those all have bugs iirc [22:07:47] So really I'd like consensus on 1) moving wfUseMW --> "supports": "whatever" (bikeshed on property name) [22:08:02] I think it's fair to make updating BoilerPlate and the docs a blocker to proceeding further. Shouldn't be too much time. [22:08:03] gwicke: please say if you are objecting to this or not [22:08:25] cool. how about getting in touch with wikiapiary folks? that is an entry-point for discovering mediawiki extensions for many people [22:08:29] DanielK_WMDE_: I guess we can have another meeting for that? [22:08:47] TimStarling: I think it's difficult to make a decision without some idea of how much effort it will be [22:08:58] ori: I'm talking with one of them on-wiki about it on Manual talk:Extension registration [22:09:08] legoktm, don't know if you really need an additional meeting for tardist. Maybe Just Do It. [22:09:08] I'll quibble with the name; 'support' is not great [22:09:15] ok, so there is no consensus [22:09:18] the extension is not supporting mediawiki; it is dependent on its facilities [22:09:46] TimStarling, because of the name (supports vs. supports-core, vs. whatever)? [22:09:53] I can accept 'supports' if need be. [22:09:57] ori: 14:48:59*gwicke depends: { 'mediawiki-core': '>=1.x.x', 'foobar': '~2.5.6' } [22:10:01] because gwicke is not supporting it [22:10:18] gwicke, like I've said repeatedly, if foobar is a library, that is in composer.json [22:10:36] I think the name can be hammered out on wikitech-l later, I have no strong feelings. I'm mainly looking for approval on introducing that ability to extension.json. [22:11:03] legoktm: +1 for getting rid of wfUseMW() [22:11:07] legoktm: is there a patchset for this already? [22:11:15] matt_flaschen: what if foobar is another extension? [22:11:25] matt_flaschen: is there support in composer for generic dependencies? [22:11:28] legoktm: if a) all extensions had a composer.json and b) enabling extensions was separate from install, would it make sense to move extension "depends" to composer.json? [22:11:34] DanielK_WMDE_, https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management#Dependencies_upon_extensions, but not sure if it's implemented. [22:11:37] or is that only limited to libraries? [22:11:39] legoktm: just submit a patch for it and we can continue the discussion in gerrit [22:11:44] TimStarling: ok, sounds good [22:11:58] sorry, but I think gwicke is right. The whole "not a library" thing is blurry and not enough of a reason to not push in the direction of using standard fields that are supporting by tools by default [22:11:59] gwicke: libraries only, afaik [22:12:07] crikey [22:12:12] stop talking already [22:12:18] #endmeeting [22:12:18] Meeting ended Wed May 13 22:12:17 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:12:18] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-05-13-21.02.html [22:12:18] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-05-13-21.02.txt [22:12:18] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-05-13-21.02.wiki [22:12:18] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-05-13-21.02.log.html [22:12:32] thanks everyone [22:12:37] gwicke, compser deps are for anything listed/listable at https://packagist.org/ . My understanding is that we don't want to list extensions there due to MW-specific issues. [22:12:44] ori: the problem is that we need to do more than what composer offers out of the box [22:12:49] ie a custom installer [22:12:53] legoktm: thx for pushing this forward [22:12:53] 𝄞♩♫ business hours are over baby <-- New Zealand's greatest comic music video [22:13:18] matt_flaschen: I see, curious what those issues are [22:13:48] some refreshing french music for you guys https://www.youtube.com/watch?v=NwVA5zYfNWw [22:14:07] TimStarling: I don't know why you're throwing a tantrum. If you want discussions to be more focused, I think you should start the conversation by stating explicitly what is up for debate (or require the RfC author to do so). [22:14:19] gwicke, legoktm can probably explain it better. My understanding is thinks like update.php and hooks, etc. [22:14:25] because time [22:14:37] ori: I did that in the first two minutes of the meeting, but it was largely ignored. [22:14:42] it's courteous to end meetings when they are meant to be ended [22:14:48] not really. the clearest statement was So really I'd like consensus on 1) moving wfUseMW --> "supports": "whatever" (bikeshed on property name), 2) the tardist service which we didn't really get to discuss. [22:15:11] I'm at the end of 2hour 15mins of meetings and need to do things that aren't work [22:15:11] gwicke: if you say the extension depends on mediawiki, it will pull in mediawiki into the vendor directory. not usefull... [22:15:12] that came at the end [22:15:36] gwicke: the composer to manage extensions issues are pretty well covered in the discussion of https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Extension_management_with_Composer [22:15:38] it's the middle of the night for DanielK_WMDE_ and he needs to go to bed [22:15:44] ori: actually [14:06:03] I mainly want to talk about and discuss the new way to specify which versions of core are supported and the branching strategy: https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management#Dependencies_upon_MediaWiki_core and the proposed tardist service to update ExtensionDistributor for these changes: https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist <-- 6 minutes, [22:15:44] but no one had really said anything before that. [22:15:53] TimStarling: yes mom ;) [22:16:04] legoktm: :-/ [22:16:27] s/I mainly/I only/ [22:17:05] I have go to now, will follow up on wikitech-l [22:17:14] See you all later. [22:17:19] see you! [22:17:32] see you [22:18:41] #action Everyone to just shut up already.