[00:00:03] wow... [00:01:13] line 213 is scary [00:01:21] well, 213 - 230 [00:04:05] TrevorParscal: Weird.. somebody likes to assign variables :P [00:04:20] that old code was giving me the creeps [00:05:17] ZOINKS, scoob! [00:12:25] The Orphans [00:12:26] :D [03:06:09] Go flipzagging :) [03:06:37] hey Roan [03:06:55] I guess I could commit as the non-extensiony parts of this are okay [03:07:02] er, core, I mean [03:07:44] Wait. I'm confused [03:07:56] Did you say you could merge the ext or the core changes? [03:08:06] well I could do both [03:08:11] since the ext only matters to me [03:08:16] the core is relatively stable [03:08:21] there are bugs in the ext [03:08:28] Alright [03:08:40] sorry, not thinking straight ATM [03:09:04] No worries [03:09:09] would you prefer it if I called the stashing module "PrivateUploadStash" or "UploadStash" ? [03:09:17] You're still working at this hour, chapeau for that [03:09:19] UploadStash is a lot easier to say. [03:09:23] what about you? [03:09:25] Yeah [03:09:41] 3am [03:09:42] So where does SessionStash come in? [03:09:46] I renamed it [03:09:57] Oh so that *is* SessionStash [03:10:05] (3am? Are you like on London time or something?) [03:10:44] it might be implemented in the db, so why make Session part of the name, I thought. Tim & Mark made some noises about reimplementing the more important session data so they work cross-colo. [03:10:56] Ah, right [03:11:11] I guess it would go in memcached but that's potentially lossy [03:11:11] I keep the Z timezone in Google Calendar so I have a rough idea of yours / French time [03:11:18] Right [03:11:19] RoanKattouw_away: Yes. [03:11:24] Yeah it's 4:10am here now [03:12:04] did you know you could have a secondary timezone in Google Calendar? It's pretty cool. [03:12:12] I have one, yes [03:12:16] You get one guess [03:13:51] Hmm I guess you could just say that stashed uploads are inherently private and be done with it [03:14:00] yeah [03:14:18] I started to translate "Session" into non-implementation specific language, and came close to calling it "PrivateTempUploadStash" [03:14:25] :) [03:14:28] The idea of being able to just lose that session data (cause it's in memcached) is kinda scary but in practice it hardly happens and the impact isn't very large [03:14:36] hah [03:14:57] I don't know, what else goes in session data? [03:15:01] Logins [03:15:14] you mean tokens and such [03:15:16] yes. [03:15:21] hmmm [03:15:21] Login state [03:15:32] what does login state mean [03:15:36] The fact that you're actually logged in as user X like your cookies claim [03:15:47] yeah, but in practice that's tokens no? [03:15:53] Yeah [03:16:25] ok, so a cross-colo move, if we leave sessions in a colo's memcached, means being forcibly logged out and some other state lost. [03:16:28] Conceptually you can think of it as being keyed by some hash and contain user name, edit token and maybe other things [03:16:35] Well the thing is [03:16:40] We have centralauth on the cluster [03:16:49] So I *think* we can salvage logins from that but I'm not sure [03:16:57] hrm [03:16:58] yes [03:17:03] well it depends [03:17:08] if the token is one-time, no [03:17:08] Although of course that too is contingent on the centralauth login state not vaporizing [03:17:12] if it's a hash, yes [03:17:31] er, that is to say, if it's a content hash of info in the cookie plus secret. [03:17:37] which is the normal way to do this. [03:17:50] anyway this has nothing to do with today's tasks :) [03:17:56] heh [03:17:59] Just theorizing [03:18:26] Either way, if someone's session data mysteriously disappears the behavior could potentially be more confusing than losing your upload wizard state [03:18:31] You could get logged out [03:18:55] well more than that [03:19:29] let's say you are interacting with an ajaxy part of the site, and suddenly the api requests are through Timbuktu rather than Florida. [03:19:41] so you're logged out AND logged in [03:19:55] I'm not clear on how exactly our multi-DC setup would work [03:20:02] As in, would we do memcached hits across DCs [03:20:14] And if not, how would we preserve session states across DCs [03:20:14] user props are already mirrored, we just make important sessiony data like that [03:20:21] do it in the db [03:20:31] Yeah that might be the only reliable way [03:20:34] or, have some fallback "reconstruct everything" method like we said before [03:20:45] Like with centralauth for logins you maen? [03:21:02] I don't know how that really works. I assume it is based on a shared secret. [03:21:09] if so everything is recoverable. [03:21:27] I have no idea [03:21:38] huh, I thought you knew everything about mediawiki :) [03:21:42] hah [03:21:53] I'm actually not very familiar with the intimate details of the login process [03:22:05] I know more about it than I should, probably, but not quite enough for this conversation [03:22:56] We should talk to Mark about this [03:23:02] Like, how are we gonna handle login sessions [03:23:14] Cause he wants to send some 10%ish of our traffic to the secondary DC [03:23:17] Tim and Mark are already thinking about it. [03:23:24] oh yeah, I forgot, you were dialed in [03:23:31] Mark said some things about it, yeah, heard that mostly [03:23:35] Where call quality allowed [03:24:00] But I didn't hear anything about keeping session/memcached/whatever state across DCs [03:24:42] I remember this discussion [03:25:09] we shouldn't replicate all of memcached, that would defeat the purpose [03:25:38] I think we might need maybe one or two new tables, maybe a token table (if we don't have one already) [03:25:44] Right [03:26:00] Well I guess login activity wouldn't be insane [03:26:12] So write-rate-wise we could afford putting all that crap in the DB [03:26:34] Not sure where we stand space-wise, I think some DB clusters are still a bit tight on disk space and we'd cause a pretty sudden hike [03:27:15] Actually I think we can do it with just a session table [03:27:21] That would store all $_SESSION data [03:27:23] well, we did this all the time at my former places of work. [03:27:31] except, we didn't abuse $_SESSION ;) [03:27:33] Which is mostly login, all else is negligible [03:27:45] that said, Yahoo kind of solved the login problem for us, I guess [03:27:52] MediaWiki has an optional (probably enabled on WMF) setting to put $_SESSION in memcached [03:27:58] we just kept a lot of user state in the db, a rather surprising amount actually. [03:28:09] oh it's definitely enabled! [03:28:13] Right [03:28:15] Has to be [03:28:27] Otherwise it'd be FS-based and your login wouldn't last 2 reqs [03:28:53] Either way, there's been some resistance, historically, to put non-critical things in the DB rather than memcached [03:29:18] Wikipedia has a history of having to run cheap [03:35:21] hey Roan, you're the master merger [03:35:39] is there an easy way to specify that only a very few files should be merged, in one svn command? [03:36:09] e.g. svn merge -r1234:HEAD branch-file1 branch-file2 branch-file3 --> trunk [03:36:24] Not in one command, no [03:36:32] The syntax is svn merge [what] [from] [to] [03:37:00] right [03:37:07] but then I need to do six or seven merges [03:37:10] Yes [03:37:14] Or use bash for loops [03:37:32] I don't mean it as a programming problem, just a cleanliness problem. [03:37:47] Cleanliness in process or result? [03:38:26] I think the cleanest way probably is to just write a bash for loop iterating over each individual file to merge [03:38:27] process [03:38:30] whatev [03:38:33] ok [03:38:46] However, if you've got a directory where all but a few are to be merged [03:38:49] oh duh, I forgot merges are not committed [03:38:51] so it doesn't matter [03:38:59] You can merge the entire dir, then revert some back [03:40:23] Yeah no one's gonna see the messy details of what you did to get there [13:49:57] robla, I can't create accounts until they're approved by someone from WM-DE, usually DaB. [13:50:14] He often takes a couple of weeks. When he approves it, I usually create them within a day or so. [16:47:15] robla, about? [16:47:25] hi Reedy: yup [16:47:43] quick pm [16:49:51] <^demon> zomg cabal [16:50:14] lol [16:50:24] It's alright ^demon, we're talking about you [16:50:38] :D [16:50:54] *^demon hides [17:38:34] roan [17:38:39] you have been bad [17:39:14] o_0 [17:39:46] special prize for anyone who can tell me why r75591 is broken [17:40:04] hint, it's in the click tracking change [22:51:29] template syntax fail http://commons.wikimedia.org/w/index.php?title=File:WMFUsability_highlights_explain.ogv&action=edit§ion=1 [23:12:36] robla, about? [23:12:53] Reedy: heya [23:13:13] Can I postpone another 15-20 minutes? I've just got back, fed the dog, and he's running around like a mad thing [23:13:16] So I think he wants a walk [23:13:53] Reedy: no prob [23:14:08] Poor thing has had nearly 12 hours with no company [23:14:39] or more than 12... [23:46:12] robla, ready when you are [23:46:45] okee doke