[00:17:47] Amgine: yes, that's a good summary [01:05:04] Legoktm: not a fan of rearranging deck chairs. I prefer to implement change which is needed, especially when there is a reasonably serious cost involved. [01:05:45] Amgine: well, it is needed. We need to do this to have a sane extension configuration system for the configuration database [01:08:02] It could be sanely implemented without this change. I think it's easily projectable that an unacceptably high number of 3rd party extension will be abandoned if this is implemented. That's not a direct cost to MW or WMF, but it will hurt the pool of amateurs from which is drawn the volunteer devs. [01:08:18] That said, I don't dislike the concept. [01:08:41] Why would they be abandoned? Nothing would stop them from working [01:09:04] Because this is a change downloaded on them, not something they seek out. [01:09:12] My goal is to write a migration script like the json i18n one, so it should be simple to migrate [01:09:15] What is this change? [01:09:46] harej: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration [01:09:50] Amgine: that would be any breaking change to core though [01:10:07] Yes. Those are fairly rare, actually. [01:10:19] <^d> Amgine: You're kidding, right? [01:10:29] <^d> We break things for extensions every week. [01:10:53] <^d> We do a decent job of grepping for uses, but if it's not in version control there's little we can do (and it's always been that way) [01:10:54] There are a few I've run which have not been substantively changed since 1.15. [01:12:04] Amgine: also, this wouldn't break any existing extensions. It would just prevent people who do use those extensions from eventually switching to a config db / using the extension manager [01:12:37] <^d> As long as it isn't a hard break (and with something like this, I can't see it being so for many many releases), it's doable as-is. [01:13:43] Are you saying this is an optional method of writing extensions? then I have no problem with it. But once it's required, a bunch of people will say it's too much work to rewrite. [01:14:03] <^d> Yes, it'd be optional. [01:14:59] Write a good tutorial and you'll be able to attract support. [01:15:00] there's a such thing as too much work? :P [01:15:30] <^d> Amgine: And hopefully it's one of those things that once the heavy lifting is done, most of it can be done by $anyBoredDeveloper. [01:15:51] <^d> Similar to how we deprecated old i18n formats/registration. [01:15:56] <^d> Old installer extension. [01:15:59] <^d> Etc etc. [01:16:26] [01:16:40] <^d> People been working on that this week. [01:16:48] This RfC has nothing to do with composer :) [01:16:50] <^d> For pulling libraries and such into core. [01:17:03] <^d> I think composer-for-installing-extensions is on ice for now. [01:17:05] legoktm: whether it should or not, it really sort of does. [01:17:48] why? [01:18:04] Because each solution does impact the other. [01:18:14] <^d> See what I said a bit ago. [01:18:17] <^d> I think it's on ice for now. [01:18:35] <^d> Focusing on using it for library-ization of core instead of installing-of-extensions. [01:18:57] ohai lilatretikov [01:18:59] Yah, then that resolves the interaction for now. I just hate the 'for now' bit. [01:19:18] <^d> Well I think the later still needs debating some. [01:19:19] helloo [01:19:43] Amgine: I'm in the camp who doesn't think composer for extensions is a good idea, but my RfC explicitly doesn't break anything to do with composer [01:19:55] <^d> +1 to lego. square peg, round hole and all. [01:20:04] Anyhoo. New pages to add to watch lists. [01:21:21] And LA vs Chicago hockey. [01:21:25] :) [01:22:03] * ^d goes back to trying to exploit __wakeup()s, callbacks and serlization