Architecture meetings/RFC review 2015-06-10


 * 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?, 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 (T99268)
 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-)