[15:12:29] why doesn't usability.wikimedia have 'E-mail me when a page on my watchlist is changed' enabled? [15:20:04] No idea [15:21:47] Ah it's off by default and enabled on specific small wikis [15:22:01] Since strategywiki has it, it should be safe enabling it on usabilitywiki too [15:23:20] Enabled now [15:53:31] did you reach home all right RoanKattouw? [15:53:55] Yeah [15:54:00] Had to try not to fall asleep on the bus [15:54:09] Went to sleep at 6, woke up at 4:30 :P [15:54:28] But that was intended, had the alarm clock set for 5:50 cause I had an exam [15:54:41] did you fly through Heathrow this time? [15:54:59] Yeah it was real smooth too [15:55:27] nice [15:55:35] Walked straight off one plane onto the other, sat at the gate for like 2 mins [15:55:49] how's your availability rest of the week and next week? [15:56:03] Excellent [15:56:13] Apart from the fact that I'm about to leave in the next 15 mins or so :P [15:57:09] did you have a scheduled presentation early next week? [15:59:04] No? I do have an oral and a written exam next week [16:01:26] i thought you had project presentation with your partner, no/ [16:01:28] ? [16:01:57] Yeah that's the oral exam [16:03:39] if your week is clear, that's great news for us [16:03:56] we still have a quite few stabilization of the release to do [16:04:08] hopefully we can start another round of testing including I [16:04:12] IE tonight [16:04:34] Yeah I saw the Calcey bugs, I'll go through them later [16:06:42] will u be back online later today? [16:06:47] Yeah [16:06:56] great [16:06:58] ttyl then [16:07:09] Not sure what time yet, probably in about 2 hours [16:07:16] k [16:07:23] trevor wanted to talk to you yesterday [16:07:33] he will be happy to see you online :-) [16:07:48] Yeah I went to sleep at 9 AM PT, so I guess that didn't really work out [16:08:50] it happens to me after the travel from europe too [16:09:39] Yeah I can prevent it if I want to by just staying up longer, I did that last time. But this time I wanted it to happen because I had to get up ridiculously early anyway [19:46:47] RoanKattouw: what flag do I pass to make in order to force it to recombine things? [19:47:15] make -B [19:47:21] thanks [19:48:59] *RoanKattouw wonders whether wikiEditor.templateEditor.css ever existed [19:50:53] adam_miller: You added wiki [19:51:18] You added wikiEditor.templateEditor.css to the CSS files list in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/60936 but never added the file itself. Do you still have it somewhere? [19:51:47] i think i started that direction, then saw how you were placing everything inline [19:51:55] Ah right [19:52:00] So the reference can be deleted then? [19:52:11] (It's 404ing now and will be rerequested on every page view) [19:52:20] yeah, didn't know i added the reference [19:52:56] it probably should be separated eventually [19:54:35] Yeah like build the file with PHP [19:54:45] It still needs to be inline from the browser's point of view [20:00:44] TrevorParscal, or RoanKattouw - is there a way to specify that an encapsulated toolbar action should split selected text on line break and act on each line, rather than the entire block of selected text? [20:01:16] Maybe with the regex function... [20:01:28] It sounds like something that should maybe be an option [20:01:33] Are you thinking list buttons? [20:01:41] indent button [20:01:47] Ah right [20:02:06] like if you have list, and you select it all, it should indent each line [20:02:08] I'll add an option for that in the toolbar code later, still processing bug reports right now [20:02:08] rather than just the first [20:02:31] there's a bug related to that which was assigned to me [20:02:43] Which one? [20:02:46] want to point me to the code and let me have a go at implimenting it? [20:02:55] https://bugzilla.wikimedia.org/show_bug.cgi?id=22209 [20:03:03] Sure, it's scary browser-specific code though :) [20:03:20] OK so it should be an option in the options object implemented similarly to ownline [20:03:37] is this in wikiEditor.toolbar.js? [20:03:53] It needs to be supported by jquery.wikiEditor.js:427 (encapsulateSelection function), twice (IE and Firefox) [20:04:07] Or well, maybe this is something you can do before the browser-specific part [20:04:54] Something like .replace( /\n./g, '$1' + pre) or whatever should do [20:05:42] You actually don't even need support in jquery.wikiEditor.toolbar.js BTW, gets passed through automatically [21:06:20] nimish_g: Would you say we have enough data to turn off ClickTracking altogether? [21:06:50] It's pulling in JS even for non-beta users and rather than fixing that I figured I might as well turn it off if we don't need it any more [21:19:24] clicktracking on leftnav and old toolbar? [21:19:36] RoanKattouw: yeah, I think we have enough on leftnav and old toolbar [21:20:19] I'm talking about disabling it wholesale [21:21:14] hm...I think we should discuss that Monday when paru's in the office too [21:21:45] OK [21:21:51] I can just fix ClickTracking I guess [21:34:34] what needs to be done for it? [21:35:06] It needs to be not enabled on every friggin' pageview ever [22:02:18] RoanKattouw: how was your flight? [22:07:15] It was good, British Airways' service is awesome [22:11:11] I actually managed to sleep the night I planned tonight, 6 PM - 4:30 AM [22:26:57] any progress on the beforeSelection? [22:27:12] both, the bug I found and also the IE stuff [22:27:34] Going through some Calcey bugs right now [22:27:38] No progress, sorry [22:27:50] Naoko said you wanted to talk to me yesterday, was it about that? [22:28:19] so - priority wise, we should sort of decide on this functionality in IE vs getting other bugs fixed [22:28:47] True [22:28:50] I'm inclined to say we should get other bugs fixed, and even let calcey have at testing with IE, and just let them report the beforeSelection breakage [22:28:57] we will be fixing it anyways [22:29:05] Yeah [22:29:09] It's really just that [22:29:24] We can even tell them like we know such and such is broken so don't file a dozen bugs about that kthx [22:29:44] yeah - especially the kthx part [22:30:29] nkomura: so, we are thinking we want to focus on fixing bugs that calcey found over adding this missing feature in IE [22:30:46] That's not necessarily what I'm saying [22:30:47] it's a rather minor feature - it's just the bit that updates the TOC when you move the cursor in the editor [22:30:55] I'm just saying that's what I was doing ATM [22:31:14] Sorry - didn't mean to misrepresent you [22:31:41] No worries; I do agree that IE compat should have priority and you've been nagging me about it for days [22:32:07] whatever makes sense for you guys [22:32:17] I'm saying, we need to solve allot of issues in a short period of time, so if you have to choose between this feature in IE and blocker - major bugs in all browsers... I'm choosing the bugs. [22:33:01] as calcey is a day ahead of us [22:33:19] Ah yeah it's Saturday night over there already [22:33:30] but their monday is our sunday [22:33:35] I think we should divide bugs into broken feature vs. missing feature - broken comes first, then we fill in the missing stuff [22:34:01] so we have another opportunity of window, if you feel another rev can be ready later today or before sunday [22:34:15] that makes sense [22:34:27] so let's see where we are at later today [22:34:35] nkomura: what if we had them do IE testing on their monday - knowing there's that missing feature [22:34:46] it doesn't break anything, it's just not a slick [22:34:58] if we communicate the missing features clearly [22:35:09] i think it'd be good approach [22:35:24] Yeah [22:35:28] that way we can get an idea as to how bad the IE situation will be - we can better judge timelines for deployment if we have that info [22:35:31] i just don't want them to test or file bugs against known issues or missing features [22:35:37] totally [22:35:41] Oh also, we should let Calcey poke at the deployment wiki instead [22:35:44] As that runs wmf-deployment [22:35:46] I can write them an email detailing that.. [22:35:57] RoanKattouw: is that up-to-date? [22:36:02] Yeah IMO they should not file bugs about things we already know [22:36:02] I was updating the prototypes [22:36:08] but not the deployment one [22:36:12] Not yet, I've been making all kinds of commits, I'll update it [22:36:39] RoanKattouw: it's OK if they submit one bug, but they often seem to submit multiple bugs and we have to later mark them as duplicates [22:37:03] Yeah [22:37:25] Also, I'm not fully impressed by the quality of their bug reports; if we do want stuff we already know about in BZ we should file it ourselves [22:37:33] brokenness / missingness should be in the bug system - we should be the ones adding those bugs, and we should let them know, btw - bug one seven niner is KNOWN, please do not duplicate it. [22:37:50] ha ah - you beat me to it [22:37:59] but I threw a niner in there, so I win [22:38:01] I think [22:38:03] Yeah [22:38:05] Absolutely [22:38:32] I've actually filed quite a few bugs for myself; a large portion of the API bugs are filed by me and assigned to me [22:39:25] *TrevorParscal hands roan a cookie for being a good developer [22:39:40] Good procrastinator, more like [22:40:00] RoanKattouw: you can start cc'ing calcey on the bugs you filed against yourself [22:40:16] Yeah I didn't file any of those for usability yet [22:40:23] Will CC them if and when I do [22:40:29] thanks [22:44:08] so TrevorParscal, may I count on you to write up test instruction summary to calcey? [22:45:39] yes [22:45:46] I will do it before I go home [22:45:52] thank you [22:46:30] *RoanKattouw updated the deployment wiki [22:50:31] awesome! [23:02:04] RoanKattouw: could you file the bug for the IE before selection issue? [23:02:45] Sure [23:02:59] thanks! [23:03:22] OK so now let's actually make the deployment wikis reachable rather than having them redirect to the normal prototypes [23:03:48] yeah, that's a good idea [23:03:55] I was just noticing that was still the case [23:03:59] like 2 seconds ago [23:04:27] Of course it takes ages to load... damn this box is slow [23:04:35] ugh [23:04:57] I almost want to disable all wikis except the one they are pounding on - just to not waste so much of their time [23:05:02] but.. that would suck for other reasons [23:05:08] OK working now [23:05:21] Deployment wikis will still be slow initially due to empty caches [23:05:37] http://prototype.wikimedia.org/deployment-en/ [23:06:07] I never removed the cached images [23:06:12] which caches do you mean? [23:06:14] APC? [23:07:12] File cache mostly [23:07:17] And yes, APC [23:08:56] this should be deployed with the form-based dialogs globally disabled and not user enableable [23:09:35] 'templateEditor' => array( 'global' => false, 'user' => false ) [23:09:39] or... [23:09:52] Yeah I'll poke at the settings [23:10:09] $wgWikiEditorModules['templateEditor'] = array( 'global' => false, 'user' => false ); [23:10:25] just add that after the inclusion [23:10:38] I just deployed two changes on the live site that should prevent it from loading our JS on every page view ever [23:11:02] cool [23:11:21] OK that seems to have worked [23:11:33] Should save some bandwidth, annoyances on older browsers, etc. [23:11:42] awesome [23:11:56] our plugins on every page, meaning even on monobook? [23:12:02] they were loading them there too? [23:13:55] Yes [23:14:07] I fixed that on trunk, so I kind of hack-backported that to deployment [23:14:16] ok [23:14:21] Because deployment still has the old structure and my fix was in Vector.hooks.php [23:14:32] what did that do to our bandwidth / request load? [23:14:35] before / after fixing [23:14:53] Not sure, lemme check the graphs [23:15:00] Only did this like 5 mins ago [23:16:33] on the cluster? [23:16:47] Yeahg [23:17:04] Can't tell the difference in bandwith/reqs though, it's in a major downward trend now [23:17:31] It's midnight in Europe and 6 PM on the East Coast so both of those regions have probably stopped hitting Wikipedia [23:18:02] http://www.nedworks.org/~mark/reqstats/reqstats-daily.png [23:19:56] yeah, I've been monitoting that for a few minutes now [23:23:05] I'm getting jquery and mw not defined errors on deployment [23:23:30] Ugh [23:23:42] I'll svn up MW on deployment [23:24:14] thanks for being the sysadmin [23:25:10] Hm looks like it was already updated, will poke [23:26:08] Loaded the main page --> 28 error :O [23:26:10] +s [23:30:30] RoanKattouw: maybe I will report the bug about the TOC [23:30:42] give you some time to get deployment solid [23:31:03] Sure [23:31:06] Thanks [23:31:16] ha ha [23:31:20] you seem busy [23:31:22] :) [23:34:03] Yeah for some reason deployment isn't loading js2stopgap.js [23:34:21] yeah, that's what I noticed as well [23:34:24] Ah it doesn't *exist* on deployment, that explains [23:36:56] looks like a good excuse [23:38:03] svn: Use --force to override this restriction [23:38:10] And I did pass --force *hate* [23:45:47] TrevorParscal: There's also some brokenness in the dialogs because they haven't been updated to use the new selection functions yet [23:50:15] hmm [23:50:43] I'll work on that tomorrow; it's nearly 1 AM and I've been awake since 4:30, I should call it a day [23:50:47] ok [23:50:52] thanks man! [23:50:55] you rock