[17:21:33] Hello chrismcmahon : I wanted to give you a quick update on our plans for today's "double-deployment" for AFT5 and Page Curation. We are now doing code review and last minute fixes on both extensions, then we plan to scap them both together to test.wiki, sometime after 11am PT. Assuming they both test well, we plan to deploy both extensions together to production sometime after 12pm PT. So it would be great to have your help in testing both [17:21:33] applications during the next few hours. [17:21:54] hi fabriceflorin got it, thanks [17:22:40] fabriceflorin: what's such a deal killer with the aft stuff that it needs to jump the train? [17:22:46] chrismcmahon: Cool. Note that the bulk of today's double-deployment will be on the Page Curation side, as outlined here: https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/PageTriage,n,z … The AFT5 changes are minimal, and do not affect article pages, nor do they conflict with Page Curation, so we don't expect any issues. Let me know if you have any questions about this plan. [17:23:48] Hi tewwy : A lot of the key features we wanted to release for AFT5 a couple weeks ago didn't make it to the platform train, so we don't want to wait an entire month to make them available. [17:24:46] fabriceflorin: the reason I'm asking was that I originally asked the PageTriage stuff to go directly to english. Has the scope crept up that we must test on test2 before english deploy? [17:26:41] tewwy: We only plan to push to test, not test2, as outlined above. Note that most of the AFT code was approved earlier, but for some reason wasn't merged due to Matthias's vacation. So we view this as a very low risk. [17:27:30] fabriceflorin: well you have to push to test to stage. But I didn't think the changes warranted testing on test before okaying release to the cluster [17:28:59] the act of staging makes it go onto test, but I didn't think we need to block to test on test just for a few bug fixes. [17:29:02] tewwy: The Page Curation changes are pretty extensive, so I think it would be prudent to test them on test.wiki before going to production. But we don't have to spend a lot of time doing that, since they have been tested on prototype. [17:30:01] fabriceflorin: okay, just don't spend too long. I assume asher has them unstuck on db [17:31:18] for the UI/skin folks around, you may or may not be aware of, and caring about http://www.wikipediaredefined.com/ [17:35:17] fabriceflorin: I'm fine with this then. Just try not to spend too much time deploying. The priority is the RFD template and stuff to set that up. [17:37:40] fabriceflorin: I'm here ;) [17:37:45] tewwy: Sounds good. We'll move as swiftly as possible, without compromising quality. My hope is that we can be done by about 1pm PT, assuming all goes well. [17:38:32] Thanks, matthiasmullie ! Kaldari has a couple Gerrit revisions for you to look at. [17:38:42] https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/PageTriage,n,z [20:09:39] fabriceflorin: quick question if you're around: I know Page Curation actions are being specifically logged, but is there supposed to be any access to that log from the UI? I'm guessing not, but I want to double-check. [20:27:38] chrismcmahon: Sorry for not responding sooner, juggling lots of balls today ;o) [20:27:59] np [20:28:15] First off, I'm happy to say that both AFT5 and Page Curation are now up on testing on test.wikipedia.org [20:29:45] hmm, I have a hiring interview in 1 minute for half an hour [20:29:55] Second, I'm afraid we don't currently have an activity log for Page Curation. That feature should be available in coming weeks, as specified on Mingle: https://mingle.corp.wikimedia.org/projects/ee/cards/70 Though there is a table that tracks whether an article is reviewed or not, it doesn't currently track individual actions. [20:31:04] chrismcmahon: No worries, we don't plan to test much on test, and could be on production by the time you get back. So you could test then, to confirm that all the templates work as intended (it's really hard to test them anywhere but production right now). [20:33:11] jeremyb: in bash, how do you get the dir the script is running from? Is it something like $DIR (just a guess) ? [20:33:22] er sorry [20:33:30] that I mean the dir the script lives in [20:33:51] where it's running from would be $PWD I suppose [20:34:15] but what's the var for where the script lives? [20:34:26] http://stackoverflow.com/questions/59895/can-a-bash-script-tell-what-directory-its-stored-in [20:34:36] MartijnH: MAn, two seconds faster than me [20:35:55] kaldari: "$(dirname "$0")" [20:36:03] kaldari: that might give you a relative path though [20:36:26] thanks [20:36:40] so you could do something like "$(pwd)/$(dirname "$0")" [20:37:28] geez, you'd think they'd come up with something simpler [20:37:34] kaldari: actually i'm second guessing myself. have to run in the subway now, maybe i'll have a couple mins later [20:37:50] stackoverflow recommends DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" [20:37:59] kaldari: well also depends how portable you want it to be [20:38:30] I just need to have a bash script call a PHP script in the same directory [20:38:40] oh [20:38:54] so, if one's in $PATH then they both are. [20:39:15] neither of them are necessarily in $PATH [20:39:37] right [20:39:42] and I don't have permission on the machine to put them somewhere better [20:39:43] but if either one is then you know they both are [20:39:52] what machine anyway? [20:39:56] fenari [20:40:05] you *do* have permission ;) [20:40:21] is this for clear l18n cache? [20:40:26] yeah [20:40:40] yeah, we should just get it installed systemwide [20:40:42] l10n? :) [20:40:53] marktraceur: i can't remember damnit ;P [20:45:20] kaldari: yeah, my original is fine. forget about the $(pwd) [20:45:30] thanks [20:45:58] so, make it: exec "$(dirname "$0")"/nameofotherthing [20:46:04] or: exec php "$(dirname "$0")"/nameofotherthing [20:46:08] kaldari [20:46:20] * jeremyb runs away. will poke you about making it systemwide later ;) [20:46:46] (exec is assuming that's the last line of the bash script. you're not then yielding back for bash to do something else later) [20:49:25] it seems to be working now [21:11:28] chrismcmahon: In case you are done with your interview, we are now live on production with new versions of Page Curation and AFT5! Would love your help in confirming we didn't break anything, as discussed in yesterday's meetings ;o) [21:12:42] fabriceflorin: almost done :) [21:13:02] chrismcmahon: Cool. Let us know what you find out. [21:26:25] fabriceflorin: things look good after a cursory look. I see you were out creating a delete-able test page or two [21:30:19] PRODing works [21:32:13] nice spinner kaldari :) [21:32:27] thnaks [21:46:21] kaldari: when are you doing the CN 2.1 deployment? [21:46:32] good question [21:46:57] oh, nvm then. i thought you had it scheduled, but I didn't see on wikitech [21:47:37] it might not even be necessary, but I need to think through the 2 unsynced stages and make sure it would still work in both cases... [21:48:08] wikis running newer CN than meta and wikis running later version than meta [21:49:01] since the 2.1 updates are mostly to banner and Geo loading and not the meta infrastructure, I'm thinking it might not be a problem. [23:03:58] * jeremyb waves kaldari [23:06:36] * jeremyb PRODs kaldari ? [23:07:10] welp, poke me when you're back [23:13:04] hey gwicke [23:13:46] hi liangent [23:13:59] I thought just now, that how will parsoid cooperate with lua [23:14:27] we can link to it directly [23:14:39] first, lua modules may generate wikitext and will pasoid be able to handle them [23:14:42] and we'll produce a libxml2 DOM [23:14:49] which can also be exposed to Lua of course [23:15:12] so every parser-interacting lua module must be written twice? [23:15:21] one for php parser and another for parsoid [23:15:29] hmm- why would that be so? [23:16:01] from the parser's point of view calling lua is not that different from calling an extension [23:16:25] will the ppframe-like structure still be there? [23:16:49] we'll try to emulate that if needed [23:17:08] we did not really look into the details yet [23:17:22] hmm and there may be some other extensions depending on it [23:17:23] hope to flesh that out when Tim is here in September [23:17:57] there are really nasty low-level hooks into the PHP parser internal state [23:18:50] I guess your team and lua's should make a more abstract model for lua modules... [23:19:53] the Lua interfaces I have seen so far didn't look that bad [23:20:06] but I last looked at it in June [23:21:22] I definitely hope that we'll manage to define a narrow interface between extensions and the parser [23:23:20] btw do you have an idea about the progress of LQT? [23:40:51] liangent: Dead, as far as I know.