[13:57:51] Hi, Does there exist an api call to resolve redirects? [14:26:26] Nischayn22, I think there is [17:27:58] New patchset: Hashar; "Update find-entries.php to 2013" [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/49230 [17:28:20] New review: Hashar; "rebased, reapproving." [mediawiki/tools/code-utils] (master) C: 2; - https://gerrit.wikimedia.org/r/49230 [17:28:42] Change merged: jenkins-bot; [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/49230 [17:42:12] Reedy: do we have any document summarizing how we deploy mediawiki on the cluster? [17:42:22] the 2 weeks sprint [17:42:31] with mw.org on first day, then enwiki the day after etc.. [19:21:43] hashar: so....? [21:17:18] New patchset: Platonides; "Accept arbitrarily long lists of dirname() calls" [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/50811 [21:17:19] New patchset: Platonides; "Allow a php shebang" [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/50812 [21:17:19] New patchset: Platonides; "Allow whitelisting additional functions on the command line." [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/50813 [21:24:57] hashar: jenkins probably needs another build host [21:25:07] :( [21:25:12] /it would benefit from having one [21:25:13] yeah https://integration.mediawiki.org/zuul/status [21:25:19] doesn't look in a good shape [21:25:24] too many changes submitted I gues [21:25:46] the parser tests are taking toooo long :-D [21:26:19] hmm [21:26:23] looks Zuul is blocked too [21:27:47] I was just going to ask RobH if there's any spare misc servers we might be able to request [21:27:51] but he's AFK for lunch [21:28:17] I think we have some in EQIAD [21:34:37] I need to get Zuul to reports statistics in graphite :-] [21:34:42] there is build in support for it [21:34:45] have to figure it out [21:42:25] hashar: So for this week: docgen and qunit in production [21:42:27] hashar: deal? [21:42:45] sumanah: https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013#Location :-) [21:45:25] hiya multichill [21:45:47] multichill: Is it in Amsterdam? [21:45:47] :p [21:45:56] Of course it is! [21:46:17] multichill: are there 1-person or 2-person rooms? [21:46:28] New patchset: Zfilipin; "Updated Ruby gems" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/50817 [21:46:29] http://www.stayokay.com/en/hostel/amsterdam-zeeburg [21:46:43] sumanah: Yes, they have those in the hostel [21:47:18] Amsterdam, Texas [21:47:53] Oh cool, it actually exists [21:47:57] Krinkle: hey :) [21:48:09] Krinkle: I have like 30 hours of meeting this week so unlikely :-] [21:48:28] hashar: well, it's taking very long now. I'm getting impatient and I don't know what we're waiting for [21:48:47] there were some things you were talking about we need in zuul, but I'm not buying that [21:48:53] basically: that is a pet project which has low priority :-] [21:48:55] are you saying we can't do any post-merge action? [21:48:58] it will be done "eventually" ;) [21:49:02] Reedy: Next to https://en.wikipedia.org/wiki/Amsterdam_Muiderpoort_railway_station [21:49:07] hashar: low priotities need to be scheduled or they are wontfix. [21:49:20] yeah I need to figure out how to handle the post-merge jobs. I have not tested them in labs yet. [21:49:39] hashar: and no, they are not low priorities. qunit testing is important, and high priority for projects. As important as phpunit for php projects. [21:49:55] Krinkle: wait a sec. [21:50:01] Krinkle: were you referring to quint or doc ? [21:50:06] either [21:50:09] ok [21:50:21] btw, low priority compared to what? I don't see anythign on the cont in plan that has higher priority. we've done everything else. [21:50:24] so to me doc is lowest priority [21:50:40] and quinit definitely need to be scheduled. [21:50:54] qunit, testswarm, browserstack, selenium, documentation. Those are the items I see "todo" in our contint plan. [21:51:04] anything else? [21:51:13] assuming not, that means qunit is now our relative #1 priority. [21:51:20] I agree [21:51:23] New review: Cmcmahon; "maintenance" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/50817 [21:51:23] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/50817 [21:51:27] hashar: good :) [21:51:30] ;] [21:51:50] which in turns need phantom.js to be deployed :) [21:51:57] not really [21:52:23] hashar: not just because we can work around it, but because we should work around it [21:52:34] it is versioned and part of a npm package [21:52:53] so it'll just be like jshint [21:52:56] and grunt [21:52:58] so it could get deployed using integration/jenkins ? [21:52:59] yeah [21:53:02] yep [21:53:07] go ahead so :-] [21:53:10] I already did this last year, you know that right? [21:53:24] it was in gerrit for a month, before it staled beyond rebase [21:53:44] it was working and running on gallium when I tried it temporarily [21:54:03] k, I'll revive it later this week [21:54:38] Krinkle: have you tested out the qunit.localhost stuff ? [21:54:46] I think I amended it a bit [21:54:55] it should be fine but I can't remember its exact status [21:56:00] it would be nice to have quint tests setup by the end of next week [21:56:54] hashar: btw, looks like zuul/gerrit/jenkins is getting mixed up [21:57:03] hashar: https://gerrit.wikimedia.org/r/#/c/50124/ [21:57:57] weird [21:58:16] https://gerrit.wikimedia.org/r/#/c/50124/ [21:58:21] http://integration.mediawiki.org/ci/job/mediawiki-core-phpunit-misc/3047/console : FAILURE [21:58:32] hashar: That jenkins run is failing because of a change that hasn't been merged yet [21:58:46] I suspect jenkins/zuul is commenting on the wrong gerrit change [21:58:54] :-( [21:59:15] the change that caused it is https://gerrit.wikimedia.org/r/#/c/50816/ [21:59:37] "Cannot access private property User::$mRights in" [21:59:47] either it comments on the wrong change or... [21:59:59] hm.. no it also left a comment on the correct change, with a different job id [22:00:16] in that case... what can it be [22:00:23] git clean / git reset not working? [22:00:37] dirty copy [22:01:43] hashar: It is affecting half a dozen other changes as well now https://gerrit.wikimedia.org/r/#/c/50734/ [22:01:58] hashar: I'm not sure how to investigate this, you know more about the local zuul repos [22:02:09] jenkins-bit verified-2 everywhere in core [22:03:48] hold on [22:04:07] I would have to look at what the commit represents [22:04:21] Zuul basically takes the latest master version, merge in the submitted commit [22:04:28] and craft a new commit which is then passed to jenkins [22:05:00] hashar: The breaking change is this: https://gerrit.wikimedia.org/r/#/c/50816/ [22:05:17] hashar: Which was not merged or anything, but some how any change submitted after that is breaking as if that code is in master. [22:05:27] hmm [22:05:33] that should not happen (tm) [22:05:57] fun times :) [22:08:01] even more fun is, how can we be sure that the rest of the tests it does are correct? [22:08:31] team meeting sorry [23:15:28] hashar: btw, any idea why checkstyle reports most of the time don't show the error inline with the code, but instead show this useless "No description available. Please upgrade to latest checkstyle version." message? [23:15:36] I doubt it has anything to do with the version [23:15:39] the data should be right there [23:15:57] just noticed it again in Scribunto, does it does it everywhere https://integration.mediawiki.org/ci/job/mwext-Scribunto-jslint/233/checkstyleResult/file.984307183/type.1174449419/ [23:16:57] Krinkle: no idea, I can't really look at it right now. Would you mind copy pasting the above in a bug report ? :-] [23:17:05] (so it does not get lost) [23:30:41] ^demon: do you have the URL for MzMcBribe gerrit stats ? [23:32:08] http://www.mediawiki.org/wiki/Gerrit/Reports#Reports [23:32:09] ;)D [23:34:01] test