[00:07:07] <AaronSchulz>	 TimStarling: https://gerrit.wikimedia.org/r/#/c/35836/ is some cleanup
[00:10:52] <kaldari>	 chrismcmahon: We have the new CSS in place on all the non-English wikis now
[00:11:11] <kaldari>	 which should minimize the server cache problems tomorrow
[00:11:33] <chrismcmahon>	 thanks kaldari and sorry for the hassle
[00:11:50] <kaldari>	 I wouldn't be surprised if a few people still have the problem though
[00:12:28] <preilly>	 AaronSchulz: thanks Aaron
[00:12:34] <preilly>	 AaronSchulz: for the sandbox/aaron/rdbstore comment
[00:36:31] <kaldari>	 chrismcmahon: I still think we should keep an eye on things tomorrow. I think there's some underlying problem here that is still unresolved. I've heard reports of similar problems from arthur, matthias, and mattwalker within the past week, all totally unrelated to the <h3> bug
[00:37:07] <chrismcmahon>	 kaldari: understood.  I saw Arthur's comment.
[00:39:44] <kaldari>	 chrismcmahon: if we hear any reports of bug 42452 from the non-English wikis tomorrow, we'll know there's a bigger problem.
[01:17:56] <gerrit-wm>	 New patchset: Stefan.petrea; "Moved message to debug mode" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/36944
[02:29:05] <spagewmf>	 how can I know in JavaScript if the user can successfully edit the current page?  (mwEditButtons is empty, wgRestrictionEdit is an array of protections indirectly related to what the user can do).
[02:31:32] <kaldari>	 you can pass it as a global with ResourceLoaderGetConfigVars hook
[02:31:47] <kaldari>	 but lemme see if there's a better way...
[02:33:07] <spagewmf>	 kaldari, yes but pass what?  I could probably work from wgRestrictionEdit and the user's rights to infer whether they can edit, but I was hoping for userCanEditCurrentPage
[02:33:41] <kaldari>	 on the server side there's quickUserCan()
[02:33:45] <kaldari>	 or something like that
[02:34:26] <kaldari>	 meh, that's not the name of it...
[02:35:20] <spagewmf>	 I think there's a $this->getTitle()->quickUserCan( 'edit' )
[02:35:22] <spagewmf>	 perfect
[02:35:38] <kaldari>	 ah cool
[02:35:41] <kaldari>	 I was looking in User
[02:35:43] <kaldari>	 wrong place
[02:37:41] <kaldari>	 I can't find anything better on the client-side :(
[02:38:05] <spagewmf>	 "May provide false positives, but should never provide a false negative." probably because it calls userCan with $doExpensiveQueries=false.
[02:38:36] <kaldari>	 I wouldn't think an edit check would be expensive
[02:38:50] <kaldari>	 but I'm not 100% sure
[02:39:50] <kaldari>	 I tried adding a unit test in core and it seems to have broken the jenkins build: https://gerrit.wikimedia.org/r/#/c/35419
[02:39:51] <spagewmf>	 I wonder if the skin showing an Edit tab vs View source is the expensive query or the quick one.
[02:39:54] <kaldari>	 I'm not sure why though
[02:40:40] <kaldari>	 who's the expert in unit tests?
[02:40:52] <spagewmf>	 Click [Edit], cluster does advanced AI for 25 seconds... "I'm afraid I can't do that. Dave"
[02:41:10] <kaldari>	 :)
[02:41:12] <spagewmf>	 kaldari, hashar seems pretty expert on phpunit, krinkle on qunit
[02:41:24] <kaldari>	 thanks
[02:41:34] <kaldari>	 looks like hashar's AWOL :(
[02:43:27] <spagewmf>	 kaldari, looking at the Console Ouptut link in Jenkins, it seems it can't auto-merge your tests, so that failed CONFLICT (content): Merge conflict in tests/phpunit/languages/LanguageTest.php
[02:43:47] <kaldari>	 weird
[02:44:47] <kaldari>	 I'll try rebasing
[02:45:04] <spagewmf>	 Looks like Jenkins resets master hard, then fetches the change, then "Auto-merges".
[02:45:10] <kaldari>	 ooh, you're right
[02:45:32] <kaldari>	 someone else was also writing language unit tests!
[02:45:40] <kaldari>	 madness!
[02:48:49] <kaldari>	 spagewmf: that fixed it, thanks!
[09:13:51] <hashar>	 Krinkle: thanks for your feedbacks :-)
[09:14:54] <Krinkle>	 hashar: yw, have you looked into using 1 job per pipeline per repo ?
[09:15:25] <Krinkle>	 also, we can start using phplint from grunt now I think.
[09:15:43] <Krinkle>	 so -lint would be just grunt jshint phplint (test first, not sure)
[09:16:13] <hashar>	 I tried the 1job per repo but if the last step of the build fail you end up with a huuuuge console to analyze
[09:16:30] <hashar>	 so instead I have split the changes to fail early and offer a short but meaningful console output to the users
[09:16:42] <Krinkle>	 hashar: that isn't a problem. 1) it has anchors, 2) we shouldn't be using console output directly in most cases anyway
[09:16:42] <hashar>	 has for jslint jobs, I want them to be part of the lint job ulitmately
[09:16:55] <hashar>	 but some repository do not pass jshint yet
[09:17:09] <Krinkle>	 well, then don't make those executions fail the main build
[09:17:12] <Krinkle>	 we've been over this
[09:17:24] <Krinkle>	 it is insane to make a separate job just to make use of the status aggregation and/or ignore.
[09:17:38] <hashar>	 now jslint does not vote, but I can make it voting for extensions we know we want jshint to keep passing
[09:17:55] <Krinkle>	 for visualeditor it should be voting, we're relying on that now.
[09:18:23] <Krinkle>	 but it appears to be getting crazier. now php lint and jshint are separate jobs too?
[09:18:33] <Krinkle>	 I don't want to open 5 tabs just to know all the failures.
[09:18:46] <Krinkle>	 if it is too much output, don't output so much :P
[09:18:52] <hashar>	 ;-]]]]
[09:19:00] <Krinkle>	 and for most failures we don't have to open the console, it genreates graphs and tables
[09:19:02] <Krinkle>	 such as phpunit
[09:19:08] <Krinkle>	 (which is the most important one anyway)
[09:19:26] <Krinkle>	 only merge conflcits go exclusively into console, which are always at the start
[09:19:31] <Krinkle>	 (and lint, which is also only at the start)
[09:20:02] <Krinkle>	 either way, this wasn't a problem before using Zuul, so if that's the only reason, then that seems a bit unjustified
[09:20:17] <Krinkle>	 its been that way for over a year
[09:20:42] <Krinkle>	 now there's a lot of duplication and workspace mess to deal with, I have 0 clue on jenkins now, everything is no where.
[09:22:39] <gerrit-wm>	 New patchset: Hashar; "mwext-VisualEditor-jslint now voting" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36959
[09:22:48] <hashar>	 Krinkle: here is the voting job :-]
[09:22:51] <hashar>	 will have to test it out though
[09:22:58] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36959
[09:23:49] <Krinkle>	 hashar: also don't forget to make it passing on core
[09:23:52] <Krinkle>	 voting*
[09:24:21] <Krinkle>	 (later when you make Zuul primary for gerrit/jenkins on mediawiki-core)
[09:24:26] <Krinkle>	 it is't yet, right?
[09:24:37] <hashar>	 Krinkle: it is voting now : https://gerrit.wikimedia.org/r/#/c/36739/  :-]
[09:24:48] <hashar>	 (^^^  faulty change made against Visual Editor)
[09:25:33] <Krinkle>	 ok
[09:25:46] <Krinkle>	 hashar: you created the JENKINS file
[09:25:55] <Krinkle>	 or is that something else ?
[09:26:04] <hashar>	 I created it
[09:26:20] <hashar>	 the failure is an edit under  the modules/ve/ve.Surface.js  which add  var foo = bar
[09:26:49] <hashar>	 I sent a PS3 fixing it, jslint  pass and that got verified 0
[09:31:46] <Krinkle>	 hashar: so where's the vote?
[09:32:26] <Krinkle>	 (V1 I mean, since we don't have tests on ve yet)
[09:33:01] <Krinkle>	 I think the problem is in the generation of jobs through very generic regexes. Reusing code but too much.
[09:33:13] <Krinkle>	 It's just 1 line of grunt call, not worth re-using I guess.
[09:33:31] <Krinkle>	 I"m not sure whether Zuul has to be this way or whether that was your choise, but I don't like it :/
[09:34:04] <hashar>	 :-D
[09:34:20] <hashar>	 I have talked about Zuul layout configuration file with openstack people
[09:34:45] <hashar>	 we could implement a templating system to avoid copy pasting similar workflow
[09:34:47] <hashar>	 s
[09:35:03] <Krinkle>	 I mean, can't we just have like this: <repo regex> pipelike X: "job title" .. shell execs...
[09:35:07] <Krinkle>	 and that for any repo pattern.
[09:35:13] <hashar>	 anyway,   verified + 1 is only for jobs being triggered by a human
[09:35:17] <Krinkle>	 no need for a generic "***-lint" job that is created for every repo
[09:35:32] <Krinkle>	 (in that hiearchy I mean)
[09:35:32] <hashar>	 I think we should either add a new label (linting)  or extends verified so that +1 means linted and  +2 means unit tested.
[09:35:58] <Krinkle>	 hashar: see my latest engineering-l reply
[09:36:11] <Krinkle>	 hashar: we've been over this (or so I thought you told me)
[09:36:23] <Krinkle>	 v+1 is linted
[09:36:26] <Platonides>	 hashar, or require two verified
[09:36:32] <Krinkle>	 and merging would require 2 scores
[09:36:35] <hashar>	 Platonides: nobody wants that unfortunately :(
[09:36:39] <Krinkle>	 which in our case would be 1 human and 1 robot
[09:36:42] <Platonides>	 but then gerrit would send _two_ silly mails :/
[09:36:47] <Krinkle>	 hashar: it is an implementation detail, nobody wants anything
[09:36:56] <Krinkle>	 it makes no practical or visible difference
[09:37:20] <Krinkle>	 Platonides: which would that be?
[09:37:29] <hashar>	 Krinkle: so lint success is verified 0  by Roan comment.  The reason is that people would be able to cr+2 and submit which mean no unit tests will be run.
[09:37:54] <Krinkle>	 Platonides: well, yes but that's not related to this discussion (one after jenkins-bot does linting and one hours/days later when the tests run after human review)
[09:38:04] <Krinkle>	 hashar: we've been over this...
[09:38:18] <Krinkle>	 hashar: you told me we can change the requirement for merging internally
[09:38:25] <Krinkle>	 there used to be no requirement, just "Submit"
[09:38:27] <Krinkle>	 then we change it
[09:38:30] <Krinkle>	 to require CR+2
[09:38:31] <Platonides>	 why do you need human review before running tests?
[09:38:32] <Krinkle>	 then we changed it
[09:38:46] <Krinkle>	 Platonides: not now, that's an old already discussed topic
[09:38:46] <hashar>	 as for having -merge splitter out of -lint, that let us write a nice message asking to rebase the change.  That happened on https://gerrit.wikimedia.org/r/#/c/36833 after Trevor sent patchset 2
[09:38:54] <Krinkle>	 to require V+1 and CR+2
[09:39:03] <Krinkle>	 we can change it again to require V+2 and 2 CR (one human and one bot)
[09:39:05] <Krinkle>	 that's what you told me
[09:39:23] <Krinkle>	 now it sounds like you implemented it with that in mind, but then backed out and changed lint down to V0
[09:39:24] <Krinkle>	 why?
[09:40:36] <hashar>	 I don't get it
[09:40:49] <Krinkle>	 hashar: I'm sure that the comment can be any format we want, and can be passed up from anything. As a matter of fact, I know we can because it is already doing that. I'm not proposing we go back to child-jobs (since that would probably not support having a custom message be sent to gerrit from the -merge child job)
[09:41:02] <Krinkle>	 I"m proposing we merge them. So whatever sends that message can still send it exactly the same way
[09:41:28] <hashar>	 merge which messages ? The -merge and -lint outputs ?
[09:41:40] <Krinkle>	 no
[09:41:43] <Krinkle>	 ignore that
[09:42:09] <Krinkle>	 you keep bringing up other things so I reply to that, don't blame me for floating away from what we were talking about :P
[09:42:25] <Krinkle>	 okay, so you read the 9:48am engineering-l reply from me?
[09:42:33] <Krinkle>	 (last part)
[09:45:51] <hashar>	 Krinkle: yup
[09:46:37] <Krinkle>	 hashar: and?
[09:46:38] <hashar>	 so linting will be v+1,  unit test v+2  and we would change Gerrit to require  v+2 to be able to submit a change
[09:47:18] <hashar>	 that is a proposal
[09:50:09] <Krinkle>	 hashar: there is V+2 as well?
[09:50:14] <Krinkle>	 I didn't know that
[09:50:19] <hashar>	 na v+1 for now
[09:50:28] <hashar>	 but we can alter Gerrit to allow v+2
[09:50:29] <Krinkle>	 yeah, that would be even better than (ab)using an extra CR+1
[09:50:33] <hashar>	 or linting-1/+1 :-]
[11:38:39] <gerrit-wm>	 New patchset: Hashar; "Generate some more extensions" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/36964
[11:38:58] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/36964
[11:41:45] <gerrit-wm>	 New patchset: Hashar; "add more extensions" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36966
[11:42:04] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36966
[11:57:07] <hashar>	 ori-l: I have enabled jenkins jobs on the EventLogging ext
[11:57:17] <hashar>	 ori-l: so your latest patch might have a failure
[11:59:38] <ori-l>	 yay
[11:59:42] * ori-l  <3 jenkins

[12:01:07] <gerrit-wm>	 New patchset: Hashar; "tweak non passing job so they dont block for now" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36976
[12:01:24] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36976
[12:04:04] <hashar>	 ori-l: if you want to trigger unit tests, you have to CR+2 and wait :-]
[12:04:29] <ori-l>	 i don't have any phpunit tests that are merged yet
[12:04:31] <hashar>	 ori-l: will eventually make it so that Jenkins merge the change for us when the unit test pass
[12:04:54] <ori-l>	 i'm actually just rebasing an older commit that adds the first set of phpunit tests
[12:05:03] <hashar>	 ahh good to know!
[12:05:12] <hashar>	 so I will be able to enable unit testing in Jenkins :-]
[12:05:53] <Krinkle>	 hashar: I know ^ is not mediawiki/core, but we're not enabling Zuul on mediawiki/core without the auto-submit, right ?
[12:06:00] <hashar>	 "Imagine a world in which every single patchset can freely share its unit test result. That's our commitment."
[12:06:16] <hashar>	 Krinkle: yup
[12:06:29] <hashar>	 Krinkle: core will auto submit. Will enable that tomorrow I think.
[12:07:53] <Krinkle>	 hashar: so about using actual build steps as steps in the job execution (instead of using separate jobs for every tiny step) - any ideas if that is feasible or not?
[12:08:13] <Krinkle>	 I did it for MEdiaWiki-GIt-Fetching a few weeks ago for jshint, it works fine.
[12:08:28] <Krinkle>	 jshint in core is a build step, not a job.
[12:08:41] <Krinkle>	 (which is how it should be)
[12:11:15] <gerrit-wm>	 New patchset: Hashar; "typo on non vote for mwext-GeoData-testextensions" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36977
[12:11:25] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36977
[12:15:57] <hashar>	 ori-l: also I think Symfony framework as a way to validate a json file according to a json schema.
[12:16:22] <hashar>	 Krinkle: so we could either have all steps in a single job or split each step in a different job.
[12:16:49] <Krinkle>	 all steps of 1 pipeline, or of all pipelines as well?
[12:16:52] <Krinkle>	 (check,gate)
[12:17:00] <Krinkle>	 I'd prefer per pipeline
[12:17:00] <ori-l>	 hashar: yeah, there are several good implementations for php -- haven't checked out symfony, tho! thanks for the tip.
[12:17:02] <hashar>	 Krinkle: we have to split the lint and jslint jobs for now because some extensions do not pass jshint tests.
[12:17:20] <Krinkle>	 hashar: No, that doesn't make sense
[12:17:30] <Krinkle>	 hashar: They aren't the same job in the first place
[12:17:45] <Krinkle>	 How does mediawiki-core-lint affect mwext-...-lint ?
[12:17:48] <Krinkle>	 they are separate
[12:17:59] <Krinkle>	 (I know you meta-define when with .*-lint, but that's the problem)
[12:18:19] <Krinkle>	 You move the repeatitve-saving from global to job level)
[12:18:26] <Krinkle>	 so instead of job job job, it is task task task
[12:19:02] <Krinkle>	 so if one needs to pass and the other not, that's completely fine
[12:19:08] <Krinkle>	 they are separately defined
[12:19:23] <hashar>	 ori-l: ahh not symphony, but here is the project : https://github.com/justinrainbow/json-schema
[12:19:28] <Krinkle>	 you can't define them all with just one, that may look fun at first, but obviously doesn't scale.
[12:19:48] <hashar>	 Krinkle: all the -lint jobs are generated based on a template which take for argument the gerrit project name.
[12:19:56] <ori-l>	 hashar: i have a staged change adding it to the repo already :)
[12:20:03] <Krinkle>	 hashar: yes, that doesn't work, unless you can create exceptions.
[12:20:15] <hashar>	 Krinkle: so mediawiki-core or  FoobarExtension are generated using the exact same template. If I enable jshint in mediawiki/core that enable it in all extensions too.
[12:20:23] <Krinkle>	 yes, why?
[12:20:34] <Krinkle>	 We already save all the repeatance by using grunt and ant
[12:20:42] <Krinkle>	 no need to abstract even more with these "job templates"
[12:20:46] <hashar>	 Krinkle: so I have split jshint out to a specific job.  Then in Zull I make all -jshint to be non voting and add exception to vote on some repositories.
[12:20:52] <Krinkle>	 unless they are useful, and it sounds like they're limiting us too much.
[12:20:59] <hashar>	 I am open to a change. But not now.
[12:21:06] <hashar>	 I have too many things to handle by the end of the year.
[12:21:20] <Krinkle>	 well, change suggests there is something. right now I'd prefer there isn't anything until we can work with it.
[12:21:45] <hashar>	 having everything in a the same build or split in jobs is just a matter of taste.  Idont disagree with you but we can argue over and over for a few months. That is really bikeshedding.
[12:21:48] <Krinkle>	 it's just a few lines of code in layout.yaml, I don't know the syntax yet or I would've done it myself
[12:21:52] <Krinkle>	 it sounds very simple to do.
[12:21:58] <hashar>	 in the end, the result is the same: tests get run and failures are reported.
[12:22:07] <hashar>	 so lets pause that and talk about it later in january :-]
[12:22:15] <Krinkle>	 it isn't bikeshedding, I know I"m talking about the format, but not because I case about the format
[12:22:28] <Krinkle>	 I'm talking about the format, because it sounds clearly that the current format is not working.
[12:22:54] <hashar>	 ori-l: you can test out the result by voting +2. That should trigger tests.
[12:23:09] <hashar>	 so so far I have to finish up adding some extensions in jenkins
[12:23:17] <hashar>	 adapt Zuul to fit our need
[12:23:35] <hashar>	 and write documentation for Zuul layout.yaml and jenkins job builder so others can amend the config :-]
[12:23:42] <hashar>	 theses are my top priorities :-]
[12:26:29] <gerrit-wm>	 New patchset: Hashar; "enable non voting mwext-EventLogging-testextensions" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36981
[12:26:58] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36981
[12:27:50] <ori-l>	 i'm going to register a gerrit account 'jenkins—bot' (em dash instead of hyphen)
[12:27:55] <ori-l>	 and leave crazy reviews on people's changes
[12:29:07] <ori-l>	 hashar and Krinkle not amused
[12:29:52] <hashar>	 :-]]]]]]
[12:36:24] <ori-l>	 hashar: is the current failure my fault or a jenkins config issue?
[12:36:37] <hashar>	 i am not sure
[12:36:42] <hashar>	 looks like the tests are not properly registered
[12:38:54] * ori-l  checks

[12:41:40] <Reedy>	 bad ori-l
[12:41:53] * ori-l  glares at Reedy

[12:42:12] <ori-l>	 i didn't merge yet
[12:42:19] <Reedy>	 fail.
[12:42:35] <ori-l>	 the books are still open
[12:42:49] <ori-l>	 anything could happen
[12:42:54] <ori-l>	 100% test coverage
[12:42:57] <ori-l>	 it's all possible
[12:43:13] <hashar>	 at least on my comp  I get nothing for  php tests/phpunit/phpunit.php -- extensions/EventLogging/
[12:43:36] <ori-l>	 no failures, then
[12:43:43] <hashar>	 no test executed :-]
[12:43:51] <ori-l>	 ...no failures, then!
[12:44:07] <ori-l>	 why doesn't jenkins like my anonymous function
[12:44:10] * ori-l  hrms.

[12:44:53] <hashar>	 the hook is in tests/phpunit/suites/ExtensionsTestSuite.php
[12:55:35] <gerrit-wm>	 New patchset: Hashar; "gate-and-submit, like clone but auto submit change" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36983
[12:55:35] <gerrit-wm>	 New patchset: Hashar; "enable auto submit for Translate" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36984
[12:56:03] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36983
[12:56:52] <gerrit-wm>	 New review: Hashar; "I have talked about it with Siebrand on i18n channel.  Having to manually press the submit button is..." [integration/zuul-config] (master); V: 1 C: 0;  - https://gerrit.wikimedia.org/r/36984
[12:56:52] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36984
[13:08:03] <gerrit-wm>	 New patchset: Hashar; "jobs for mw/ext/LiquidThreads" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/36987
[13:08:15] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/36987
[13:11:05] <gerrit-wm>	 New patchset: Hashar; "enable reporting for LiquidThreads" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36988
[13:11:06] <ori-l>	 aksjhdkajshd
[13:11:08] <ori-l>	 figured it out
[13:11:14] <hashar>	 ori-l: what was it ?
[13:11:21] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36988
[13:11:32] <ori-l>	 filename was 'JsonSchemaTests.php'; has to be 'JsonSchemaTest.php'
[13:11:37] <hashar>	 haha
[13:11:56] <ori-l>	 i don't know if that's because it has to match to class name or because phpunit wants %sTest.php
[13:12:00] <ori-l>	 but i also don't care
[13:12:01] <hashar>	 ori-l: Translate extension simply glob any file named  **Test.php
[13:12:09] <hashar>	 for a later change :)
[13:12:23] <ori-l>	 that's a good idea
[13:14:18] <hashar>	 ori-l: our i18n team is full of good idea
[13:14:59] <ori-l>	 i had globbing for js files and auto-registration as resourceloader modules as early as may
[13:15:08] <ori-l>	 if they preceded it, hats off to them :P
[13:16:51] <Krinkle>	 ori-l: phpunit loads all %sTest.php files, then inside that file a class with the name of the file (so the file can contain non-test classes as well), and then it queues all test% functions inside that class
[13:17:34] <ori-l>	 yeah, it's the curse of XUnit
[13:17:42] <ori-l>	 passed on from one generation to the next
[13:23:42] <hashar>	 there is a replacer for PHPUnit : https://github.com/atoum/atoum#readme :)
[13:23:49] <hashar>	 haven't looked at it yet though
[13:26:02] <ori-l>	 hashar: can i get the tests to run on this changeset, or is it a chicken-and-egg problem?
[13:26:47] <hashar>	 ori-l: Jenkins get latest master then merge the change on master.
[13:26:54] <hashar>	 so that is more like hammer and egg :-D
[13:27:25] <DanielK_WMDE_>	 Reedy: hi! in preparation for the deployment tonight, we need two core fixes to be backported:
[13:27:36] <hashar>	 ori-l: where hammer is the change you apply on egg and see how it breaks it
[13:27:37] <DanielK_WMDE_>	 https://gerrit.wikimedia.org/r/#/c/36989
[13:27:54] <DanielK_WMDE_>	 and https://gerrit.wikimedia.org/r/#/c/36990
[13:28:08] <hashar>	 ori-l: to retrigger the test either send a new patchset or write a comment with CR+2
[13:29:12] <DanielK_WMDE_>	 Reedy: is that doable?
[13:29:35] * DanielK_WMDE_  is going to grab some food now, bbl

[13:29:39] <hashar>	 ori-l: yeahh htest failures :) https://integration.mediawiki.org/ci/job/mwext-EventLogging-testextensions/5/console
[13:29:44] <hashar>	 ori-l: congratulations
[13:29:49] <ori-l>	 assertJsonStringEqualsJsonString
[13:29:56] <ori-l>	 we must be running an older version of phpunit
[13:29:57] <ori-l>	 bummer
[13:30:15] <hashar>	 ori-l: we are on 3.6 :(
[13:32:09] <hexasoft>	 hello
[13:33:23] <hashar>	 ori-l: will try to get it updated
[13:33:24] <hexasoft>	 a question about Lua/Sribunto: it is not clear for me here: http://www.mediawiki.org/wiki/Lua_scripting -> Roadmap: "January-March 2013   Full deployment of Lua to the production cluster (contingent upon October assessment) "
[13:33:45] <hexasoft>	 is this roadmap only for mediawiki or for all the projects?
[13:34:22] <ori-l>	 hashar: \o/
[13:36:57] <hashar>	 ori-l: https://bugzilla.wikimedia.org/show_bug.cgi?id=42724
[13:37:07] <ori-l>	 i saw, thanks!
[13:38:22] <Reedy>	 hexasoft: full deployment would mean everywhere
[13:38:40] <Reedy>	 Or mostly everywhere, some projects might have some issues and have to be rolledback etc
[13:39:17] <Reedy>	 hexasoft: besides, it's already on mediawiki.org
[13:42:16] <hexasoft>	 Reedy: ok, thanks. Nice :)
[13:44:05] <hexasoft>	 BTW Scribunto stuff still lack of "good pratices" documents: you can perform what you want in so many ways, it is difficult to know if we don't choose the worse one
[13:47:55] <DanielK_WMDE_>	 Reedy: thanks for merging!
[13:58:57] <hashar>	 ori-l: I have merged your PHPUnit tests in EventLogging
[13:59:05] <hashar>	 ori-l: and will make them blocking
[14:00:53] <gerrit-wm>	 New patchset: Hashar; "EventLogging unit tests are now voting" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36998
[14:01:05] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/36998
[14:04:21] <hashar>	 snackk time
[14:55:15] <gerrit-wm>	 New patchset: Hashar; "enable reporting for operations-puppet-validate" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37007
[14:55:35] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37007
[15:18:53] <gerrit-wm>	 New patchset: Hashar; "lint check now vote on Code-Review label" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37012
[15:19:24] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37012
[15:32:29] <gerrit-wm>	 New patchset: Hashar; "update workflow representation based on recent changes" [integration/doc] (master) - https://gerrit.wikimedia.org/r/37014
[15:32:45] <gerrit-wm>	 Change merged: Hashar; [integration/doc] (master) - https://gerrit.wikimedia.org/r/37014
[16:00:44] <gerrit-wm>	 New review: Mwjames; "Can we have another shot at this one, now that we starting SMW 1.9 as a master branch I really like ..." [integration/jenkins] (master) C: 0;  - https://gerrit.wikimedia.org/r/32836
[17:39:37] <Krinkle>	 hashar: now jenkins-bot is doing CR+1 instead of V+1 for VisusalEditor on linting https://gerrit.wikimedia.org/r/#/c/36934/
[17:40:13] <Krinkle>	 (which means I need to override V+1 to merge)
[19:39:19] <yukon>	 Hi, is it possible to find the 15 millionth file specifically on Commons?
[19:40:07] <AaronSchulz>	 well there is no img_id field
[19:40:34] <AaronSchulz>	 and img_timestamp is not unique
[19:40:36] <yukon>	 we've found it in the past I'm pretty sure
[19:40:45] <AaronSchulz>	 also it depends on whether deleted stuff counts too
[19:41:10] <yukon>	 well, we'd like to promote something nice
[19:41:12] <AaronSchulz>	 these things never seem well defined :)
[19:41:21] <AaronSchulz>	 you could probably lie and no one would notice
[19:42:05] <yukon>	 heh
[19:42:18] <yukon>	 http://blog.wikimedia.org/2011/04/15/ten-million-free-media-files-and-counting/
[19:54:31] <multichill>	 yukon: We always just select a file and say that's the milestone. Same happened this time for the 15Mth one
[19:55:07] <multichill>	 This time Jean-Fred did shotgun on https://commons.wikimedia.org/wiki/File:17W_Aug_14_1996_0124Z.png
[20:01:18] <RoanKattouw>	 hashar: Any idea why Jenkins didn't V+1 https://gerrit.wikimedia.org/r/#/c/36833/ ?
[20:01:47] <RoanKattouw>	 Oh hah, and now that I've +2ed it, Jenkins V+1ed it
[20:01:50] <RoanKattouw>	 But didn't submit it
[20:01:57] <hashar>	 RoanKattouw: yeah no autosubmit yet
[20:01:58] <RoanKattouw>	 Is this Zuul thing broken for VisualEditor?
[20:02:07] <RoanKattouw>	 I see
[20:02:23] <AaronSchulz>	 preilly: I replied to tyler
[20:02:26] * AaronSchulz  almost forgot

[20:02:37] <hashar>	 RoanKattouw: in which channel is the VE team ?
[20:02:44] <hashar>	 RoanKattouw: IRC channel I mean
[20:02:45] <RoanKattouw>	 hashar: #mediawiki-visualeditor
[20:02:49] <hashar>	 of course
[20:02:58] <hashar>	 follow up there :)
[20:03:26] <preilly>	 AaronSchulz: thanks
[20:07:50] <gerrit-wm>	 New patchset: Hashar; "enable auto submit for VisualEditor" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37054
[20:11:18] <MaxSem>	 AFT5 team: Notice:  Undefined variable: wmgArticleFeedbackv5CTABuckets in /home/wikipedia/common/wmf-config/CommonSettings.php on line 2260
[20:12:40] <gerrit-wm>	 New review: Hashar; "Roan says so :)" [integration/zuul-config] (master); V: 1 C: 2;  - https://gerrit.wikimedia.org/r/37054
[20:12:42] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37054
[20:12:45] <AaronSchulz>	 MaxSem: messing up cli scripts?
[20:12:49] <MaxSem>	 yup
[20:28:06] <gerrit-wm>	 New patchset: Hashar; "jobs for mw/ext/Parsoid" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/37061
[20:28:25] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/37061
[20:32:30] <gerrit-wm>	 New patchset: Hashar; "add Parsoid extension (jshint only)" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37062
[20:33:18] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/37062
[20:35:18] <Krenair>	 kaldari, saw https://gerrit.wikimedia.org/r/#/c/36941/2 - Reedy compressed the others, does that need to be done here as well?
[20:39:27] <kaldari>	 Krenair: hopefully not, I saved it in Save for Web mode in Photoshop to get rid of all the extra crap, but I haven't run pngcrush on it.
[20:40:00] <kaldari>	 might make a small difference though
[20:43:25] <kaldari>	 jdlrobson: Hey Jon...
[20:43:47] <kaldari>	 so I'm not actually doing any local jslint configuration, just relying on the core configs
[20:44:36] <jdlrobson>	 hey kaldari: :)
[20:44:47] <jdlrobson>	 where is the core config?
[20:44:52] <Reedy>	 chrismcmahon: Ugh. My IRC cliented showed you pinged me...
[20:44:54] <Reedy>	 I can't find where
[20:45:44] <chrismcmahon>	 Reedy: in #wikimedia-tech.  (01:44:16 PM) chrismcmahon: Reedy: are you doing today's deploy?  UW is busted for IE7 (at least) on test2 just now. https://bugzilla.wikimedia.org/show_bug.cgi?id=42736 (cc andre__)
[20:45:47] <kaldari>	 slash.jshintrc
[20:45:59] <kaldari>	 (can't type the slash in IRC)
[20:46:09] <jdlrobson>	 kaldari: so you are using https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=.jshintrc;h=7fa138d44f3d2d7e45884fa3854076518132da2c;hb=HEAD
[20:46:13] <chrismcmahon>	  /.jshinntrc
[20:46:14] <kaldari>	 jdlrobson: Here's an example of the error report: .jshintrc
[20:46:41] <kaldari>	 chrismcmahon: how'd you do that?
[20:46:50] <kaldari>	 oops...
[20:46:53] <chrismcmahon>	 kaldari: lead with a space :)
[20:47:05] <kaldari>	 member:jdlrobson: Here's an example of the error report: https://integration.mediawiki.org/ci/job/mwext-Echo-jslint/4/console
[20:47:35] <kaldari>	 jdlrobson: Yes, that's the file
[20:48:06] <jdlrobson>	 kaldari brb just grabbing lunch but this is most odd.. i wonder if config file is coming from somewhere else / has an error
[20:48:18] <kaldari>	 jdlrobson: Maybe so
[20:55:32] <Krenair>	 hashar, https://gerrit.wikimedia.org/r/#/c/37079/ had to get manual approval
[20:55:57] <Krenair>	 I don't think we need to have l10n-bot changes tested
[20:56:42] <hashar>	 Krenair: poor l10n-bot :/
[20:56:55] <hashar>	 Krenair: I thought it merged stuff automatically anyway
[20:57:38] <Nikerabbit>	 Krenair: you only waited two minutes, it's not instant
[20:58:03] <Nikerabbit>	 https://gerrit.wikimedia.org/r/#/dashboard/137
[20:58:24] <Nikerabbit>	 it will soon merge them all in one go
[20:58:47] <Krenair>	 Huh, ok. I'll ignore them in future then
[20:59:12] <Nikerabbit>	 ... I hope anyway
[20:59:19] <hashar>	 Jenkins voted some of them :-]
[20:59:38] <Krenair>	 But still, I wouldn't bother getting jenkins to run tests on them
[20:59:47] <kaldari>	 chrismcmahon: How'd the deployment go today?
[21:00:39] <chrismcmahon>	 kaldari: UW busted on test2 right now for IE6/7 unfortunately https://bugzilla.wikimedia.org/show_bug.cgi?id=42736
[21:01:10] <Nikerabbit>	 Krenair: ah it is really broken this time
[21:02:27] <kaldari>	 chrismcmahon: good to know, any issues with the h3s?
[21:02:41] <chrismcmahon>	 kaldari: not that I'm aware
[21:02:58] <kaldari>	 that's a nice change :)
[21:03:29] <chrismcmahon>	 andre__ is also looking for things like reports of h3 weirdness
[21:03:46] <andre__>	 but it looks good this time.
[21:03:50] <kaldari>	 too bad I only speak English :(
[21:04:26] <kaldari>	 I could ask at Simple English Wikipedia :)
[21:04:49] <kaldari>	 i speak good at simple english
[21:05:50] * apergos  goes to look at some el projects

[21:06:47] <apergos>	 so far so good
[21:07:04] <lwelling>	 kaldari, re email, I figured that about the i18n messages
[21:07:51] <chrismcmahon>	 UW should be OK on commons right now but it sure has been thrashing on test2, I think this is the 3rd time in 3 deploys it's been busted.
[21:08:29] <apergos>	 (as far as h3 and other issues, I am not checking uw, don't even know if it's enabled on those)
[21:11:06] <kaldari>	 lwelling: cool
[21:14:56] <kaldari>	 chrismcmahon: I don't think anything's been changed in UW since the last time. Was there a new test added?
[21:16:32] <kaldari>	 the last change included in the version on test2 is the fix we did for IE8 (compat-mode).
[21:17:14] <lwelling>	 but the strings are not currently very granualar, and I don't know how similar the HTML ones will be
[21:17:38] <lwelling>	 the current ones are a 10 line email body as a single string
[21:18:39] <kaldari>	 lwelling: hmm, we don't normally do that. it may require a bit of refactoring
[21:19:03] <kaldari>	 also I need to finish reviewing https://gerrit.wikimedia.org/r/#/c/35342/
[21:19:59] <kaldari>	 lwelling: I think anywhere we would want to change formatting, we'll probably want to split or tokenize the string
[21:20:08] <chrismcmahon>	 kaldari: UW in IE7 on commons looks OK, must be a config difference between test2 and commons
[21:20:35] <chrismcmahon>	 kaldari: same versions on both, from Nov 28
[21:20:51] <kaldari>	 chrismcmahon: I'll try to take a look either today or tomorrow
[21:21:22] <chrismcmahon>	 kaldari: thanks!  it would be nice to have test2 working for like, a test :)
[21:21:29] <kaldari>	 lwelling: we can also include strings as tokens to put inside other strings if necessary
[21:21:46] <kaldari>	 chrismcmahon: for real
[21:22:38] <chrismcmahon>	 kaldari: the automated test for UW was passing yesterday fwiw
[21:22:50] <kaldari>	 that's strange
[21:23:19] <kaldari>	 I can't imagine anything related to UW changing since yesterday, even config-wise
[21:24:00] <chrismcmahon>	 unless I missed something big, I believe that to be true
[21:24:22] <kaldari>	 I believe you, it's just weird :)
[21:25:42] <chrismcmahon>	 I've been known to miss stuff too :/
[21:31:51] <kaldari>	 chrismcmahon: maybe it's a race condition
[21:32:00] <chrismcmahon>	 kaldari: makes sense
[21:32:34] <kaldari>	 I'll check all the dependancies to be safe
[21:32:51] <chrismcmahon>	 kaldari: but if it's a race condition, it could happen on commons occasionally also.  at least it's just pre-IE8 that (might) have it it seems
[21:33:27] <kaldari>	 commons users are more tolerant of errors than your script :)
[21:34:22] <chrismcmahon>	 kaldari: I checked manually, both IE6 and IE7 coughed up the error when I used the browsers myself
[21:34:39] <chrismcmahon>	 (the script just told me what to check)
[21:34:51] <kaldari>	 where does it give you the error, on initial load or one of the steps?
[21:35:10] <kaldari>	 I'm trying to repro on browserstack right now
[21:35:43] <chrismcmahon>	 kaldari: immediately upon clicking link to UW after logging in.  I used crossbrowsertesting.com btw
[21:35:53] <chrismcmahon>	 and the automated test used Sauce Labs hosts
[21:42:01] <kaldari>	 chrismcmahon: finally saw the error. took me about 10 tries though. Must be a race condition.
[21:42:42] <chrismcmahon>	 kaldari: I'm just lucky that way I guess, got it the first time both times
[21:43:30] <kaldari>	 I hope my error is the same as your error :)
[21:45:20] <chrismcmahon>	 kaldari:  I start to think test2 has burps like that.
[21:48:37] <kaldari>	 chrismcmahon: looks like it could be related to config differences, BTW. Still debugging, though (which is painful in IE7).
[21:49:22] <chrismcmahon>	 kaldari: I'm re-running my browser test suite and IE7 just passed :(
[21:49:37] <chrismcmahon>	 in the middle of IE6 right now
[21:49:53] <Reedy>	 PHP Fatal error:  Call to a member function getRedirectChain() on a non-object in /usr/local/apache/common-local/php-1.21wmf5/includes/EditPage.php on line 2985
[21:50:11] <jdlrobson>	 kaldari: that jshint problem is bizarre
[21:50:26] <jdlrobson>	 there is no reason it should be sending an error for window being undefined
[21:50:58] <kaldari>	 jdlrobson: I know. I hope I'm not the only person experiencing this
[21:51:10] <jdlrobson>	 kaldari: I'd suggest defining your own .jshintrc file in the extensions folder with exact same contents and seeing if that passes
[21:51:16] <jdlrobson>	 (assuming this is for Echo)
[21:51:21] <kaldari>	 yeah, for Echo
[21:51:24] <kaldari>	 I'll try that
[21:51:32] <jdlrobson>	 MobileFrontend does that without any problems
[22:01:08] <awjr>	 Reedy: im about to do a config change and noticed there's an outstanding change on Fenari - think it might be yours
[22:01:09] <awjr>	 -       $wgArticleFeedbackv5CTABuckets = $wmgArticleFeedbackv5CTABuckets;
[22:01:09] <awjr>	 +//     $wgArticleFeedbackv5CTABuckets = $wmgArticleFeedbackv5CTABuckets;
[22:01:21] <Reedy>	 It is
[22:01:24] <Reedy>	 Fixing someone elses error
[22:01:47] <Reedy>	 Though, as it's giving a notice
[22:01:56] <Reedy>	 I'm just gonna commit it as it's not going to break anything
[22:01:57] <Reedy>	 moment
[22:02:00] <awjr>	 k
[22:03:50] <Reedy>	 awjr: go ahead
[22:03:57] <awjr>	 thanks Reedy
[22:06:49] <robla>	 Reedy: is test2 all Wikibasey?  :-)
[22:07:02] <Reedy>	 It is
[22:07:10] <Reedy>	 Apparently it'll make almost no difference though.. :D
[22:07:38] <robla>	 that's not going to stop us from declaring victory
[22:07:49] <robla>	 WE HAVE CHECKED THE CHECKBOX!  HUZZAH!
[22:07:50] <robla>	 :)
[22:08:09] <awjr>	 dont think this is a huge deal but figured folks should know:
[22:08:09] <awjr>	 awjrichards@srv193:~$ sync-common
[22:08:10] <awjr>	 Copying to srv193...rsync: send_files failed to open "/php-1.21wmf5/maintenance/.mwsql_history" (in common): Permission denied (13)
[22:08:10] <awjr>	 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [generator=3.0.9]
[22:08:10] <awjr>	 failed
[22:25:19] <kaldari>	 chrismcmahon: I think this bug is related to the weird ExperimentalAsyncLoading on test2
[22:25:39] <kaldari>	 we really should turn that off if we want to use test2 as a clean test environment
[22:25:56] <chrismcmahon>	 kaldari: nice!  I have heard that mentioned as a possible source of other weird heisenbugs in IEs before
[22:26:00] <kaldari>	 as it fundamentally changes how JS is loaded
[22:26:13] <kaldari>	 and it's only turned on on test2
[22:26:23] <chrismcmahon>	 kaldari: at one point I was getting a ton of unreproducible errors in IEs when hacking on AFT
[22:27:10] <kaldari>	 yeah, any tools that are JS-heavy could likely be affected unless they have extremely defensive coding.
[22:27:54] <chrismcmahon>	 AFT is not known for defensive coding.  it's much better than it was though.
[22:30:10] <kaldari>	 one of the problems is that it inverts the order of JS loading - it calls all the RL modules immediately before the JS globals, which frequently causes race conditions
[22:30:39] <kaldari>	 although they are rare unless you are loading some large JS globals, which UW does.
[22:30:42] <chrismcmahon>	 kaldari: since I haven't heard that name in months, I assume it is not under active development.  can you disable it on test2?
[22:31:23] <kaldari>	 chrismcmahon: I don't think anyone's messed with it in at least a year or so, but Roan would know for sure.
[22:31:23] <RoanKattouw>	 kaldari: Eww, I didn't know it did that
[22:31:33] <RoanKattouw>	 And yes, no one has messed with it recently
[22:32:12] <kaldari>	 RoanKattouw: cool if I turn it off on test2?
[22:32:26] <RoanKattouw>	 Yes
[22:33:09] <chrismcmahon>	 thanks!
[22:33:33] <kaldari>	 RoanKattouw: actually what I said earlier is wrong...
[22:35:11] <kaldari>	 the RL modules are called before the addScript globals regardless of whether it's using the experimental async loading, but the difference is that the async loading does it in the head instead of in the footer, which I imagine affects how they load.
[22:36:06] <kaldari>	 it would be nice if those addScript globals got output sooner either way
[22:36:18] <RoanKattouw>	 addScript globals?
[22:36:22] <RoanKattouw>	 Oh, legacy wgFoobar stuff?
[22:36:26] <kaldari>	 although I guess not many things use addScript any more
[22:36:28] <RoanKattouw>	 As in, not using mw.config ?
[22:36:29] <kaldari>	 yeah
[22:37:35] <kaldari>	 UW uses.. getOutput()->addScript( Skin::makeVariablesScript( blah... which we should reimplement one day
[22:37:42] <RoanKattouw>	 Noooo
[22:37:49] <RoanKattouw>	 Yeah I can see how we might have failed to account for /that/
[22:37:56] <kaldari>	 :)
[22:40:46] <kaldari>	 chrismcmahon: I'll make a note to fix that one after the Flickr stuff gets deployed. It's been that way for ages, and I'd rather not make a major JS change at the same time the other stuff is going out
[22:41:27] <kaldari>	 chrismcmahon: plus it seems unlikely this is actually occurring on Commons, and if it is only rarely.
[22:42:33] <chrismcmahon>	 kaldari: agreed and thanks, that should make things more stable.   want to update https://bugzilla.wikimedia.org/show_bug.cgi?id=42736?  or I can
[22:42:43] <kaldari>	 I will
[22:42:59] <kaldari>	 and I'll turn the async loading off tomorrow during the UW deployment
[22:43:05] <chrismcmahon>	 awesome
[22:53:30] <Eloquence>	 kaldari, is the flickr import going live tomorrow?
[22:54:09] <kaldari>	 that's the plan
[22:54:17] <kaldari>	 finally got everything +2ed
[22:54:44] <Eloquence>	 nice. one small thing - it might be nice to have a specific tracking category for flickr imports, if it doesn't add one already