[00:16:40] Ryan_Lane: btw, regarding import from wikitech, how are you (if) dealing with user names. [00:16:51] both wikitech and labsconsole have the nature of being a fishbowl [00:17:11] well wikitech more so than labsconsole, but the principle is the same. [00:17:39] or are you going to use special import/export and have them not have any user ids (just names) [00:17:47] I can' see there being many cases where they aren't he same person. [00:21:40] I think labsconsole will win [00:21:46] as it uses ldap [00:22:21] and is the obvious if what he does is an export & import [00:33:06] Krinkle: people will need to reregister [00:33:50] I'm using export/import [00:39:17] csteipp: https://bugzilla.wikimedia.org/show_bug.cgi?id=41586 [00:42:34] Ryan_Lane: sure, I don't mean the actual accounts, but attribution of edits. [00:43:07] Krinkle: any recommendation? [00:43:40] Ryan_Lane: Not really [00:43:46] labsconsole is a fishbowl? umm [00:44:05] Ryan_Lane: If it were imported including the accounts, one could merge&delete those accounts into actual accounts per request [00:44:14] Krenair: it's not in the cluster [00:44:16] so that it edits are easily re-attributed. [00:44:32] could, yeah [00:44:34] I guess that is still possible when using import/export, but it'd be harder. [00:45:24] Krinkle, the import keeps the usernames as they were on the foreign wiki [00:45:34] Platonides: I know, that's the point. [00:45:38] so if you have Krinkle on both, they'll appear "merged" [00:45:52] I don't see the problem [00:45:55] Platonides: Not sure that's true, the revisions will have user_id=0 afaik. [00:46:11] the problem is of course in cases where the names are not the same [00:46:30] yep, rev_user=0 but rev_user_text = 'Krinkle' [00:46:34] I know [00:46:58] hmm... maybe better to filter them at the export [00:46:58] import/export was never a way to restore or merge a wiki, it always considers the imported entries foreign [00:47:12] there won't be many worthy users in wikitech [00:47:48] there is < 500 accounts [00:48:53] 87 accounts with editor rights [00:49:51] lol [00:50:17] hmm, plus a few more that have administrator but not editor [00:50:38] wow, my account is one of the oldest ones [00:53:58] hmm... Gwicke account created 13 December 2012 at 21:50 [00:54:07] but edited in 2004 ?? http://wikitech.wikimedia.org/index.php?title=Main_Page&diff=prev&oldid=2140 [00:54:27] Platonides: I originally created that wiki on my personal server [00:54:52] oh, you didn't migrate the user accounts? [00:54:53] the account was probably not migrated [00:54:59] that would explain it [00:55:18] [00:55:18] Gwicke [00:55:18] 0 [00:55:18] [01:35:32] New patchset: Zfilipin; "Documentation on how IRC notifications should be set up" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51093 [01:37:20] New review: Cmcmahon; "docs for IRC notification" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/51093 [01:37:20] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51093 [01:52:19] New review: Zfilipin; "Thanks a lot for the update! :)" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/51069 [01:52:19] Change merged: Zfilipin; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51069 [07:23:03] Ryan_Lane: see #wikimedia-labe pm. several new lines [07:23:09] labs [07:51:04] hi MaxSem [07:51:10] hey [18:11:16] hashar: so, you didn't tell me the other day (or I forgot), do we have a blocker for docgen? [18:11:35] the pipeline/trigger thing, you mentioned there was a better hook coming in zuul, but its not there yet? [18:11:38] do we really need that? [18:17:31] Krinkle: still have to figure it out [18:19:43] hashar: code in gerrit doesnt' work? [19:10:18] Change on 12mediawiki a page WMF Projects/Data Dumps was modified, changed by Sharihareswara (WMF) link https://www.mediawiki.org/w/index.php?diff=652930 edit summary: [+28] Mariya [19:23:59] hashar: ping? [19:24:10] GrumpyPanda: in meeting [19:24:15] hashar: ah, ok [19:24:27] GrumpyPanda: some mobile app dead? [19:24:41] yup. Dependency issue with maven and jenkins [19:24:47] it is trying to fetch a dependency that has been removed [19:24:49] and hence failing [19:25:06] not sure how I can help on that :D [19:25:16] hashar: on jenkins [19:25:19] it works fine locally [19:25:49] anyway will investigate :) [19:30:12] hashar: fixed! Sorry for the spam :) [19:30:21] well done :D [19:30:55] :P [19:39:41] hi [19:47:11] hashar: I need someone (=you) for code review here, not difficult (wfMsg -> wfMessage) [19:47:31] otherwise I need to +2 .... my own extension.... [19:47:45] not making friends [19:47:57] hashar: https://gerrit.wikimedia.org/r/#/c/50604/ [19:50:41] Wikinaut: ask the i18n team in #mediawiki-i18n :-] [19:50:52] I am in a meeting right now [19:50:57] again ? [19:51:12] Wikinaut: He's a popular guy. I might be able to help, sec. [19:51:34] marktraceur: yes pls. (I am maintainer of E:RSS) [19:51:37] Wikinaut: I am in SF for two weeks so I am taking that opportunity to meet others face to face :-] [19:51:40] the code is tested and works [19:51:48] hashar: okokok [19:52:03] marktraceur: pls. have a look https://gerrit.wikimedia.org/r/#/c/50604/ [19:52:03] Wikinaut: I dunno, I don't have OID configured on my system, it'd be impossible to test [19:52:18] no, this is E:RSS [19:52:33] soory [19:52:37] I was wrong !! [19:52:40] sorry [19:53:07] there is almost nobody except me and Ryan who have this set up [19:53:16] Right, so why not ask him? [19:53:31] becasue he is busy with other stuff [19:53:36] I am in contact with him [19:53:55] he's already in the list of code reviewers [19:54:06] will ask him later, again [19:54:21] or, +2 [20:35:34] siebrand: hi [20:46:19] New patchset: Zfilipin; "Updated Ruby gems" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51212 [21:13:26] AaronSchulz: I'm pushing your user_token changes live [21:13:49] we can clean up the DB after that I suppose [21:14:02] so that "remember me" is unbroken [21:15:17] we can just run resetUserTokens.php [21:15:38] I think it will mostly only affect bots, since most users will use the centralauth equivalent [21:16:12] yep [21:18:03] just reviewing that script [21:18:13] $result = $dbr->select( 'user', [21:18:13] array( 'user_id' ), [21:18:13] array(), [21:18:13] __METHOD__ [21:18:13] ); [21:18:18] might use a fair bit of memory [21:20:15] 18M rows, maybe only 200MB or so since it's a result object not an array [21:20:26] if it was in a PHP array we would be in trouble [21:20:57] I'll just run it and see what happens [21:21:09] on hume, so less people will mind if it goes into swap ;) [21:23:24] Simple enough to shift it over to being batched [21:24:10] New review: Cmcmahon; "maintenance" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/51212 [21:24:11] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51212 [21:24:37] sure, 5 lines of code, then commit, push, merge, cherry-pick, merge, pull, sync [21:24:51] yeaaah [22:13:39] Who's a good person to review changes to HTMLForm and Preferences? [22:16:44] AaronSchulz: I see Chad merged that async upload change for you [22:18:20] kaldari: I see you've had some discussions with Tyler [22:18:51] Yeah, there seems to be some confusion on the div and raw output formats for HTMLForm [22:19:04] I didn't know we even had output formats [22:19:11] New patchset: Hashar; "parsoid parserTests to the test pipeline (non voting)" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/51284 [22:19:28] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/51284 [22:19:29] My understanding is that div formats the form with divs instead of tables. I'm not sure what the raw format is for [22:19:54] where do you get cables from around here? I could use a bigger screen [22:20:10] Probably want to ask Chip [22:20:22] over on the other side of 3rd floor [22:20:29] right [22:21:29] let's look for setDisplayFormat callers [22:21:33] qgil: I'm available until 4pm today if you'd like to take a look at the CRM other people at the WMF use, and that I'm investigating to see if we could use it for tech volunteers as well. [22:22:42] Looks like extensions/MobileFrontend/specials/SpecialMobileFeedback.php uses the raw formar [22:22:45] format [22:22:54] yeah, I found that too [22:24:02] guess I should taylor the raw output for mobile then [22:24:07] tailor [22:24:26] https://gerrit.wikimedia.org/r/#/c/5246/ [22:25:12] TimStarling: Thanks, I'll add Arthur as a reviewer :) [22:27:08] the core change was arthur also: https://gerrit.wikimedia.org/r/#/c/6636/ [22:32:25] prior to that change, there was only the "table" output format [22:32:49] that is, the "table" output format in the new code is the same as what the old code generated [22:36:35] guillom, coincidence or not I started with https://www.mediawiki.org/wiki/User:Qgil/Contributors [22:42:54] Ryan_Lane: [22:42:57] PM [23:18:24] DanielK_WMDE_, any news on Solr meeting? [23:18:24] New patchset: Spage; "Ignore vim .swp files and generated reports/ dir." [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51293 [23:24:14] New patchset: Spage; "Add proper test for ResourceLoader errors." [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [23:27:05] New review: Krinkle; "(3 comments)" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [23:27:15] spagewmf: trigger word "ResourceLoader" :) [23:27:49] Krinkle hey, talking with zeljkof. [23:28:28] Change merged: Zfilipin; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51293 [23:29:14] superm401: ping [23:29:29] Krinkle, hey [23:29:31] https://gerrit.wikimedia.org/r/#/c/48745/3/tests/qunit/suites/resources/mediawiki/mediawiki.test.js [23:29:32] Krinkle, Proposing a similar RL test for QUnit is still on my list, as is talking to hashar about running Special:JavaScript/qunit in SauceLabs. [23:30:06] Krinkle, yep I replied. [23:30:12] superm401: I know [23:30:24] spagewmf: hi :-] [23:30:35] spagewmf: I am meeting ori and you tomorrow morning we can talk about it probably [23:30:48] looking forward to it [23:30:53] zeljkof: are you using SauceLabs ? [23:30:53] spagewmf: yes, though avoid duplicating efforts. Unit testing is already being worked on by me for Jenkins (whether it uses browserstack or saucelabs is a minor detail that can easily be changed) [23:31:12] spagewmf: i.e. don't start implementing code for running special:javascripttest in saucelabs [23:31:38] hashar: yes, we run selenium tests at sauce labs [23:31:46] ah that is the selenium [23:31:52] zeljkof: thx :) [23:32:03] Krinkle, glad to hear it. We just visit SauceLabs and manually pull up that page on one of our labs instances in different browsers. [23:32:18] Krinkle: spagewmf and I are playing with javascript and selenium [23:32:23] spagewmf: yeah, I do the same in browserstack right now [23:32:51] superm401: Exactly due to the browsers serialising it differently, building it with jquery and serialising isn't reliable [23:33:19] no more reliable then comparing two html strings that you may or may not quickly feed trough html() [23:33:47] The way I'm doing it now should work. [23:33:52] As long as the browser is internally consistent. [23:34:01] consistent in what [23:34:13] in putting the attributes in order of definition? [23:34:16] In the order of iteration and HTML serialization. [23:34:17] (for example) [23:34:35] you don't know in which order they element is created in jqueryMsg compared to the inline attr({}) call in the test [23:34:53] if jquerymsg() does the title first and then the href, .. [23:35:05] Alright, fine. [23:35:08] and even if the order is the same, the way jquery iterates the attr({}) call may be different etc. [23:35:09] So how about this? [23:35:15] I've been there, in qunit internals [23:35:20] I write an assertEqualsHTML helper method. [23:35:20] it is a big mess unfortunately [23:35:37] superm401: s/write/plug-in [23:35:39] It takes in two HTML strings, parses them, and reserializes them. [23:35:50] Yeah, it could go in our runner, right? [23:35:51] If it only were that simple [23:35:54] yes [23:36:20] Okay, why isn't it that simple? [23:36:22] superm401: for starters https://github.com/jquery/jquery-ui/blob/9f841dffcc83105cc2517c7e31640848fbfff0af/tests/unit/testsuite.js#L180 [23:36:33] and https://github.com/JamesMGreene/qunit-assert-html/blob/master/src/qunit-assert-html.js [23:36:50] I don't claim those two are as simple as possible, but they sure are complex. [23:36:50] New review: Spage; "(3 comments)" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [23:37:05] slightly more than running through html and getting it back out again [23:37:15] Krinkle, note they're taking an element as input. [23:37:19] I'm not proposing doing that. [23:37:22] superm401: Sure, I know [23:37:25] Just two HTML strings. [23:37:32] New patchset: Spage; "Add proper test for ResourceLoader errors." [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [23:37:34] So I don't need to worry about styles, properties, etc. [23:37:37] Just attributes. [23:37:39] superm401: but if they could compare them by serialising, that domEqual method would compare the outer html [23:38:16] No, because they want to know the applicable styles. [23:38:20] Because they're testing UI. [23:38:25] I know [23:38:26] As one would expect from a UI framework. [23:38:27] I wrote part of that [23:38:31] I know we don't need all of it [23:38:54] Given all the differences I mentioned, why doesn't the HTML round-trip I mentioned work? [23:39:00] For *our* use case [23:39:13] I'm just saying, serialising html won't work. The attribute order in most browsers is either alphebetical (in which case serialising would be sufficient) and in other browsers it is in order of definition and/or last updated. [23:39:28] that is the problem [23:39:49] because we shouldn't/can't rely on jqueryMsg putting the attributes in in the same order as our test. [23:40:01] You already convinced me to write the assert. [23:40:11] Okay, do you think this will work? [23:40:22] superm401: jquery.getAttr(), and perform a deep equal [23:40:43] One sec [23:40:47] MatmaRex: you there ? [23:41:24] mostly [23:41:35] hashar: about to disappear in ~15 minutes, though [23:41:46] did i break something? ;) [23:41:50] MatmaRex: I have read your wikitech-l message about category collation [23:41:52] Krinkle, so do you think this will work? [23:41:56] 1. Parse both HTML strings. [23:41:57] MatmaRex: I will try to get it deployed on beta :-] [23:42:03] 2. Recursively, for every level: [23:42:11] a. Compare every attr. [23:42:16] b. Compare .text() [23:42:18] MatmaRex: I will figure it out and reply to your wikitech-l once that is done. This way you will be able to have some people to test it on beta [23:42:22] MatmaRex: that is all :- [23:42:25] hashar: yay [23:42:26] MatmaRex: have a good sleep hehe [23:42:37] hashar: i've set up my own testwiki for pl and uk languages [23:42:50] MatmaRex: beta has a few more languages too :-] [23:42:54] hashar: and even wrote myself a script for setting them up :P (attached on the bug) [23:42:57] superm401: getting all attributes is also non-trivial due to IE bugs, but I wrote jquery.getAttrs for that so that should be fine [23:43:03] superm401: but yeah, that sounds good. [23:43:22] Alright, will do. [23:43:26] hashar: thanks for this, and good night :) [23:43:42] superm401: .children().each [23:43:49] hm.. no that wouldn't be recursive :) [23:44:09] superm401: I'll let you try first, don't wanna spoil it [23:44:23] or you may know already, there's a few different ways. none are wrong really. [23:45:59] superm401: find('*') gets all children recursively, jquery ensures they are in "following dom order". [23:47:00] How about contents() (includes text unlike children())? [23:47:03] My algorithm would be recursive. [23:47:10] But contents could be one step in the recursion. [23:47:42] I guess find('*') would be easier. [23:47:47] It definitely includes text? [23:48:41] superm401: no, it purposely doesn't [23:48:59] Okay, well I need to compare text, so I'll use contents(), and not text() [23:49:02] superm401: you'd wrap it in an element and start at a root [23:49:50] superm401: right, you'll want to compare the text nodes separately [23:50:06] instead of .text() since then you'd compare the same text many times [23:50:12] since .text() is aggregrated, too [23:50:35] reminds me of the TreeWalker [23:50:47] recursive loop it is, find() or other jquery methods don't help in this case. [23:50:58] https://wiki.php.net/rfc/optimizerplus#vote [23:50:59] https://www.mediawiki.org/wiki/MediaWiki:Gadget-Numerakri.js [23:52:45] superm401: well, https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-Numerakri.js&oldid=558756 rather [23:52:54] Alright [23:53:05] depends on whether you want to do it linear or not [23:54:08] then for text node take text, for elements take getAttrs() [23:54:43] superm401: btw, since you need to end up with 1 push into the assertion queue, I guess you'd build up a huge object literal and compare it at once, so there is a diff with context. [23:55:11] well, huge, depending on what it is fed :) [23:55:34] this is going to be a useful utility in other tests [23:56:38] Yep