[00:00:02] you can just merge them for now there, by updating the code with new files... [00:00:06] won't you guys be a bit annoyed if I merge them in on the main site? [00:00:21] not really I think all testing is moving to test2 wiki on prod now [00:00:38] okay [00:00:43] so deployment site is rather for special wikis, like commons etc, so I don't think it really matters [00:01:02] I guess it's going to be merged to wmf1 later anyway, or not? [00:01:25] if so, it should matter in fact it's better to break this site now, than prod later :) [00:02:15] however hexmode is guy who is ruling on deployment beta site, so in worst case he punch you... [00:02:21] yeah [00:02:26] okay fair enough [00:02:33] heh [00:02:36] hexmode: thoughts? [00:03:48] werdna: you intend on committing these core patches soon, right? [00:04:04] hey there... bsitu, kaldari, awjr, TimStarling .... 20% coordination time [00:04:12] robla: yo [00:04:17] robla: Need anything more from me? [00:04:18] ugh so slow [00:04:25] petan: I figure we should move to 1.20 and daily svn up on beta [00:04:26] It's 1am and Roan is asking permission to go to sleep :D [00:04:30] RoanKattouw: I think we're good for now, thanks! [00:04:36] again [00:04:36] thanks RoanKattouw [00:04:38] Yay [00:04:38] robla: you probably want me too, I'm doing 20% tomorrow as well [00:04:55] I'm doing 20% tomorrow, focusing on front-end [00:05:01] any requests? [00:05:16] hexmode: any bug fixes to look at? [00:05:19] hexmode: when you want to move to that [00:05:36] I thought until we deploy we should test this one [00:06:09] wow....the blocker list got bigger: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=91060&resolution=---&target_milestone=1.19wmf%20deployment&known_name=1.19%20deploy%20blockers&query_based_on=1.19%20deploy%20blockers [00:06:35] there's a few there that kaldari could work on [00:07:03] so I go now... :) [00:07:13] sort by id, all but the last ones are bugs [00:07:15] enjoy testing on deployment beta [00:07:18] I already fixed 34424, just awaiting deployment [00:07:24] petan: see pm [00:07:44] which one [00:07:50] I don't see any pm from you [00:07:51] robla: the current fundraising team is completely snowed under at the moment for a large variety of reasons and could use some help with code review. any problem with me cashing in some 20% time to help them out? [00:07:56] I'll try to take a look at some of the JS ones as well [00:08:01] petan: just now [00:08:28] k...thanks [00:08:40] awjr: we're pretty snowed under too with 1.19 [00:08:44] I could do bug 34421 (duplicate email headers) [00:09:14] robla: which bug do you want me to look at [00:10:05] bsitu: https://bugzilla.wikimedia.org/show_bug.cgi?id=34431 might be a good one [00:10:14] I'm not sure it's truly high priority [00:10:23] robla: ok, but i'm not super familiar with core. i don't mind helping out with 1.19 code review (and getting more familiar with core), but i'm not sure it's the best use of my time. [00:12:53] bsitu: that one doesn't look like it needs a lot of familiarity with core [00:13:07] I'll be around if you need help [00:13:25] thx [00:13:46] Is that a regression in 1.19? [00:13:49] *RoanKattouw is skeptical [00:14:24] What do you need from me robla? [00:14:46] RoanKattouw: which one are you asking about? [00:14:53] (and why aren't you in bed?) [00:14:59] werdna: there are some new FIXMEs [00:15:02] "Old edit toolbar flashes before new one appears" [00:15:05] werdna: love and attention? [00:15:30] *AaronSchulz trolls the BZ [00:15:31] there's also 223 new revisions [00:16:09] 223? gasp [00:16:31] but maybe we should find some LiquidThreads bugs for werdna to fix [00:16:51] werdna said he fixed those last week :P [00:16:57] all of them :p [00:17:03] all? [00:17:09] I did one or two, but mostly I just went through patches and applied them [00:17:20] there aren't any patches pending against any of my extensions anymore, which is nice. [00:17:51] that's funny, because if I search for unresolved LQT bugs I get 203 results [00:18:08] Yes, I think hexmode misunderstood me [00:18:13] yeah, I think I remember it being just patches [00:18:21] *hexmode sighs [00:18:36] werdna: my sig bug is SUPER important [00:18:39] :) [00:18:46] If robla really does need that much work on 1.19 then I don't think LQT bugs are the most important thing for me to work on. [00:19:32] the review backlog is looking pretty awful, isn't it [00:19:49] werdna: could you poke at the fixmes here: https://www.mediawiki.org/wiki/MediaWiki_roadmap/1.19/Revision_report [00:19:56] we use LQT on lots of big wikis [00:20:00] http://toolserver.org/~robla/crstats/ [00:20:14] so if there are any regressions in it due to 1.19 changes then we should look at those [00:20:59] geez, robla. if people keep that up we're gonna have a real hole [00:21:36] basically, we'll have throw away a bunch of code checked into trunk on the migration to Git [00:21:55] ....and let people resubmit via gerrit [00:22:03] +1 [00:22:05] well, do you want help with that? [00:22:12] werdna: that would be useful [00:22:31] of course that assumes there aren't any lqt regressions [00:22:36] if there are regressions then I should work on those [00:22:37] awjr: that would be useful for you too ^ [00:23:05] robla: so, any deployments today? [00:23:15] AaronSchulz: Reedy already did them [00:23:30] robla: you mean re LQT? [00:23:36] werdna: we've only done small wikis and I don't think anyone reported LQT bugs... I'm almost finished w/ my VP tour [00:24:04] awjr: no, helping us keep on top of code review while 1.19 deploy is happening so that we don't have to ask people to resubmit their code [00:24:12] *hexmode likes how "Village Pump" abbreviates [00:25:06] awjr: we're not planning to migrate unreviewed code....which means either reviewing it all, or picking a cutoff that we can review up to [00:25:11] robla: sure thing - what do you mean though by "so that we don't have to ask people to resubmit their code"? i think i need some more context [00:25:18] ah ok [00:25:50] (see my mail to wikitech-l last week on the code slush subject) [00:27:31] now that Roan is gone, I can say he's wrong ;-) [00:27:56] maybe he had a second irc nick in here [00:28:10] *AaronSchulz should try that sometime [00:28:21] I just double checked the 34431 is a regression [00:28:22] robla: wrong about what? [00:28:26] ah [00:29:53] I'm not *positive* about it, but it's pretty easy to repro on 1.19 wikis, and I haven't seen it on 1.18 [00:30:11] I'm willing to believe it's lower priority, though [00:30:41] did we leave anyone off the list? [00:38:57] *robla ducks into meeting [00:46:18] binasher: why is graphite mixing a crapton of data for a few hours? [00:46:34] mixing? [00:46:38] lol, missing [00:46:41] oh [00:46:46] because 1.19 broke it :) [00:47:44] parser::braceexpand-title or something like that profiles with the article title name added to the profile key [00:49:06] profiler-to-carbon bombed on encoding issues with the article names and what goes in to the c collector doesn't always seem to be valid unicode or utf-8 [00:49:22] i fixed by having it skip those [00:53:18] binasher: how hacky is the fix? [00:53:34] like, if new profile names are added like this, will it still explode [00:53:36] ? [00:54:04] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111694 [00:54:13] the ones that explode will just get skipped over [00:55:20] re: the skip regex in there, that's just to avoid that profile type from going in on names that are just ascii [00:56:23] hrm, ok [00:56:31] i think there's a better way to handle the bad characters, but then again, creating graphs per article across all wikis would kill the whole thing anyways [00:57:12] probably no way around that [00:58:00] a massive cluster to make pretty graphs! [00:59:19] binasher: we need a distributed graph cluster that makes 3D holographic graphs [00:59:21] but yeah.. if anyone adds a profileIn that includes something like article names, a matching regex should be added to skips[ ] to avoid overloading things [00:59:38] now how do you get people to remember that? [01:00:00] AaronSchulz: make sure everyone remembers that [01:00:01] why is graphite password-protected? [01:00:03] there [01:00:26] binasher: ok, Mr Feynman [01:00:45] because it offers no security around editing or deleting dashboards [01:00:55] and we should all have a labs account [01:01:12] i'm in the midst of putting together a public thingy [01:03:13] no CSRF protection? [01:04:13] hrm, well, apache basic auth seemed better than nothing [02:06:18] is howie still at the office? [02:11:01] yep [02:15:00] i was interested in his thoughts on the guy he interviewed. [09:37:26] anyone using git+eclipse [09:54:15] I got problems cloning MWDumper any suggestions [11:40:03] gwicke, around? [11:40:16] guillom: yep [11:42:30] gwicke, hi! Quick question: would it be ok to move the Parsoid todo list to a subpage? 2 reasons: 1. The project pages were originally intended to be high-level overviews of a project, linking to more details in dedicated pages, and 2. The line you added about and templates actually breaks the page where it's transcluded :) (The whole page is in a noinclude, and the closing tag you added messes it up) [11:43:52] guillom: that is ok with me [11:44:02] gwicke, ok, great. Mind if I do it now? [11:44:20] the section id should still work though, as it is published already in a few places [11:44:27] can just have the link though [11:44:35] sure, no problem [11:44:40] Thank you! [11:45:04] you can go ahead [11:45:13] I just saved my last outstanding change [11:45:18] ok, thanks :) [11:48:40] done [11:51:09] moved the high-level status block before the todo as well [11:51:35] looks nice and clean now without the gritty technical detail out of the way ;) [11:52:09] *with it out of the way* [11:56:02] :) [12:32:35] what's the url for read only access to git ? e.g. ssh://oren@gerrit.wikimedia.org/mediawiki/tools/mwdumper.git ?? [13:50:36] could someone look at a js problem on simple? I've confirmed their gadget is acting weird, but it appears to be 1.19's fault. [13:51:21] https://simple.wikipedia.org/wiki/Wikipedia:Simple_talk#Issues_with_Navigation_Popups.3F [13:55:04] guillom: I was talking with some peeps about a village pump task force made up of volunters and robla said I should talk to you [13:55:20] Reedy: ^^ could you look at the js problem on simple? [13:57:23] hexmode, well, you're talking to me. Now, how about you be more specific and tell me what you need from me :) [13:57:39] heh [13:58:10] guillom: ok, so I also spoke with Ironholds about this and got his input [13:59:17] basically, I'd like to set up relationships with people on different projects and get them to report any problems from village pumps, etc to a central place on (probably) meta [14:00:10] hexmode, sounds good. This sounds like an initiative similar to the "wikitech-ambassadors" mailing list; you could probably merge / consolidate the two. [14:00:36] Ironholds said I should talk to Phillippe and Maggie so this doesn't just end up as another "hey, great idea!" that some staffer comes up with [14:01:22] guillom: yeah, sumanah said the same thing about wikitech-ambassadors. maybe I should go there first to find people? [14:01:47] I think there's an opportunity for consolidating this and bringing people together so it doesn't become, as you say, "yet another great idea" [14:02:16] remember, guillom is task-oriented and hexmode is people-oriented here :-) [14:02:34] thank you for not talking past each other :D [14:02:54] hi sumanah [14:02:57] hi guillom [14:03:09] sumanah, mind if I pm? I was about to send you an e-mail, but since you're around... [14:03:21] sure! [14:03:21] sumanah: ? really? I hadn't made the task/people distinction, but it makes sense :) [14:05:20] guillom: so my goal here is to get people to bubble reports up sooner so we don't alienate people and leave their problems un-addressed. Sounds like the next step is to write something up to send to Wikitech-l and give it to you to review. k? [14:06:21] <^demon> hexmode: I found a possible 1.19 regression, see #mediawiki. [14:08:50] hexmode, I'd say, Just Do It. Set up the page on meta, reach out to the ambassadors list, in a word, just set it up, *then* reach out to people to join it. [14:09:04] This is just my ???0.2. [14:11:15] guillom: thanks for you for your $0.26314 ... just what I needed :) [14:11:49] np :) [14:13:43] ^demon: looks like you introduced the TESTWIKI define with WikiMaintenance extension [14:14:22] and it is used in WMF LocalSettings.php to switch between /home/wikipedia commont settings and the local one [14:14:55] <^demon> Ha, whoops [14:14:57] but somehow /home/wikipedia is not available on apache, that generates a ton of warnings in the syslog [14:15:03] so something must be broken :D [14:15:37] tail -f /home/wikipedia/syslog/syslog | grep 'PHP Warning' [14:17:36] ^demon: what's the url for read only access to git ? e.g. ssh://oren@gerrit.wikimedia.org/mediawiki/tools/mwdumper.git ?? [14:17:51] <^demon> That's the read/write. [14:18:04] I need a read only for jenkins [14:18:08] <^demon> Read only is https://gerrit.wikimedia.org/r/p/mediawiki/tools/mwdumper.git [14:21:21] ^demon: do you have any idea about the error referenced above ? ( include_once(/home/wikipedia/common/wmf-config/CommonSettings.php): failed to open stream ) [14:21:47] do we know where the line is? [14:21:56] it is from php-1.19/LocalSettings.php [14:22:22] an if( defined('TESTWIKI') ) {} let you switch between /home/wikipedia and /usr/local/apache to load CommonSettings.php [14:22:33] I can't say I've ever looked in our LocalSettings.php :p [14:22:36] the only place I have found the TESTWIKI define is in the WikimediaMaintenance extension [14:24:06] what is confusing me is that TESTWIKI should thus only be defined for requests on the test wikipedia [14:24:22] and it probably does not have that many requests [14:32:05] ^demon: thanks! [14:32:12] <^demon> yw [14:38:52] ^demon I've not been able to get git to work properly with our repository - should I open a bug or can we check some things? [14:39:06] <^demon> What's going wrong? [14:41:40] I get when I tries to get the remote branches I get : Exception caught during execution of ls-remote command [14:42:11] <^demon> Let me do an anonymous clone and see. [14:42:11] this happens when I try to import mwdumper into eclipse [14:42:44] yeah for PHP $argv does hold the script name :-D [14:43:10] any idea which script could have the following args: --wiki=testwiki, --procs=5, --maxtime=300 ? :-D [14:43:25] <^demon> Probably runJobs.php? [14:43:30] <^demon> --procs is runjobs iirc. [14:43:34] probably [14:44:22] and every time one is run on apache for testwiki, it emits an error since /home/wikipedia is not mounted [14:44:33] need to exclude testwiki from the runjobs I guess [14:46:52] mwdumper is now a bit broken [14:47:10] the packinging needs to be modified asap [14:50:32] <^demon> OrenOf: http://p.defau.lt/?kNM9MvgLUagX1MEcQXL_oQ [14:52:43] Dantman: ping [15:02:24] Reedy: ping [15:02:49] ohai [15:03:17] yeah no more php spam in syslog conf :-))))) [15:03:26] Reedy: what do you think of doing something like this http://pastebin.mozilla.org/1486287 in order to get rid of the need for output buffering in mobile frontend [15:03:53] ^demon: I have added a hack to have job runners load CommonSettings.php from the apache directory instead of /home/wikipedia [15:03:59] hashar: have you noticed most of the reported fatals are in 1.18? ;) [15:04:05] ^demon: that removed the spam :D [15:04:58] Reedy: that was in 1.19 [15:05:15] Feb 17 14:20:58 10.0.11.49 php: PHP Warning: include_once(): Failed opening '/home/wikipedia/common/wmf-config/CommonSettings.php' for inclusion (include_path='.:/usr/share/php:/usr/local/apache/common/php') in /usr/local/apache/common-local/php-1.19/LocalSettings.php on line 4 [15:05:25] I know [15:05:30] But I'm meaning most of the other errors [15:05:47] the one related to some cache? [15:05:55] seems Roan cleared the cache [15:07:31] Reedy: thoughts? [15:09:03] Reedy: also, are you going to http://www.phpconference.co.uk/ ? [15:15:04] WordPress.com is an Alexa Top 20 web website, we get more than 100 million page views per day and 99% of the backend is PHP. [15:15:14] 20 seconds deploy on a thousand servers, tens times per day [15:15:14] lol [15:15:45] <^demon> A thousand servers? [15:15:46] <^demon> lol [15:16:52] preilly: no I'm not, didn't even know of it's existance... [15:21:37] Reedy: you still around? [15:22:48] Yeah, just doing numerous things [15:22:49] [15:17:25] preilly: no I'm not, didn't even know of it's existance... [15:23:03] Reedy: ah, I see [15:23:31] Reedy: when you get a spare cycle or two can you take a look at the paste bin link that I sent http://pastebin.mozilla.org/1486287 [15:23:52] Yeah, I will do [15:40:34] hi siebrand do you have a minute to help double-check something with me? https://bugzilla.wikimedia.org/show_bug.cgi?id=33762 [15:48:16] chrismcmahon: checking. [15:48:30] chrismcmahon: what about it? it's verified fixed... [15:48:46] siebrand: that ticket says it should be in 1.19 but I find no evidence that it is. [15:49:21] chrismcmahon: at the time of writing of that comment, MediaWiki 1.19 had not yet been branched, and was MediaWiki 1.19 alpha. [15:49:33] chrismcmahon: you've going versioning mixed up I think ;) [15:49:45] going = got [15:50:31] chrismcmahon: MediaWiki 1.19 was branched after r110105 (in which the issue was fixed), so in 1.19 the issue will not be present. [15:50:41] !1.19 [15:50:41] --elephant-- I don't know anything about "1.19". [15:50:48] !1.18 [15:50:48] --elephant-- I don't know anything about "1.18". [15:50:59] sumanah: elephant is stupid ;) [15:51:27] chrismcmahon: anyway, see https://translatewiki.net/wiki/MediaWiki:Uncategorizedpages-summary [15:51:46] chrismcmahon: and https://translatewiki.net/wiki/Special:Uncategorizedpages [15:52:07] chrismcmahon: oops, second link should be https://translatewiki.net/wiki/Special:UncategorizedPages?uselang=en [15:52:38] chrismcmahon: all clear or need more explanation to clear up the confusion? [15:52:44] (ask for a few mins). [15:52:47] afk... [15:53:57] siebrand: thanks, the 1.19 release notes were confusing about that, I'm updating some documentation. [17:12:46] Dantman: ping [17:29:16] hi folks [17:29:17] http://www.mediawiki.org/wiki/MediaWiki_1.19/Revision_report [17:30:24] looks like we're having a tough time finishing up old review, and we're also building up a backlog of stuff to review [17:32:14] gwicke: Reedy: you around? [17:33:05] *gwicke considers to hide somewhere [17:33:18] Ya [17:33:34] :) [17:34:20] is Amir's IRC nick obvious? [17:34:32] amire80 or something iirc [17:35:02] ok...reasonably obvious then. he's just not around right now [17:35:31] anyway, Reedy, you've probably got about as good a grasp on what's needed for code review as anyone [17:35:42] when I emailed him yesteday he appeared within 10 minutes on ircx [17:36:09] robla: is there anything parserish in there? [17:36:49] Reedy: how much of the unreviewed stuff tagged 1.19 is already deployed? http://www.mediawiki.org/wiki/MediaWiki_1.19/Revision_report [17:38:04] I'll have a look in a few minutes [17:39:06] gwicke: this is sorta parserish http://www.mediawiki.org/wiki/Special:Code/MediaWiki/109678 [17:39:17] it's OutputPage [17:39:24] robla, hi; got a minute? [17:39:25] (granted, that's a stretch) [17:39:43] robla: ok, will have a look [17:39:46] guillom: let me wrap up this IRC mtg, and then I will [17:39:50] sure [17:42:25] hrm....I realize now this is the one irc meeting I didn't properly put into the cal [17:42:40] *robla resolves to fix this before next week [17:42:43] guillom: what's up? [17:43:14] robla, 2 things. First, I wanted to touch base with you regarding the 1.19 comms, and check that everything was going well. [17:43:32] And second, just wanted to make sure you had seen that watchlist bug [17:43:55] *gwicke wades into revert-of-a-revert-of-a-revert code review [17:43:57] re #1, I think so...I do owe another email to wikitech-l about what we've done [17:44:38] re #2....the watchlist bug isn't ringing a bell [17:44:47] have the bug number handy? [17:45:00] yup, was looking for it [17:45:01] https://bugzilla.wikimedia.org/show_bug.cgi?id=34469 [17:45:10] looks like a 1.19 bug [17:46:25] robla: none of them AFAIK [17:47:26] gah....34469 looks bad [17:48:13] Krinkle isn't around, is he? [17:48:25] I think he's on vacation. Not sure. [17:49:12] ^ yup [17:49:18] Reedy: any idea how to fix 34469? [18:00:18] robla: it is quite hard to estimate the potential problems 109678 might cause for extensions, I think Tim and Nikerabbit (who already commented) are in a better position to do so with reasonable time investment [18:01:42] gwicke: could you comment on the revision? even a note saying that it's difficult to know how much trouble it will be would be helpful [18:02:01] robla: ok, will leave a note [18:02:34] also, we can't defer to Tim on everything. this seems to be a common theme when I ask people to review stuff outside their comfort zone [18:10:40] ^demon: sorry, need to move Monday meeting. [18:10:45] *sumanah sends revised invite [18:11:57] robla: it does not make too much sense to guess a review though [18:13:10] api changes are especially tricky, as few people actually have a good idea of which things might be affected [18:13:10] ^demon: OH DUH Monday is Presidents' Day and we shouldn't be working at all! [18:16:39] werdna? [18:23:40] gwicke: that's probably a good reason for us to be conservative and revert. I know you probably don't want to be the one to actually revert, but it's good to at least encourage conservatism in this area [18:24:39] jorm? [18:24:54] i'm trying to get ACW running on my local wiki but, uh, it isn't. [18:25:23] gwicke: one of our biggest problems in code review right now is that most folks tend to default to "I don't understand this, therefore I'll leave it to others", rather than "I don't understand this, and I'm reasonably smart, so I'll revert until I'm convinced this is well thought through". [18:25:48] gwicke: but that's a meta problem. i don't want to push you into a revert war on this particular issue... I think you've done enough on this. thanks! [18:25:49] jorm: you'll need to disable the bucketing [18:25:59] how is that done? [18:25:59] $wgArticleCreationBucketConfig['buckets']['off'] = 0; [18:26:11] robla: I agree with your assessment [18:26:29] things simply become harder with size [18:26:53] hrm. no love with that. [18:27:08] robla: I definitely do that. I don't feel comfortable reviewing every single revision. [18:27:19] especially since there are a lot of revs that are just outside my area [18:27:26] i.e. API, resource loader, parser, etc [18:27:37] that's part of why we pretty much need to switch to pre-commit review [18:27:55] right, exactly [18:28:02] so the problem will fix itself in 2 weeks [18:28:04] robla: and the many existing APIs for extensions combined with their large number don't help either [18:28:08] just need to get this latest batch of stuff done :) [18:28:28] ah. i had a cookie set. [18:28:52] I think people believe I'm bluffing when I say we are going to cut over to git at some point before the latest rev in svn [18:29:07] werdna: also this is why I hope we are going to train more people in code review on various areas where they want to get better [18:29:44] if we have a huge review backlog, though, it's going to be tough to justify just lobbing everything into git or waiting until we're back to "zero" [18:29:51] i'm getting the buttons but not the flyouts. [18:29:57] *werdna hates reviewing code, feels like he's bad at it. [18:30:04] jorm: I think kaldari was doing some stuff [18:30:07] hold on [18:30:21] summoned him [18:30:36] i also have code to review from him. [18:30:47] yeah [18:31:03] remember the flyouts only come up on 'create this page', which will only appear if you're logged in [18:31:10] imo the reviewing is the easy part if you already know the area a patch might affect [18:31:48] but there are a few areas where the consequences are very hard to judge [18:31:57] oh. there's a flyout on "create this page myself" but not on anything else. [18:32:11] jorm: also, it won't work if your core code isn't updated since it depends on Benny's hook [18:32:18] not so for me. I find that I can sometimes miss unexpected consequences, along with the general feeling of "maybe I just don't understand what they're trying to do" [18:32:27] jorm: this is by design, unless you want to provide flyouts for the others [18:32:31] i updated everything; i'm running 1.20a [18:32:42] there were supposed to be, i thought. [18:32:46] if you want to add flyouts, you can stick them into the $wgArticleCreationButtons array. [18:32:58] jorm: well, I haven't been given any yet, so there aren't any. They're easy to add, though [18:33:03] no worries. [18:33:09] and make sure your 'on' bucket is set to 100 [18:33:15] doesn't matter what it's set to [18:33:22] so long as off is 0 [18:33:28] werdna: "I don't understand what you're trying to do with foo" is a perfectly valid comment, right? [18:33:30] kaldari: do you have an easy place i can demo that code you want reviewed? [18:33:47] sort of... [18:34:06] sumanah: yes yes, I'm not always as comfortable deciding on the worth of somebody else's work though [18:34:08] if you get ACW working you can just change the class on the buttons to look at all of them... [18:34:19] unless I'm *really* sure.. [18:34:24] otherwise, I can set up a demo page that has them all for you to look at [18:35:06] the classes as ui-button-green, ui-button-green-large, ui-button-blue, ui-button-blue-large, etc. [18:35:19] werdna: is there any way https://www.mediawiki.org/wiki/Code_review_guide could be improved to help your confidence in this area? [18:35:31] k. [18:35:36] werdna: like "it's fine to ask questions and does not imply the work is bad" :) [18:36:13] werdna, kaldari, have you guys looked at Echo? [18:36:27] right now it doesn't say anything about the *conversational* and *learning* aspects of review [18:36:40] what's Echo? [18:36:42] Echo [18:36:43] Echo [18:37:14] sumanah: I'm not quite sure that I can properly articulate my problem here [18:37:19] http://www.mediawiki.org/wiki/Echo_(Notifications) [18:37:20] because that's not quite it [18:37:33] so, i'm about to start a dive on Zoom/NPT. [18:37:52] and i do not believe that we're going to get much value out of Zoom without a revamped notifications system. [18:37:55] s/revamped //; [18:38:13] now, ideally, Echo works across all wikis. [18:38:25] But let's restrain ourselves to only thinking about one wiki. [18:38:31] and if it is possible at al.. [18:38:32] werdna: you may be interested in skimming https://www.mediawiki.org/wiki/User:Sumanah/Launchpad-dev-process which describes a team that tries to mentor every developer into a code reviewer. Also every commit, along with a commit summary, has to have a "merge proposal" that's more detailed [18:38:36] all. [18:39:16] "I don't always test my code. But when I do, it's in production." [18:39:50] Zoom, jorm? [18:40:19] that's the code name for this: http://www.mediawiki.org/wiki/New_Page_Triage [18:41:02] It seems like Echo would be complimentary to NPT, but I don't see how it would limit NPT without it [18:41:26] sumanah: the problem I see with code review is that you need a lot of background knowledge to judge the harder changes [18:41:55] Of course [18:42:05] and large projects with underdefined internal apis tend to be especially hard [18:42:52] it is complimentary. [18:43:11] npt will work without it but the big value we'll get from npt is notifying users that their shit just got wrecked, basically. [18:43:22] true [18:43:41] gwicke: my thinking is, if I can help increase the # of people who are comfortable doing code review *at all* then it'll be helpful and possibly reduce load on the people who know particularly twisted sub-codebases [18:44:28] gwicke: and at first it would be a beachhead sort of strategy [18:44:51] "here, you are interested in $extension, would you like to be a code reviewer/project owner for it?" [18:44:56] sounds reasonable [18:45:20] (three months of learning/training later): "so, that went well, how would you feel about also getting that status for that other thing you care about?" [18:45:28] reducing scopes of changes with better apis and maintainer teams might also help [18:46:46] gwicke: examples will help me think about what you are suggesting [18:47:35] nobody can review changes to unstructured spaghetti if it gets to a certain size [18:47:44] gwicke: yes. [18:47:45] everybody can know only so much code [18:47:53] gwicke: also no one can properly unit test spaghetti code. [18:47:59] so refactoring is important for both those goals [18:48:26] so apis and modules help people to focus on parts, and be sure that some change won't affect anything else as long as the api behavior does not change [18:48:45] does anyone working in Mediawiki code do pair programming? I haven't heard the term used. [18:49:00] gwicke: https://www.mediawiki.org/wiki/User:Sumanah/Launchpad-dev-process might also interest you in case you want to implement any bits of it in your team [18:49:07] chrismcmahon: Trevor and Inez do, a bit [18:49:27] chrismcmahon: and I think Ian and Neil did, when Neil was with WMF [18:49:34] but overall, I think it only happens ad hoc at hackathons. [18:49:36] and stuff like that. [18:51:25] sumanah: thanks, reading.. [18:58:20]