MediaWiki

Architecture meetings/RFC review 2015-06-10

< Architecture meetings
Just in case meetbot's logs for this meeting (http://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-10-21.02.html) remain lost (due to an NFS outage?, phab:T113000), here we go

2015-06-10 21:00:45 [TimStarling] ori has said that he won't be here until half past the hour
2015-06-10 21:02:28 [TimStarling] we'll start anyway
2015-06-10 21:02:42 [bd808] works for me
2015-06-10 21:02:46 [TimStarling] #startmeeting RFC meeting
2015-06-10 21:02:47 [wm-labs-meetbot] The meeting name has been set to 'rfc_meeting'
2015-06-10 21:02:47 [wm-labs-meetbot] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
2015-06-10 21:02:47 [wm-labs-meetbot] Meeting started Wed Jun 10 21:02:47 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot.
2015-06-10 21:02:55 [TimStarling] #topic 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/
2015-06-10 21:03:01 [legoktm] o/
2015-06-10 21:03:49 [TimStarling] since ori isn't here yet, I thought we might first have a quick discussion about how the RFC process is going and if any changes need to be made
2015-06-10 21:04:06 [TimStarling] since we have just been talking about that in the previous committee meeting
2015-06-10 21:04:44 [bd808] I have enjoyed that RfCs are being discussed rather promptly after publishing
2015-06-10 21:05:11 [TimStarling] yeah, we've cleared the backlog now, and we have a pretty slow flow of new RFCs being written
2015-06-10 21:05:38 [TimStarling] we were wondering why there are not more of them, in fact
2015-06-10 21:05:53 [gwicke] we have been discussing forming working groups around important topics, to make sure that they are tackled
2015-06-10 21:06:34 [gwicke] somewhat similar to a similar idea in the Rust community: https://github.com/aturon/rfcs/blob/rust-governance/text/0000-rust-governance.md
2015-06-10 21:06:43 [jzerebecki] if they are not being tackled is that not because of a lack of resources?
2015-06-10 21:06:58 [bd808] From my new seat in the Reading group I think I've found that many teams don't think about things as needing RfCs
2015-06-10 21:07:17 [bd808] and yes there is the "when would I work on this" angle for other things
2015-06-10 21:07:19 [DanielK_WMDE] jzerebecki: sometimes. more often, they arn't even discussed and decided.
2015-06-10 21:07:28 [gwicke] jzerebecki: I think it's also that issues that span several teams are harder to handle as an RFC
2015-06-10 21:07:44 [legoktm] the move to phabricator has made it harder to follow the development and progression of RfCs, with many still active on mw.o, and phab notifications being generally useless.
2015-06-10 21:07:54 [legoktm] the process itself is going well I think
2015-06-10 21:08:23 [DanielK_WMDE] legoktm: i actually find it easier to follow now, and easier to maintain
2015-06-10 21:08:25 [csteipp] I agree, I think they're less discoverable in Phabricator
2015-06-10 21:08:31 [spagewmf] legoktm: all active mw.o RFCs should have a phab task and their status automatically becomes "See phabricator"
2015-06-10 21:08:37 [DanielK_WMDE] but phab notifications could be improved. not that mw watchlists were too great either...
2015-06-10 21:08:55 [DanielK_WMDE] csteipp: how could that be changed?
2015-06-10 21:09:07 [gwicke] gmail's poor filter support on headers doesn't help with phab notifications
2015-06-10 21:09:07 [bd808] we have a better chance (and motivation) to improve watchlists than to improve phab
2015-06-10 21:09:39 [DanielK_WMDE] bd808: i'm actually not sure that is true...
2015-06-10 21:09:52 [gwicke] but, writing an RFC on a large and only partially understood issue is hard
2015-06-10 21:09:57 [DanielK_WMDE] gwicke: another use case for a pubsub service :)
2015-06-10 21:09:59 [gwicke] *issue
2015-06-10 21:10:32 [DanielK_WMDE] bd808: do you think we should go back to a wiki based process? or have an overview page on the wiki, maintained by a bot?
2015-06-10 21:10:58 [gwicke] for complex issues it can be easier to gather interested folks and start to figure it out
2015-06-10 21:11:27 [csteipp] DanielK_WMDE: I'm not entirely sure, other than changes to Phab, which are being worked on (search being a major issue). Actually, I think the last time I looked the workboard wasn't up for the Phab project-- so it actually looks better now.
2015-06-10 21:11:27 [DanielK_WMDE] gwicke: in an RFC (Request For Discussion)?
2015-06-10 21:11:34 [bd808] I actually don't mind Phab for tracking the status but I find it less useful for discussion. Lack of threading comes to mind as a drawback
2015-06-10 21:11:36 [legoktm] DanielK_WMDE: it's generally a workflow thing for me. I could see & review every change to all open RfCs in my inbox with an RSS feed, but now I get a bunch of useless emails that require me to use a web browser to look at a bunch of diffs individually to figure out what's going on
2015-06-10 21:11:36 [DanielK_WMDE] gwicke: err, RFD, of course :)
2015-06-10 21:11:37 [gwicke] DanielK_WMDE: ;)
2015-06-10 21:12:31 [TimStarling] in the old process, a lot of the RFCs had LQT talk pages
2015-06-10 21:12:34 [DanielK_WMDE] bd808: i actually find it much more useful for discussion than plain mw talk pages. with flow, well, maybe.
2015-06-10 21:12:46 [bd808] The history of an RfC that is being managed mostly/solely as a phab task description is hard to follow
2015-06-10 21:13:02 [DanielK_WMDE] legoktm: can you show me how to do that? i mean for RFCs specifically, not everything on my watchlist
2015-06-10 21:13:11 [csteipp] DanielK_WMDE: One minor thing-- could someone describe the expected process on https://phabricator.wikimedia.org/project/profile/52/?
2015-06-10 21:13:19 [DanielK_WMDE] oh, related changes...
2015-06-10 21:14:01 [DanielK_WMDE] csteipp: you mean this? https://www.mediawiki.org/wiki/Requests_for_comment/Process
2015-06-10 21:14:13 [DanielK_WMDE] there should at least be a prominent link, yea...
2015-06-10 21:14:48 [legoktm] DanielK_WMDE: https://www.mediawiki.org/w/api.php?hidebots=1&days=14&limit=50&target=Category%3AOpen_requests_for_comment&translations=filter&action=feedrecentchanges&feedformat=atom
2015-06-10 21:14:55 [gwicke] DanielK_WMDE: are you changing it?
2015-06-10 21:15:01 [chasemp] tickets definitely aren't a wonderful multithread debate medium, there is a more question/answer oriented app in beta but even that is more stackoverflow-esque
2015-06-10 21:15:23 [TimStarling] in terms of administration, I would say phabricator makes things easier
2015-06-10 21:15:48 [gwicke] DanielK_WMDE: I added a link
2015-06-10 21:15:50 [TimStarling] it's easier to drag things from column to column in phab than to change the index heading in the old system
2015-06-10 21:16:08 [csteipp] gwicke: Thanks :)
2015-06-10 21:16:16 [bd808] TimStarling: if that part is working well for the committee then +1
2015-06-10 21:16:22 [TimStarling] and I can write a comment on an RFC ticket and reasonably expect the author to see it
2015-06-10 21:16:22 [DanielK_WMDE] gwicke: so did I, and phab doesn't handle edit conflicts :P
2015-06-10 21:16:39 [bd808] (which as you know means nothing :)
2015-06-10 21:16:51 [gwicke] I also think that on balance Phabricator is a win
2015-06-10 21:17:18 [DanielK_WMDE] legoktm: thanks :)
2015-06-10 21:18:07 [TimStarling] phab at least does have a notification system
2015-06-10 21:18:20 [legoktm] TimStarling: I feel the opposite, I end up missing comments because they get lost in all the bug mail, while it was really easy to filter out RfC related stuff in the past based on on-wiki categories
2015-06-10 21:18:21 [gwicke] DanielK_WMDE: ouch
2015-06-10 21:18:25 [chasemp] if we can get teh realtime stuff going it will be much more useful as well (notifications)
2015-06-10 21:18:40 [chasemp] i.e. someone commented on this while you were typing, etc
2015-06-10 21:18:48 [gwicke] realtime phab, or realtime MW?
2015-06-10 21:19:13 [chasemp] phab, my apologies that was primarily an addendum to TimStarling's comment
2015-06-10 21:19:35 [TimStarling] legoktm: you would want the equivalent of related changes for phab?
2015-06-10 21:20:09 [gwicke] TimStarling: I opened a ticked about subscribing to a tag / project without being a member
2015-06-10 21:20:18 [DanielK_WMDE] i think phab isn't the holdup. i think people either don't think they need or want input, or they beleve the process is too slow, or requires too much work.
2015-06-10 21:21:00 [gwicke] DanielK_WMDE: agreed
2015-06-10 21:21:08 [DanielK_WMDE] TimStarling: that would be nice... isn't there a project feed, though?
2015-06-10 21:21:11 [TimStarling] and to some extent they are right
2015-06-10 21:21:13 [legoktm] TimStarling: yes, I'd like all the features of MW's recentchanges system in phab ;)
2015-06-10 21:21:18 [TimStarling] obviously doing your own stupid thing is quicker than asking for advice
2015-06-10 21:21:38 [DanielK_WMDE] legoktm, TimStarling: https://phabricator.wikimedia.org/project/feed/52/
2015-06-10 21:21:48 [DanielK_WMDE] can we get that as an atom feed?
2015-06-10 21:22:16 [TimStarling] and it requires more work to write a design document that other people can understand than to write a few notes to yourself before starting to code
2015-06-10 21:22:17 [gwicke] TimStarling: at the same time, a lot of advice exchange is happening all the time in regular tasks
2015-06-10 21:22:24 [gwicke] and code review
2015-06-10 21:22:28 [DanielK_WMDE] https://phabricator.wikimedia.org/T67
2015-06-10 21:22:43 [chasemp] we did propose briefly an RSS feed version of this and upstream as unconvinced as they saw RSS as dying technology (the project feed)
2015-06-10 21:22:51 [chasemp] that doesn't mean a better made case wouldn't win the day
2015-06-10 21:22:54 [TimStarling] gwicke: true
2015-06-10 21:23:02 [legoktm] DanielK_WMDE: https://secure.phabricator.com/T1928 upstream thinks RSS is dead
2015-06-10 21:23:32 [legoktm] DanielK_WMDE: the on-phab feed isn't useful: "GWicke edited the description of T99088: [Meta-RFC] Content adaptability, structured data and caching." tells me nothing about what he did, on mw.o I could see the entire diff
2015-06-10 21:23:52 [DanielK_WMDE] legoktm: one person there does, anyway. we could argue
2015-06-10 21:23:59 [legoktm] :P
2015-06-10 21:24:03 [gwicke] there is a link to a diff if you go to the task, but it's somewhat hidden
2015-06-10 21:24:10 [legoktm] but maybe I'm the only one who's frequently running to this as an issue?
2015-06-10 21:24:26 [spagewmf] also ArchCom hasn't asserted itself. a) A comment from #ArchCom member on a ticket should be like the Word of God; b) ArchCom should produce a Future of MediaWiki story, saying This is How it's Gonna Be (now help realize it)
2015-06-10 21:24:28 [chasemp] we could easily request the feed link go the diff itself
2015-06-10 21:24:32 [chasemp] I have made similar requests
2015-06-10 21:25:49 [gwicke] spagewmf: you are asking for a lot
2015-06-10 21:26:01 [jzerebecki] i'd like for mails with "daniel edited Description." to contain the diff...
2015-06-10 21:27:36 [gwicke] jzerebecki: +1
2015-06-10 21:27:54 [TimStarling] I'd like MW watchlist emails to contain the diff
2015-06-10 21:28:21 [spagewmf] gwicke: not really, a) is just prefixing comments with "Architecture Committee thinks..." and b) is https://www.mediawiki.org/wiki/Architecture_focus_2015 with some more context of what's already agreed
2015-06-10 21:28:26 [DanielK_WMDE] spagewmf: i'm definitly with you on (b). not so sure about the Word of God thing, but it's appealing :P
2015-06-10 21:28:33 [jzerebecki] TimStarling: +1
2015-06-10 21:29:07 [gwicke] spagewmf: re b), I don't think the committee can do this in isolation
2015-06-10 21:29:50 [TimStarling] there's something to be said for dogfooding
2015-06-10 21:29:58 [DanielK_WMDE] gwicke: i think the archcom could *propose* such a vision, and put it up for discussion, as a whole.
2015-06-10 21:30:04 [gwicke] I think the archcom can make sure the process to build such a shared vision happens, and guide it in the right direction
2015-06-10 21:30:07 [jzerebecki] spagewmf: a) means ArchCom comments containing one contradictions results in undoing the universe :P
2015-06-10 21:30:11 [gwicke] but I don't think it can completely replace it
2015-06-10 21:30:14 [TimStarling] it would be a bit sad if we patched that feature into phabricator before we got it in MW
2015-06-10 21:30:27 =ori joined channel
2015-06-10 21:30:29 [spagewmf] b) things like you should be using OOUI; you should have tests and continuous integration; you must have a solid API. Things that set direction for anyone developing a feature
2015-06-10 21:30:40 [DanielK_WMDE] ori: on the minute :)
2015-06-10 21:30:40 [ori] hello
2015-06-10 21:30:41 [TimStarling] hi ori
2015-06-10 21:31:01 [ori] catches up with the backlog quickly
2015-06-10 21:31:12 [TimStarling] we've just been talking about process stuff
2015-06-10 21:31:29 [gwicke] spagewmf: to carry weight, things need to be carefully considered, with input from relevant teams
2015-06-10 21:31:51 [TimStarling] any meeting notes or action items before we move on to ori's RFC?
2015-06-10 21:31:58 [DanielK_WMDE] spagewmf: Thou Shallt Not Use The Global State, For It Is An Abomination!
2015-06-10 21:32:45 [ori] is ready

Create a proper command-line runner for MediaWiki maintenance tasks (phab:T99268)

edit

2015-06-10 21:32:57 [TimStarling] #topic Create a proper command-line runner for MediaWiki maintenance tasks | 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/
2015-06-10 21:33:05 [TimStarling] #link https://phabricator.wikimedia.org/T99268
2015-06-10 21:33:44 [TimStarling] ori: it's not clear what you expect to do about it being a mess
2015-06-10 21:34:05 [TimStarling] it's a mess because nobody has tidied it up for a while
2015-06-10 21:34:08 [TimStarling] right?
2015-06-10 21:34:17 [ori] well, there are some essential design flaws
2015-06-10 21:34:35 [ori] I think the classes which extend Maintenance should be autoloaded by the command-line runner
2015-06-10 21:34:51 [TimStarling] but you want backwards compatibility
2015-06-10 21:34:56 [ori] so that they can implement interfaces that describe functionality and (perhaps) indicate utility
2015-06-10 21:35:12 [TimStarling] would you move the implementation out and just leave a stub in maintenance/?
2015-06-10 21:35:43 [ori] I'm not sure. Open to suggestions.
2015-06-10 21:35:56 [DanielK_WMDE] i think the tricky question is how to enumerate the maintenance commands.
2015-06-10 21:35:58 [ori] On the task I suggested: The top-level entry-point script could then walk the maintenance/ hierarchy and include each PHP file it encounters. It could then iterate on get_declared_classes(), looking for Maintenance subclasses.
2015-06-10 21:36:26 [ori] That's obviously very horrible, but given that command-line invocations are presumably infrequent, maybe that would be OK
2015-06-10 21:36:37 [SMalyshev] it looks like the proposal is going to load all the classes to do that... maybe there's better way for it?
2015-06-10 21:36:39 [DanielK_WMDE] ori: but this would run all top level code. most files should behave well, but do all?
2015-06-10 21:36:42 [DanielK_WMDE] can we rely on that?
2015-06-10 21:36:45 [bd808] there are a zillion 3rd party PHP cli libraries
2015-06-10 21:36:57 [ori] DanielK_WMDE: the previous sentence is: "Because the entry-point script would have to be aware of (and capable of inspecting) Maintenance subclasses, the files in maintenance/ must be audited to ensure they are safe to include (i.e., they have no code with side-effects in file scope)."
2015-06-10 21:37:07 [ori] bd808: yes, that was the other consideration -- there are, and there are some good ones
2015-06-10 21:37:36 [TimStarling] I didn't like the get_declared_classes() proposal
2015-06-10 21:37:37 [jzerebecki] walking maintenance/ doesn't work for extensions
2015-06-10 21:37:51 [TimStarling] I would have a registration interface
2015-06-10 21:37:53 [csteipp] And by "top-level" you mean in the directory root, instead of a subdir, right?
2015-06-10 21:38:06 [TimStarling] maybe like ResourceLoader modules
2015-06-10 21:38:07 [ori] TimStarling: that's obviously the right solution for anything created from here on
2015-06-10 21:38:21 [ori] ("Extensions should be able to register additional subcommands. This could be done by extending the extension.json schema or by providing a hook that extensions can use to register subcommands, similar to the way the UnitTestsList and ResourceLoaderRegisterModules hooks allow extensions to declare unit tests and ResourceLoader modules.")
2015-06-10 21:38:24 [SMalyshev] do we have to load all of those as classes to just list options? can't we load them as text and scan comments or something?
2015-06-10 21:38:29 [DanielK_WMDE] TimStarling: the extension could register classes, callbacks, or just a directory
2015-06-10 21:38:37 [jzerebecki] +1 on registration interface
2015-06-10 21:39:10 [DanielK_WMDE] SMalyshev: we could look for @annotation style tags
2015-06-10 21:39:12 [ori] I mean, a better solution for back-compat would be to roll up our sleeves and port the older scripts to the registration interface we implement / incorporate via composer
2015-06-10 21:39:32 [TimStarling] oh god don't say composer
2015-06-10 21:39:36 [ori] I'd be up for that, but it's a lot for one person, and I wasn't sure if other people felt this was an important thing to do
2015-06-10 21:39:45 [SMalyshev] DanielK_WMDE: exactly, something like that. If some scripts aren't annotated - so they don't show up, if called directly still can be run
2015-06-10 21:39:47 [TimStarling] can't we have one RFC that doesn't discuss composer for half an hour?
2015-06-10 21:39:54 [legoktm] :P
2015-06-10 21:39:57 [ori] c######r
2015-06-10 21:40:01 [bd808] SMalyshev: I was wondering something similar. If we just need class discovery and we aren't worried about speed then we could do some sort of annotation search
2015-06-10 21:40:26 [SMalyshev] grepping 200 files is not that big deal I think... even in php.
2015-06-10 21:40:30 [TimStarling] we have a number of precedents for registration interfaces that you could follow
2015-06-10 21:40:35 [TimStarling] extension.json is the most recent
2015-06-10 21:40:42 [ori] bd808, SMalyshev: that's the sort of code that you end up apologizing for when you on-board new developers
2015-06-10 21:40:49 [TimStarling] ResourceLoader is slightly less recent
2015-06-10 21:41:02 [DanielK_WMDE] ori: i like SMalyshev's idea... maintenance scripts could just have a tag like @mw_cli_class RefreshFooBar in the top comment block.
2015-06-10 21:41:04 [TimStarling] before that -- special pages, query pages, languages, skins
2015-06-10 21:41:15 [bd808] ori: maybe not if you find a maintained lib that already does it, but I do get your point
2015-06-10 21:41:17 [SMalyshev] ori: dunno... not worse than loading 200 files IMHO.
2015-06-10 21:41:27 [DanielK_WMDE] ori: that would tell the runner what classes are in which file, and allows them to be enumerated nicely.
2015-06-10 21:41:49 [jzerebecki] DanielK_WMDE: then scan all files, including extensions?
2015-06-10 21:41:53 [SMalyshev] at least we won't have the tool freak out if someone broke one script
2015-06-10 21:42:00 [TimStarling] I don't think we need to invent a new registration method based on get_declared_classes() when there are so many better precedents to follow
2015-06-10 21:42:09 [DanielK_WMDE] jzerebecki: the maintenance dir, and whatever additional dirs extensions have registered
2015-06-10 21:42:13 [legoktm] I don't like the idea of autodiscovery, an explicit registration system sounds much better
2015-06-10 21:42:15 [DanielK_WMDE] just like with tests
2015-06-10 21:42:27 [ori] I agree that explicit registration is better
2015-06-10 21:42:45 [ori] I raised the autodiscovery question in the context of what to do about the piles and piles of existing maintenance scripts
2015-06-10 21:42:53 [SMalyshev] right, phpunit does stuff like that and it mostly works
2015-06-10 21:42:54 [gwicke] to me it sounds like a lot of the listing and guidance benefit could be had by listing the directory, and post-processing the result
2015-06-10 21:43:09 [gwicke] per-entry-point help would require calling the sub-script
2015-06-10 21:43:22 [ori] Porting each one to the new registration mechanism would be cleaner, but I'm not volunteering for doing that for 150 scripts
2015-06-10 21:43:22 [legoktm] for back-compat, we could continue supporting the Maintenance.php entry point so people still use php fooBar.php, and for newer scripts, they use the new system
2015-06-10 21:43:41 [legoktm] and we'd probably want to keep supporting "php update.php"
2015-06-10 21:43:42 [ori] legoktm: that's not a bad idea
2015-06-10 21:44:07 [DanielK_WMDE] oh hey nice, we could go all fance with token_get_all()
2015-06-10 21:44:15 [DanielK_WMDE] *fancy
2015-06-10 21:44:18 [jzerebecki] SMalyshev: phpunit freaks out if one file breaks, not that I dislike its way...
2015-06-10 21:44:44 [SMalyshev] looking at maintenance, most of them have 1-line description as first line of comment. I bet one could write a script to get it to @annotation or callback() or something...
2015-06-10 21:44:56 [ori] is still not sold on that
2015-06-10 21:44:59 [TimStarling] we don't need to have really high standards for b/c in this case
2015-06-10 21:45:21 [TimStarling] most of the scripts are purely a UI
2015-06-10 21:45:54 [bd808] Drupal uses https://doctrine-common.readthedocs.org/en/latest/reference/annotations.html
2015-06-10 21:46:05 [bd808] to locate plugins
2015-06-10 21:46:09 [TimStarling] my inclination would be to move everything to includes/maintenance and leave stubs behind in maintenance/
2015-06-10 21:46:23 [TimStarling] but don't even bother to commit the stubs for useless old stuff that nobody ever runs
2015-06-10 21:46:28 [DanielK_WMDE] use Doctrine\Common\Annotations\AnnotationReader;
2015-06-10 21:46:29 [gwicke] it sounds like one of the goals is to point out the most important scripts separately; this would require some knowledge about what the important ones are, which could be built into an entry point
2015-06-10 21:46:33 [ori] I don't think grepping files or auto-loading them is optimal, so unless there is a hard back-compat requirement (which there sounds like there isn't) I'm not in favor of that approach
2015-06-10 21:46:48 [SMalyshev] IMHO drupal is overdoing it but we don't need to build an ORM :)
2015-06-10 21:47:03 [ori] An explicit registration would really be better
2015-06-10 21:47:19 [bd808] explicit registration seems like a reasonable idea to me
2015-06-10 21:47:23 [TimStarling] out of 150 scripts, maybe you need 30 b/c stubs
2015-06-10 21:47:23 [DanielK_WMDE] ori: a big json file?
2015-06-10 21:47:38 [spagewmf] FYI 122 extensions/*/maint*/*.php scripts, https://phabricator.wikimedia.org/P759
2015-06-10 21:47:43 [tgr] just load all the files and cache the results? slow on first run, only needs to stat the files after that
2015-06-10 21:48:00 [DanielK_WMDE] spagewmf: tnx
2015-06-10 21:48:08 [SMalyshev] if we have scripts.json with registration, then we could run a script to fill it in with old ones so we don't need to do it manually...
2015-06-10 21:48:19 [ori] OK so for the remaining ten minutes, since it sounds like the back-compat issue isn't big one way or another
2015-06-10 21:48:34 [ori] I'd love to solicit endorsement of any existing CLI frameworks
2015-06-10 21:48:44 [ori] if anyone has experience with any
2015-06-10 21:49:15 [legoktm] we could first start with explicitly registering the current maint scripts and introducing a simple entry point that calls Maintenance::runChild()?
2015-06-10 21:49:19 [ori] and if anyone has a registration mechanism in core that they particularly like, that would be cool too
2015-06-10 21:49:46 [ori] legoktm: for extensions too?
2015-06-10 21:49:50 [TimStarling] I don't know about json as a configuration format
2015-06-10 21:50:04 [bd808] ori: symfony/console is pretty widely used. not sure how aewsome it is
2015-06-10 21:50:30 [legoktm] ori: yeah
2015-06-10 21:50:31 [DanielK_WMDE] ori: well, symphony is all the rage... but i have never used it. looks a bit bloated, but nice https://github.com/symfony/Console
2015-06-10 21:50:37 [TimStarling] Resources.php has lots of comments in it
2015-06-10 21:50:46 [TimStarling] you can't have comments in JSON, I am told
2015-06-10 21:50:58 [DanielK_WMDE] ori: i dislike them all, let's write one that we can then use for everything :)
2015-06-10 21:51:07 [TimStarling] I mean, we discussed this at the start of the extension registration project and I said that we totally can and should have comments in JSON
2015-06-10 21:51:23 [TimStarling] but whatever, I'm now told it's impossible, so we should stop using it
2015-06-10 21:51:27 [tgr] symfony console is quite nice, not sure how much of the framework it drags with itself though
2015-06-10 21:51:29 [bd808] json + comments == yaml
2015-06-10 21:51:51 [ori] we could switch to yaml, the existing json files would be valid
2015-06-10 21:51:55 [TimStarling] json + comments + a hundred pages of parsing pain and idiocy = yaml
2015-06-10 21:52:03 [bd808] :) that too
2015-06-10 21:52:03 [ori] I was going to make the same joke :P
2015-06-10 21:52:03 [DanielK_WMDE] hehehe
2015-06-10 21:52:19 [bd808] but I wrote so many tests! ;)
2015-06-10 21:52:24 [ori] the parsing pain / idiocy doesn't really matter if it's encapsulated in library that is maintained upstream (cough)
2015-06-10 21:52:26 [TimStarling] I had this discussion with yuri at lyon
2015-06-10 21:52:44 [TimStarling] he said "we should use yaml instead of json so that we can put comments in it"
2015-06-10 21:52:55 [SMalyshev] there's https://pecl.php.net/package/yaml but no idea how good
2015-06-10 21:53:04 [ori] SMalyshev: look at the maintainer's name
2015-06-10 21:53:06 [spagewmf] TimStarling: legoktm's extension.json supports "@NOTE": "whatever I want to say", seems a reasonable convention
2015-06-10 21:53:09 [SMalyshev] ahh, I see :)
2015-06-10 21:53:12 [DanielK_WMDE] can we just strip all lines starting with # and be done with it?
2015-06-10 21:53:13 [bd808] oh it's horrible SMalyshev horrible
2015-06-10 21:53:18 [TimStarling] I said: you know, the problem with yaml is that nobody is aware of the fact that you have to put quotes around "yes" to stop it from being a string
2015-06-10 21:53:22 [SMalyshev] sure it's excellent then :)
2015-06-10 21:53:27 [DanielK_WMDE] we could call this dialect json#
2015-06-10 21:53:34 [TimStarling] yuri said: actually I was not aware of that
2015-06-10 21:53:39 [ori] What sort of comments do you envision for extension.json?
2015-06-10 21:53:49 [ori] I think it's pretty minimal right now which is a good thing
2015-06-10 21:53:54 [TimStarling] so I looked for it in the spec
2015-06-10 21:54:10 [ori] if you need to pontificate out loud about the contents of extension.json that's probably a red flag
2015-06-10 21:54:13 [bd808] http://yaml.org/type/bool.html
2015-06-10 21:54:19 [TimStarling] the main spec doesn't mention it, you have to go to the type registry, and then find the boolean type spec
2015-06-10 21:54:25 [ori] that said I added comment support to .dblist files a month ago
2015-06-10 21:54:36 [TimStarling] it's like XML
2015-06-10 21:54:40 [legoktm] it's much easier to add support for comments to extension.json afterwards than it would be to remove support for them after the fact
2015-06-10 21:54:41 [bd808] the yaml spec is a bit of a dog's breakfast
2015-06-10 21:54:56 [TimStarling] actually just use XML, at least we understand what sort of pain we're getting into with XML
2015-06-10 21:54:59 [ori] We should maintain a list of Tim Starling trigger words and forbid them in RFCs. Composer and JSON are primary candidates.
2015-06-10 21:55:02 [SMalyshev] yeah whoever wrote that spec must hate implementers...
2015-06-10 21:55:41 [spagewmf] ori: me? AIUI because LocalSettings.php encourages arbitrary # comments, this is the extension.json equivalent
2015-06-10 21:55:54 [ori] Ok, last question, fuzzy but important:
2015-06-10 21:56:09 [ori] do people share my sense that the current mess is very ugly and worth doing something about?
2015-06-10 21:56:18 [jzerebecki] ori: yes!
2015-06-10 21:56:21 [ori] it'd be good to know if there was a snowball's chance of other people getting involved in a cleanup
2015-06-10 21:56:22 [legoktm] yes
2015-06-10 21:56:25 [ori] even without firm commitments
2015-06-10 21:56:26 [ori] cool
2015-06-10 21:56:40 [gwicke] re config formats: https://github.com/toml-lang/toml has some nice properties
2015-06-10 21:56:55 [gwicke] but, yet another format..
2015-06-10 21:56:59 [TimStarling] if we ever have debian packaging of mediawiki, it would be nice to have a single maintenance script entry point
2015-06-10 21:57:05 [TimStarling] then we can install it into /usr/bin
2015-06-10 21:57:22 [TimStarling] or a wrapper for it, anyway
2015-06-10 21:57:36 [Krenair] like mwscript?
2015-06-10 21:57:41 [Krenair] :P
2015-06-10 21:58:04 [spagewmf] ori: I had a question about "sign-posts to guide the user", how do maintenance scripts say what they do? https://www.mediawiki.org/wiki/Manual:Writing_maintenance_scripts dpesm
2015-06-10 21:58:17 [ori] same way API modules do
2015-06-10 21:58:17 [TimStarling] Krenair: what does mwscript --help do?
2015-06-10 21:58:20 [spagewmf] ... doesn't describe a way to describe what they do
2015-06-10 21:58:34 [ori] by implementing methods that provide information about their purpose and parameters
2015-06-10 21:59:06 [Krenair] tells you off for not providing a wiki database
2015-06-10 21:59:16 [ori] I'm a bit fuzzier on how you determine the subset of subcommands that should be enumerate when the command-line entrypoint is invoked with no arguments (or with --help), like git
2015-06-10 21:59:32 [ori] should it be curated by us, or do we allow subcommands to indicate their own importance?
2015-06-10 21:59:41 [ori] tilts toward curation
2015-06-10 22:00:01 [TimStarling] they should at least have groups
2015-06-10 22:00:11 [ori] oh yeah, groups are a good idea
2015-06-10 22:00:21 [Krenair] yeah
2015-06-10 22:00:22 [aude] waves :)
2015-06-10 22:00:32 [TimStarling] maybe groups and a boolean "advanced" flag
2015-06-10 22:00:43 [TimStarling] which will hide them from the default display
2015-06-10 22:01:01 [ori] that's a good idea too
2015-06-10 22:01:08 [DanielK_WMDE] oh good, flags
2015-06-10 22:01:36 [SMalyshev] yep advanced flag sounds good.
2015-06-10 22:01:41 [DanielK_WMDE] wants "silly" and "ymmv"
2015-06-10 22:01:46 [spagewmf] ori: yeah I see $this->addDescription( 'What it does...'), not in that manual page, and used by very few extension scripts :-/
2015-06-10 22:01:48 [aude] most awesome would be to get rid of phpunit.php as a "maintenance" script and have a proper bootstrap that phpunit + maintenance scripts can use
2015-06-10 22:01:59 [Krenair] where'd we draw the line on 'advanced'?
2015-06-10 22:02:06 [aude] whatever libraries we use...
2015-06-10 22:02:28 [TimStarling] we should wrap up
2015-06-10 22:02:41 [TimStarling] there's obviously a lot more design to do
2015-06-10 22:03:04 [ori] I can update the task with the bits that we agreed on, there seem to be quite a few points which were uncontroversial
2015-06-10 22:03:23 [TimStarling] it sounds like ori and legoktm will collaborate on it
2015-06-10 22:03:42 [legoktm] I uh,
2015-06-10 22:03:43 [spagewmf] ori and legoktm for co-CTO!
2015-06-10 22:03:49 [ori] legoktm: are you volunteering to help? (I would love that)
2015-06-10 22:03:59 [ori] he's only doing a million other things
2015-06-10 22:04:07 [legoktm] I can provide advice, but don't really have much time to dedicate to actually doing things
2015-06-10 22:04:11 [ori] don't answer, i shouldn't put you on the spot
2015-06-10 22:04:14 [ori] yeah that's fine
2015-06-10 22:04:28 [TimStarling] ok
2015-06-10 22:05:10 [TimStarling] well, update the RFC, propose an interface, write to wikitech-l, then maybe we should schedule another meeting
2015-06-10 22:05:20 [ori] sounds good to me
2015-06-10 22:05:45 [ori] will write to wikitech-l.... in JSON
2015-06-10 22:05:52 [TimStarling] lol
2015-06-10 22:06:05 [spagewmf] is script config file in the proposal, or is it just discovery of Maintenance subclasses?
2015-06-10 22:06:12 [DanielK_WMDE] do we have an atom feed for wikitech-l?
2015-06-10 22:06:36 [ori] script config file is not in the proposal
2015-06-10 22:06:40 [legoktm] DanielK_WMDE: of course, gmane :)
2015-06-10 22:06:49 [wm-labs-meetbot] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-10-21.02.txt
2015-06-10 22:06:49 [wm-labs-meetbot] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-10-21.02.html
2015-06-10 22:06:49 [wm-labs-meetbot] Meeting ended Wed Jun 10 22:06:49 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
2015-06-10 22:06:49 [TimStarling] #endmeeting
2015-06-10 22:06:50 [wm-labs-meetbot] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-10-21.02.log.html
2015-06-10 22:06:50 [wm-labs-meetbot] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-10-21.02.wiki
2015-06-10 22:07:05 [ori] thanks for waiting for me guys
2015-06-10 22:07:10 [ori] and thanks for the suggestions
2015-06-10 22:07:16 [spagewmf] ori: WFM, maybe class Maintenance could have addGroup() to group scripts
2015-06-10 22:07:27 [spagewmf] and we promote addDescription() more
2015-06-10 22:08:06 [ori] I'm not sure if class Maintenance could be rehabilitated without badly breaking a ton of scripts that are perhaps not hugely important but should still ideally work
2015-06-10 22:08:31 [ori] using an existing CLI framework and hand-porting the important ones seems better
2015-06-10 22:08:34 [ori] but I gotta run! :)
2015-06-10 22:08:40 [spagewmf] bye, thanks!@
2015-06-10 22:08:42 [aude] slowly replace maintenance with something else :)
2015-06-10 22:08:48 [aude] that maybe has those things
2015-06-10 22:09:14 [aude] thinks it's especially evil that phpunit uses Maintenance.php
2015-06-10 22:11:24 [spagewmf] aude: I just realized Maintenance has ::readConsole() and ::readlineEmulation() 8-)

Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2015-06-10&oldid=1886610"