[03:22:44] New patchset: Jeroen De Dauw; "Re-apply "Added EntityId and EntityIdParser in JS"" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/43989 [07:00:19] New patchset: Jeroen De Dauw; "Re-apply "Added EntityId and EntityIdParser in JS"" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/43995 [07:00:42] Change abandoned: Jeroen De Dauw; "wtf gerrit is wtf" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/43989 [07:01:18] New patchset: Jeroen De Dauw; "Fix test" [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/43996 [07:01:27] Change merged: Jeroen De Dauw; [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/43996 [07:03:04] New review: Jeroen De Dauw; "This still has some UI issue. Although values are saved correctly, they are not shown in the widget...." [mediawiki/extensions/Wikibase] (master); V: -1 C: 0; - https://gerrit.wikimedia.org/r/43995 [07:54:14] omg, double nyan all the way [07:54:14] !nyan [07:54:14] !nyan [07:54:14] ~=[,,_,,]:3 [07:54:15] ~=[,,_,,]:3 [08:26:24] Hi DanielK_WMDE and JeroenDeDauw! On test, we now have a wmf7 client and a 2013-01-14 repo. I get a php error when starting the old pollForChanges script. [08:26:35] "PHP Fatal error: Cannot instantiate abstract class Wikibase\EntityDiff in /srv/testclient-en/w/includes/db/ORMRow.php on line 529" [08:26:52] Any ideas? [08:27:18] abstract??? [08:27:21] It is not [08:27:30] Silke_WMDE: running old code? [08:27:39] yes, wmf7 [08:27:40] With new serialization? [08:37:05] ok, it's working now. [08:42:10] JeroenDeDauw: are you *already* up, or still?... [08:42:30] DanielK_WMDE: Been up since 03:30 [08:42:33] !nyan [08:42:33] ~=[,,_,,]:3 [08:43:10] JeroenDeDauw: oh, i see, you are living by Mumbai time now! [08:44:05] Silke_WMDE: hm... how did it get fixed? [08:44:37] I truncate wb_changes [08:44:38] this could be a real compatibility problem between wmf7 and wmf8 [08:45:09] Silke_WMDE: ...and it still works if you edit the repo? [08:45:22] if wmf7 can't load the wmf8 serialization, we are in trouble :/ [08:45:25] hrm [08:45:49] one more reason not to use serialized objects, but just serialize array structures. or use json [08:46:55] hm [08:47:10] a mometn ago the client saw the changes, now it dies not. [08:47:15] äh it does not [08:48:39] * Silke_WMDE is citing JeroenDeDauw: "This is like saying 'My Windows 95 can't oopen...'" [08:50:00] yea, it is [08:50:02] but [08:50:49] JeroenDeDauw: client wikis wil typically be one deployment cycle behind. we have to account for that, especially wrt change propagation and the API. [08:51:55] DanielK_WMDE: "one more reason not to use serialized objects, but just serialize array structures. or use json" that is so completely besides the point ;) [08:51:55] Silke_WMDE: can you look at the logs from runJobs? [08:52:13] JeroenDeDauw: is it? how? [08:53:03] the changes table contains serialized data. if that data uses classes that did not exist before, or were abstract before, then the client can't process them. [08:53:07] DanielK_WMDE: this issue can just as well occur if you have an array or josn [08:53:59] JeroenDeDauw: sure, compatibility issues can arise, but it's easier to make the code robust against that. if a class used in serialization simply isn't there, you can't unserialize. that's it. [08:54:42] * Silke_WMDE needs explanations [08:55:07] DanielK_WMDE: fair enough. Though if we have a map between types and handling classes, our senior developer guy starts shouting about having way to much indirection :D [08:55:56] Do I configure client and repo as if both had 2013-01-14??? [08:58:12] JeroenDeDauw: ...possibly, though actual (not potential) use cases do tend to convince him after a while (he's stubborn, i know) [08:58:54] Silke_WMDE: no. you did it right. you uncovered an incompatibility that will hit us in production tomorrow. thanks :) [08:59:18] DanielK_WMDE: I'm not sure [08:59:39] Are we trying to use dispatchChanges or pollForChanges?? [09:00:10] Silke_WMDE: pollForChanges. dispatchChanges can't be used until the clients are running wmf8. that will only happen in 2 weeks [09:00:19] ok [09:00:26] currently, repo and client are running wmf7, but tomorrow, we are deploying wmf8 to the repo [09:00:33] yes [09:00:48] Send a mail to internal list [09:00:48] Silke_WMDE: the issue seems to be that wmf7 can't read changes that wmf8 wrote to the database [09:00:56] me thinks maintaining compat in two directions sucks [09:00:57] i'm not sure what to do about it right now... [09:01:10] Esp between many different revs [09:01:21] JeroenDeDauw: do you see a way around that? [09:01:30] DanielK_WMDE: Go back to pollForChanges for wmf8? [09:01:35] Yeah, don;t deploy using different versions of lib [09:01:40] Silke_WMDE: hm? how would that help? [09:02:16] I mean take your new code that was merged yetserday out of the tag? [09:02:19] Silke_WMDE: the problem is not with the dispatcher. it doesn't matter which code reads the serialized changes. it will fail because the serialization itself is incompatible [09:02:26] ah [09:02:34] ouch... [09:02:52] yea, serialized php objects in the database... [09:03:25] JeroenDeDauw: i'm thinking: change the serialization to json, backport the corresponding de-serialization to wmf7 [09:03:43] DanielK_WMDE: Have you tried it out yourself? I am never 100% sure I am configuring what you have in mind. [09:04:02] JeroenDeDauw: "don;t deploy using different versions of lib" - that would mean all wikis have to be updated at the exact same time. this is not going to happen, ever. [09:04:33] Silke_WMDE: i havn't tried yet, but i will in a minute [09:12:12] JeroenDeDauw: hm, when and why is an EntityDiff used directly in the serialized change? [09:12:19] i only see ItemDiffs in my database [09:28:19] Abraham_WMDE: please have a look at my last mail to the list. [09:28:31] Damn it. [09:28:35] DanielK_WMDE: sec [09:28:38] Something has checked out the old repos. Again again [09:36:36] 42 Warning: array_key_exists() expects parameter 2 to be array, boolean given in /usr/local/apache/common-local/php-1.21wmf7/extensions/Wikibase/client/WikibaseClient.hooks.php on line 429 [09:36:41] I'm guessing that must be fairly replicable [09:37:05] Reedy: that happens when deserialization of rc_params fails [09:37:12] ...usually because it got truncated [09:37:13] ohhh [09:37:23] lol [09:37:30] wfSupressWarnings()? [09:37:34] Or is that asking for trouble [09:37:52] that IS asking for trouble. [09:38:08] no, we should just check that unserialize actually returns an object [09:38:37] Reedy: we'll need to backport some changes to wmf7 olater today anyway. i'll make a patch for this issue. [09:38:45] Great [09:40:42] just FYI: I'm updating and enabling IME for ULS in wikidata.org [09:41:27] I should be around till 7pm CET and then back around later on [09:41:42] hi [09:41:57] hi aude [09:42:10] New patchset: Henning Snater; "suggester jQuery widget: Option to adapt letter case" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44010 [09:42:10] New patchset: Henning Snater; "Only adapt first letter in AutocompleteInterface" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44011 [09:42:16] we can check rc_params although wonder why it's still happening, if it is? [09:42:47] and i shall try old client and new repo to confirm issues [09:43:18] aude: i don't think it's still happening [09:43:31] but the broken entries are still in the db [09:43:36] so we still try to render them [09:44:07] aude: we should just never leave the result of unserialize unchecked. we should always assert that it's really what we expect (an object or array or whatever) [09:44:46] DanielK_WMDE: true [09:45:36] can you make a small patch that will use trigger_error(..., E_WARNING) to issue a meaningfull message when unserialize fails? [09:46:09] i do think we should still generate a warning. but it should be meaningful, and we should not blindly use the broken value in subsequent code. [09:46:25] Reedy: do you agree --^ [09:46:27] ? [09:47:21] New patchset: Aude; "check rc_params is array in client" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44012 [09:47:46] wtf. the mediawiki/extensions.git meta repo seems to have the old Wikibase ones as submodules [09:47:48] * Reedy frowns [09:47:49] we could put a debug log there [09:47:57] ^ probably the better way [09:48:03] we can log it to file if needed [09:48:04] if the hook returns false, then [09:48:09] it simply does not render [09:48:12] it skips it [09:48:40] question is if we want wfDebugLog( __CLASS__ ....) or wfDebug() [09:48:48] no, debug log is not the right thing [09:48:54] probably the firs for consistency [09:48:54] we are hitting a real error here [09:48:59] that should not be silent in production [09:49:02] it should show in some log [09:49:08] mmmm...... [09:49:23] even wfWarn is too weak [09:49:36] actually, I was told off for using wfWarn in such a situation recently [09:49:50] and only got my code merged after is changed it to use trigger_error [09:49:58] * DanielK_WMDE is trying to remember where that was, but it was in core [09:50:22] don't think that is right way here [09:50:24] Reedy: how would you ever notice that there is something to log? we are talking about data loss here. this should not be silent [09:50:38] aude: why not? [09:50:43] People complaining that stuff isn't happening right ;) [09:50:47] DanielK_WMDE:we can log [09:50:55] I fixed a bunch more of schemas on the wikis [09:50:59] but not fail visibly to the user [09:51:02] And it's snowing again [09:51:04] aude: that'S what trigger_error does. it logsw [09:51:16] mmmm, ok [09:51:36] aude: trigger_error with E_USER_WARN is not visiuble to the user on a production system. it just logs [09:51:49] it's actually the only reliable way to log an error in production, afaik [09:52:13] Reedy: cool! can dewiki and frwiki be fixed on the fly? [09:52:14] ok [09:52:20] New review: John Erling Blad; "There were 9 errors:" [mediawiki/extensions/Wikibase] (master); V: -1 C: 0; - https://gerrit.wikimedia.org/r/43995 [09:52:34] DanielK_WMDE: I think so. Might just cause a bit of replag for 10-15 minutes while the table is locked [09:52:52] hmhm [09:52:57] don't do it at peak time :) [09:53:29] aude: actually, i'd like to change wfWarn to always log, even in production. but that's not the current semantics. [09:53:40] (as I learned the hard way) [09:57:14] New patchset: Aude; "check rc_params is array in client" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44012 [09:57:29] https://gerrit.wikimedia.org/r/44015 [09:57:29] grrr [10:10:59] JeroenDeDauw: can you tell me whan an instance of EntityDiff is used instead of an ItemDiff? Is this when editing Properties? [10:13:51] New review: Daniel Kinzler; "looks sane, but havn't tested. poke me later if i forget." [mediawiki/extensions/Wikibase] (master); V: 0 C: 2; - https://gerrit.wikimedia.org/r/44012 [10:14:56] uh... [10:16:37] we have no wmf8 tag at all? [10:17:00] so i'm supposed to use 2013-01-14 i guess [10:20:07] yes [10:20:07] DanielK_WMDE: we have a tga [10:20:18] DanielK_WMDE: that's the tag, right. [10:20:36] Abraham_WMDE: but it's not called anything with "wmf8" [10:20:47] why not? [10:21:04] it would make sense to tag stuff in a way to refers to the cycle it was deployed in [10:21:16] DanielK_WMDE: see Anja's google doc [10:21:16] that's how we did it in the past, too [10:21:23] hm. [10:21:43] DanielK_WMDE: we never name the tags with "wmf..*" [10:22:10] DanielK_WMDE: I suggeest to do so, but we decided to stay with the "date" [10:22:31] you are right, we only did that with the branches [10:22:39] and we don't have a branch for wmf8 yet [10:22:49] i find this rather inconvenient [10:23:08] it requires me to find out when a certain version of mediawiki was deployed to find the corresponding wikidata tag [10:23:18] ...and even then, it's a guess [10:29:44] DanielK_WMDE: i can make a branch [10:29:54] that's easier for doing backports [10:30:08] aude: yea, we'll need it anyway [10:30:11] no rush, though [10:30:17] i found the version i need for testing now [10:30:53] * aude could use a branch [10:32:37] New review: Siebrand; "See inline comments." [mediawiki/extensions/Wikibase] (master); V: 0 C: -1; - https://gerrit.wikimedia.org/r/43583 [10:32:39] ok, we have mw1.21-wmf8 branch for wikibase [10:35:58] ok, got wikis setup [10:40:13] DanielK_WMDE aude OK, on dev-8 you need to purge the clients cache manually, then it works [10:40:30] just pushing the changes doesn't work [10:40:40] Silke_WMDE: but the rows injected into recentchanges will also be broken, i think [10:40:43] can you check that? [10:41:10] so far so goo [10:41:11] d [10:42:10] Hm, I think the changes that are *really* troublesome are the ones that modified a property [10:42:18] we don't have that enabled on wikidata.org, right? [10:42:21] hmmm.... wmf7 client and wmf8 repo works [10:42:23] for me [10:42:28] no we don't [10:42:38] in recent changes I dont see my changes [10:42:47] * aude using pollforchanges though [10:42:54] the dispatcher should also be good [10:42:57] * Silke_WMDE too [10:43:28] (diff | hist) . . Japan (Q17)‎; 05:42 . . (+25)‎ . . ‎69.164.222.250 (Talk)‎ (‎Added site-specific [enwiki] link: Japan) [10:43:31] yup [10:43:47] errr. [10:43:51] confused, that's my repo] [10:44:37] (eltér | történet) . . Japán (Q17); 05:41 . . 69.164.222.250 (vitalap) (Language link added: de:Japan) [10:44:44] might have to rebuild my localisation [10:46:24] New patchset: Henning Snater; "Moving snak type selector to left of the value input" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44040 [10:55:36] aude, Tobi_WMDE, Silke_WMDE: please specifically test modifications of *properties* [10:55:44] when testing locally, these seem to be the only ones that fail [10:55:56] but they always fail. or rather, make pollForChanges fail. [10:56:09] DanielK_WMDE: language links work for you??? [10:57:06] Silke_WMDE: havn't tested that, i was huntung a fatal error. and got it. [10:57:22] pollForChanges simply *dies* if it encounters a change to a property [10:57:37] DanielK_WMDE: just added a statement to my wmf8 repo and my wmf7 pollforchanges says: "One new change was found" [10:57:45] ...and thus obviously doesn't handle any subsequent changes to items, so links don't get purged [10:57:53] pollForChanges doesnt see anything here [10:58:06] Tobi_WMDE: not statement. modify the property itself! change its label! [10:58:20] as in Property:P23 [10:58:30] *boom* [10:58:35] ;) [10:58:37] exactly [11:00:48] Denny_WMDE et.al.: pollForChanges dies when property definitions are modified. but properties are not live yet. i'll keep checking to see if there are other problems. [11:00:51] if it's just properties, then we should be ok [11:00:57] yea [11:01:00] !nyan [11:01:01] ~=[,,_,,]:3 [11:01:02] would be nice, obviously to fix [11:01:03] still scary, though [11:01:07] or avoice [11:01:10] avoid int he future [11:01:27] aude: we could try to hot fix it by making EntityDiff not abstract in wmf7. [11:01:33] No jeblad? Or is he just hiding from irc? [11:01:35] maybe removing the abstract keyword is all it takes [11:02:00] ok, i'm afk for a bit. lunch. [11:02:03] ok [11:02:07] * aude pokes around more [11:02:24] DanielK_WMDE: and I now know why I was not having troubles yesterday while testing: I was testing it with experimental:false. which is ok I think. [11:02:53] New patchset: Jeroen De Dauw; "Re-apply "Added EntityId and EntityIdParser in JS"" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/43995 [11:04:41] It wasn't me! [11:04:48] but as long as experimental stays false, there should not be any problems with deploying wmf8, right? [11:04:50] I haven't done anything! [11:04:57] Reedy: here's our own Jeblad_WMDE [11:05:04] ...and it was probably Tobi_WMDE ! [11:05:26] !nyan [11:05:26] ~=[,,_,,]:3 [11:05:32] Tobi_WMDE: Shall I disable experimental stuff on test? [11:05:35] Tobi_WMDE: enwiki is a great place to experiment [11:06:01] Silke_WMDE: yes [11:06:10] Reedy: indeed!! [11:06:39] Reedy: reason to turn on the Awesomeness extension there [11:07:34] Silke_WMDE: yes, try it. but i think there is still something else wrong on test [11:14:56] what JeroenDeDauw says. [11:35:01] Reedy: something for you https://gerrit.wikimedia.org/r/#/c/44045/ [11:38:15] New patchset: Henning Snater; "(bug 43867) Prevent entity selector widget from resetting entity" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44046 [11:39:34] Tobi_WMDE: i think with experimental mode off, we should be fine. [11:47:48] New review: Daniel Kinzler; "This addresses bug 43978" [mediawiki/extensions/Wikibase] (master); V: 0 C: 2; - https://gerrit.wikimedia.org/r/44012 [11:49:56] Denny_WMDE: if we disable experimental stuff on test, where do we test experimental stuff? [11:50:11] or rather, have people test it? [11:52:21] JeroenDeDauw: noooooooooooooooo! [11:52:28] you started the ultimate bikeshed [11:52:30] :D [11:52:37] Lydia_WMDE: profit! [11:52:41] for sure [11:53:06] Lydia_WMDE: this is my evil masterplan to end the ultimate bikeshed with "why do you hate freedom so much?" [11:53:18] haha [11:58:23] DanielK_WMDE: on dev [12:04:54] New patchset: Aude; "Remove abstract stuff from EntityDiff" [mediawiki/extensions/Wikibase] (mw1.21-wmf7) - https://gerrit.wikimedia.org/r/44048 [12:07:08] New review: Aude; "this seems to work but is a hack" [mediawiki/extensions/Wikibase] (mw1.21-wmf7); V: 0 C: 0; - https://gerrit.wikimedia.org/r/44048 [12:07:14] DanielK_WMDE: https://gerrit.wikimedia.org/r/#/c/44048/ [12:07:21] please review and try it [12:19:53] I think I cannot run pollForChanges.php as a non-root user any more [12:26:57] Silke_WMDE_: check the file permissions on the pid and state files [12:27:13] wouldn't make sense having to run that as root [12:27:18] have you tried running it manually? [12:27:29] aude: looking into it, having another problem currently [12:27:47] for some reason, my stylepath seems to be screwed. [12:29:09] DanielK_WMDE: aude is at lunch [12:31:28] DanielK_WMDE: Yes: running pollForChanges manually as a user brings me this: "PHP Warning: file_put_contents(/tmp/WBpollForChanges_testclienten.pid): failed to open stream: Permission denied in /srv/testclient-en/w/extensions/Wikibase/lib/includes/Utils.php on line 549" [12:32:14] New review: Daniel Kinzler; "Seems to work, fine as a hot fix." [mediawiki/extensions/Wikibase] (mw1.21-wmf7); V: 2 C: 2; - https://gerrit.wikimedia.org/r/44048 [12:32:16] Change merged: Daniel Kinzler; [mediawiki/extensions/Wikibase] (mw1.21-wmf7) - https://gerrit.wikimedia.org/r/44048 [12:32:50] ah [12:32:58] no, ok, that was audes pid file [12:38:19] hm, we should check this and not just issue warning, but exit with a meaningful error message [12:46:58] New patchset: Reedy; "Followup to 36780, add new columns FIRST" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/37485 [12:48:05] New patchset: Reedy; "Followup to 36780, add new columns FIRST" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/37485 [12:49:45] ^ MaxSem reviewed it for sqliteness. Only issues were casing (fixed) and wonder why I wasn't using sqlite datatype but that's not really related to this patch [12:59:49] DanielK_WMDE: Do you know since when the pid file has been moved from /tmp to /var/run??? Makes a lot of sense, but seems to fail because the wikidata system user can't write there... [13:15:40] Silke_WMDE_: IIRC this has already been a while [13:16:59] Changes like this interesting because puppet would like to know about them, too. [13:18:47] Silke_WMDE_: it tries to use /var/run, and if it can't, it uses /tmp [13:19:11] Silke_WMDE_: it has been like this for a long time, at least since the introduction of the state file [13:19:53] you can always force the location of the pid and state file using commond line options [13:20:05] anyway, pollForChanges is going away [13:20:06] aha [13:20:13] yes [13:21:04] at leat on test, it did not run as a wikidata user script [13:21:24] now, with modified file permissions, it does [13:22:29] back [13:22:43] so, DanielK_WMDE are you confident with my hot fix? [13:23:28] Tobi_WMDE: did you or can you try my patch to make wmf7 compatible? [13:29:03] Tobi_WMDE: https://gerrit.wikimedia.org/r/#/c/43183/ is optionally needed if we opt for the dispatching change script [13:29:31] aude: and if we keep pollForChanges but run yesterday's tag ? [13:29:36] otherwise, if we use wmf8 of the extension with wmf7 core [13:29:40] and pollforchanges, it's ok [13:29:45] ok thx [13:30:07] i would double check with DanielK_WMDE [13:32:50] so, currently i see two options: 1) hu with client8 and core7, repo with repo8 and core8, or 2) hu with client7+hotfix and core7 and repo with repo8 and core8. is that correct? (assuming the tests run through well) [13:33:25] When are you guys wanting to deploy the bugfixes? [13:33:47] tomorrow with wikidatawiki if that is ok [13:34:01] err [13:34:07] Will need to be done earlier in the day [13:34:17] well, not necesserily.. [13:34:23] As it's git deploy day, so wmf8 is going out.. [13:34:48] and you would like to do whatever needs to be done to hu before that? [13:34:58] aude: verify that the issue with the crashing pollforchanges when adding/editing a property is gone with your patchset [13:35:00] Definitely for huwiki [13:35:04] and we can deploy wikidatawiki through git deploy later? [13:35:10] Yup [13:35:18] ok, got it [13:35:20] hopefully branchpoints etc should be "as normal" [13:35:40] wikidatawiki should be [13:35:56] it just looks like we need to do a small change to huwiki too [13:37:29] ok we are still checking the different versions and how they play together [13:37:37] Reedy: i am testing the patch with current repo [13:38:17] Tobi_WMDE: thanks [13:39:15] aude: i will still run the whole set of selenium tests on client+wmf7+your fix & repo+wmf8 [13:39:23] Tobi_WMDE: good [13:42:40] currently running tests on client-wmf8+core-wmf7 & repo-wmf8 [14:00:25] Denny_WMDE: the hotfix works fine on repo wmf7, so far as i can tell (and phpunit tells me) [14:00:37] * aude trying deleting & restoring items [14:07:31] New patchset: John Erling Blad; "(Bug 42778) Show Git hash in Special:Version" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44056 [14:07:33] Henning_WMDE: Tobi_WMDE i get one qunit failure but i don't think it's critical [14:07:36] jquery.ui.suggester: basic tests (1, 5, 6)Rerun [14:07:42] Detected scrollbar width. [14:08:00] at Object. (http://en-wikidata.localhost/extensions/Wikibase/lib/tests/qunit/jquery.ui/jquery.ui.suggester.tests.js:98:10) [14:08:45] OK, test is running now with audes hotfix (clients English and Hebrew) [14:09:04] also, i have experimental = false [14:09:11] Silke_WMDE_: thanks [14:12:24] Henning_WMDE: Tobi_WMDE i get the same qunit failure on master everything [14:12:34] * aude does not think it's critical [14:12:56] aude: Denny_WMDE: client-wmf8+core-wmf7 & repo-wmf8 OK [14:13:07] Tobi_WMDE: good :) [14:13:23] * aude is confident [14:14:47] * aude gets a few more qunit failures on master + experimental, but if features are experiment then i can ignore [14:15:54] now testing client+wmf7+aude's fix & repo+wmf8 [14:16:16] Tobi_WMDE: thanks [14:21:37] DanielK_WMDE: ? [14:25:59] Silke_WMDE_: I'm getting an "internal error" on test-repo [14:26:03] saying "Could not acquire 'testrepo:messages:de:status' lock." [14:26:26] sounds like the messages cache [14:27:04] Silke_WMDE_: seems it's gone now [14:27:18] Tobi_WMDE: Where's that message? I don't see it [14:27:28] Silke_WMDE_: seems it's gone now [14:27:42] it happend when clicking on "example entry" [14:29:05] Do we want to keep test without experimental features? Denny_WMDE? [14:29:23] annoying message cache [14:29:32] * aude would love to know why we get those errors on labs [14:30:03] it probably ran cronjob to restart memcached or something and then it works again? [14:30:12] possible [14:31:38] Silke_WMDE_: actually i wouldnt mind to switch experimental on on test [14:31:57] it is just that we then dont have it anywhere without experimental :-/ [14:31:59] hmm [14:32:00] wait [14:32:06] let us keep it without experimental for now [14:32:13] and as soon as we have test1 with repo [14:32:15] ok [14:32:23] we can switch it on for our test [14:39:31] Denny_WMDE: re. sorry, had to mind some family stuff here. [14:39:34] what did i miss? [14:39:46] np [14:39:58] i just wanted to say that we didnt do a sprint start meeting with everyone today [14:40:00] DanielK_WMDE: we have two options for tomorrow, both i am confident about [14:40:26] 1) the hotfix --- fine if we backport it today or tomorrow to wmf7 repo and client [14:40:46] and update repo to wmf8 tomorrow and run wmf7 + hotfix client [14:41:08] passes all tests everywhere (minus one non-critical qunit) in every combination [14:41:40] option 2) update the wikipedias + the repo to wmf 8 tomorrow (the clients would still be on wmf7 core) [14:42:03] option 2 also passes everything, except if we want to try dispatching script then we need to backport your core patch for job queue [14:42:29] * aude recommends option 1, but for any reason we have a problem with it, we can do option 2 as plan B [14:42:44] we can also 3) just deploy wmf8 without patching wmf7. the issue doesn't ocurr without experimental features enabled. it's triggered by edits to property definitions. [14:42:54] DanielK_WMDE: it does [14:42:58] i did confirm it [14:43:03] i think..... [14:43:18] with labs, though maybe it was properties [14:43:53] errrr, i did see the issue on my own setup without properties [14:44:11] * aude thinks [14:44:44] can't imagine how that would happen [14:44:53] for items, ItemDiff is used, which works fine [14:45:00] i can try once more [14:45:13] it would also happen for other non-item entitites, but we don't have any (Query stuff is defined but not oiperational) [14:45:18] New review: Jeroen De Dauw; "Lots of duplication between MultiLangConstraintDetector deriving classes. A single class can take an..." [mediawiki/extensions/Wikibase] (master); V: 0 C: -2; - https://gerrit.wikimedia.org/r/43865 [14:45:19] yeah [14:47:22] one of the problems was instantiation of an abstract class. that shouldn't be effected by whether it is experimental or not. i still do not understand why this didn't raise a problem though [14:59:26] Denny_WMDE: because that class is only used by Property objects. [14:59:43] there is no way to create Property entities when expoerimental is off [15:00:01] ok [15:00:11] DanielK_WMDE: i tried again on my own setup and it's okay without the patch [15:00:27] ok, good [15:00:34] i suppose we can just try [15:00:56] if it doesn't work, then try the hotfix [15:01:06] if that doesn't work, then update clients to wikibase wmf8 [15:01:21] * aude is fairly confident we won't have to do #2 or #3 [15:02:02] think i only had the issue on labs and hope i'm not confused or forgetting something [15:03:03] New patchset: Tobias Gritschacher; "(minor) workaround for failing qunit tests in firefox" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44057 [15:03:37] Henning_WMDE: https://gerrit.wikimedia.org/r/#/c/44057/ [15:03:43] DanielK_WMDE: it would still be nice to backport https://gerrit.wikimedia.org/r/#/c/44012/ [15:03:57] which means i need to revert the hotfix and commit them in order [15:04:01] ok, shall i write an Email with these results, or can we remember? :) [15:04:11] Denny_WMDE: an email would be nice [15:04:30] * aude is comfortable and confident with any of the options [15:04:49] New review: John Erling Blad; "This references the wrong bug. This is" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/43434 [15:05:05] if pollforchanges fails for any reason, it only means we might miss some recent changes being reported in the client due to the way pollforchanges does continuation [15:05:10] but not a big deal [15:05:26] New review: John Erling Blad; "This references the wrong bug. This is" [mediawiki/extensions/Wikibase] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/43865 [15:05:40] New patchset: Henning Snater; "suggester widget: Replace input value with suggestion list item" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44058 [15:05:41] New patchset: Henning Snater; "(bug 43867) Entity selector: Setting entity on mousedown event" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/44059 [15:05:56] aude: client+wmf7+aude's fix & repo+wmf8 OK [15:06:02] Tobi_WMDE: good [15:06:16] * aude is done testing [15:06:31] testing client+wmf8 & repo+wmf7 now [15:06:34] ok [15:07:03] * aude thinks this is the best tested deployment ever for us [15:07:27]