[01:19:43] what's the current state of map reducability of request logs? [01:19:47] is it all in HDFS? [01:20:49] in particular, how feasible is it that i could design my own job and hand it off to someone with access to actually run it for me? [01:51:11] jeremyb: poke drdee? [01:58:14] drdee: ! :) [01:58:16] bbl [01:59:00] YuviPanda: i wonder how the philippine situation compares with india. i.e. could you get the carrier to respond faster or to respond with a real human instead of a drone? [01:59:14] see my latest tweets to @smartcares [02:09:23] jeremyb: usually no [02:09:42] jeremyb: unless you knew people 'high up' [02:13:55] yeah... [02:14:08] i guess i can't say the US is any better [02:14:18] part of the problem is the lack of competition [02:21:57] jeremyb; yes in theory that should be possible but there is very little documentation available about the data streams and of course there is the big question on how to handle jobs that query dataset with PII (personal identifiable information) so this requires some more thinking first [03:35:13] gah, missed him by a few secs [03:35:22] PII is exactly what i want to query [03:36:09] is there a sample of a past job that i could adopt? [03:37:53] we have request logs in hadoop now? huh [03:37:56] * Ironholds goes to check [03:39:13] jeremyb, I can't see the data actually in there yet, actually, although the fulltime analysts will know better than I [03:53:51] Ironholds: sure. this would be for https://otrs-wiki.wikimedia.org/wiki/504_gateway_timeout btw [03:54:08] Ironholds: i'm thinking we could get request stats for the entire netblock in aggregate over time [03:54:31] jeremyb: aha. To my knowledge that data isn't in hadoop yet, I'm afraid. [03:54:49] Ironholds: right, you just said you don't see it :) [03:54:57] at the moment we're only just experimenting with using the cluster regularly, with pageview data (by experimenting, I mean toby tasked me with quote "break hadoop and tell us how" [03:55:12] so, yeah. sorry :( [11:00:59] hi drdee [11:01:02] hi milimetric_ [11:01:07] hi qchris [11:01:10] heya [11:06:59] Hi average :-) [11:07:07] hey qchris [11:07:38] wanted to chat with drdee about tree extraction from the category table. I threw my eyes over the problem a bit [11:08:21] Interesting :-) [11:08:59] didn't write any actual code for it [11:09:09] Would this be for the pageview api stuff? [11:09:14] yes [11:09:25] Interesting. [11:09:32] this part https://www.mediawiki.org/wiki/Talk:Analytics/Hypercube#The_trouble_with_categories [11:11:08] I am curious how DarTar and Erik will respond to drdee's request to rank-order the different features [11:11:26] I was thinking of extracting a tree based on [11:11:33] But yes, this will definitely require further discussion [11:11:34] damn , pressed return too early [11:11:44] Meh. Go ahead :-) [11:11:48] What was your idea? [11:12:03] uhm, so I was thinking that there are 2 different things [11:13:34] #1 finding out how the structure of the categories (hierarchy/graph thing) changes over time. my understanding is that it can be extracted only by going through each revision of each page in the dump and looking at the bottom of the revision (reverse regex for fast snatching of the categories). [11:13:34] average hopes that someone will have a look at https://mingle.corp.wikimedia.org/projects/analytics/cards/1 [11:15:38] Historic data is a problem, yes. [11:15:55] 2) deciding on what is the best way to extract a multipath tree out of the graph that's currently described by the category table. possible candidates for this can be visualized in gephi(large graph visualization opensource software) to see what their results would look like [11:16:27] But I am not sure if we need historic data. [11:16:35] I know for 2) drdee has some candidates. I have a candidate too. but it's more of a .. curiosity for me [11:16:59] Maybe we can ignore historic data, and start collecting the data from now on? That might make things simpler. I do not know. [11:18:01] Ad 2) ... is this about "how do we store this information" or really about "how can we extract this information"? [11:18:18] qchris: well, the need of historic data would arise from the fact that the tree would change over time I think. I remember that's what the Talk page said .. [11:18:54] Yes, it would change over time, but maybe it would suffice if we start to collect the [11:19:05] data right now, and store changes as they occur. [11:19:13] that would make total sense I think [11:19:24] That would allow us to push back importing old data a bit. [11:19:27] unless it's already in the Mediawiki schema somewhere [11:19:49] I'm not very well versed with the mediawiki schema, for example I don't know what the category_links contains [11:20:08] category_links table [11:20:35] It's some time that I looked at the schema, but when I last looked (~1.19) historic data was not available [11:20:46] as category_links is tied to the page, not the revision [11:20:54] But that might be wrong/have changed [11:21:23] I briefly looked at the 1.20 schema [11:22:23] The last printout I have is dated 2011-11-14 :-) [11:23:00] about 2) I'll make a short conjecture: "Categories in the upper levels of the tree change much less often than categories from the bottom or lower levels" [11:23:47] Ok, let's assume the conjecture holds. [11:24:38] in other words, big categories rarely change in terms of their constituent parts being moved around. [11:25:49] if the conjecture holds, and we can extract the historic data of evolution of category changes, then we can find a tree whose structure persists over time. [11:26:11] based on what parts of the big graph change less often [11:27:29] That sounds good. [11:27:49] But as I probably understand the problems too little, how would we exploit that for extraction? [11:30:01] we color the nodes of the tree in red or green. green means childern of node rarely change(change means deletion of a category or creation of a new child category). red means it changes often. [11:30:05] we get a green tree [11:30:12] Yes. [11:30:28] What does the green tree buy us? [11:30:56] it buys us a hierarchical category structure that stays the same with the passing of time [11:31:54] Yes, that tree should not change too often. [11:32:34] now let's make a leap of faith and suppose we have the tree. the leafs are actual articles [11:32:53] every time an article gets a hit, the hit propagates through the tree, all the way up to the top category [11:34:20] unfortunately articles can belong to multiple categories. which brings us to the next problem.. [11:35:09] Article "Cat" belongs to categories "Mammal" and "Feline" which are in turn sub-categories of category "Animal" [11:35:24] Yes. [11:35:32] if you propagate the +1 from both "Mammal" and "Feline" you get +2 in "Animal" which is wrong [11:38:02] to make this short, I'll mention that I don't have a solution to double-counting [11:38:40] We can do the naive approach and determine the full set of categories an article belongs to. [11:38:48] After weeding out duplicates [11:38:59] Adding 1 to the categories would do the trick. [11:39:28] But as that needs to happen in realtime, we need to make sure such queries are superefficient [11:39:32] That's nasty. [11:40:00] To avoid that, we could just record the hits, and batchprocess them. [11:40:27] But that somehow depends on time-resolution. [11:40:42] If we're fine with day-resolution, the problems becomes simpler. [11:41:12] because you just update the tree at the end of the day [11:41:21] and hopefuly that will not be very expensive [11:41:30] ? [11:41:36] Updating the tree is a different thing. [11:41:48] I was referring to increasing hit counters [11:41:51] for categories [11:41:52] I mean just updating the hit count for all the nodes of the tree [11:42:56] To me, it mostly depends on what our product owner identifies as providing most business value (Marketing talk :-((( ) :-) [11:44:20] Once that has happened, we have to think hard about if/how we can make it happen. [11:45:21] true [11:50:25] < qchris> But as that needs to happen in realtime, we need to make sure such queries are superefficient [11:51:11] qchris: ^^ is this implying more-or-less that we model hits going up the tree as messages traveling on the tree with unique identifiers so we can distinguish hits and not double-count ? [11:51:37] No. [11:52:00] There are models that allow deduplication on the fly. [11:52:10] So we can evade adding ids to hits. [11:52:34] But these models rely on properties of the tree. [11:53:02] So we'd have to check which properties we have (or can artificially establish), and which model meets those properties. [11:54:25] As that will get involved and require some work, I'll keep pushing it back until we really know [11:54:30] what we want to arrive at. [11:54:48] that makes sense [11:54:49] Otherwise it might well be that we end up implementing the wrong thing. [11:54:53] I think [11:57:59] I don't think stats.grok.se has this [11:58:53] I agree. I also do not think stats.grok.se has this. [11:59:06] But stats.grok.se does not treat categories at all IIRC. [11:59:29] totally true [12:00:39] I hope that the decision makers rate down the need to cover categories. [12:00:45] * qchris keeps his fingers crossed [13:35:04] qchris, average: weren't we supposed to be tasking today [13:35:36] milimetric: Who stole my focus when closing windows? :-D [13:35:44] milimetric: Yes, I thought so as well. [13:36:19] hm, let's do it :) [13:36:36] Yes. Totally. [13:36:42] when was the meeting supposed to start? [13:36:50] I think I voted for 10:00 our time [13:36:57] so 16 your time [13:37:01] milimetric: I dunno about tasking. I'm working on my piece of the cake [13:37:12] I think we did not yet agree on a date. [13:37:13] I would prefer to use this time to work until standup [13:37:31] Besides ... our Scrum Master is not here, and has scheduled no time for it. [13:37:40] yes, this is true :/ [13:37:53] The product owner did not say which cards we should work on. [13:38:07] And the cards are not prioritized [13:38:08] also true, but we can start by tasking out what's already in flight [13:38:13] so we cannot start on our own. [13:38:25] but i agree for the most part, let's wait for drdee [13:39:05] It's possible he thought the tasking would start during the next sprint. But in my opinion, this would already put us behind a little bit since we need to task the next sprint's cards [13:39:46] I thought there was an agreement to start today. [13:39:55] But I'll take whatever comes. [14:06:09] milimetric: what's code climate ? [14:06:45] it's an automated code review tool, Zelko used it to analyze some repositories [14:07:12] seemed easy to add and it was - took me like 1 minute [14:07:26] it looks like reportCreate isn't as good as it should be, so I'll be looking at that [14:07:37] average - did you get a chance to review the test refactor? [14:07:52] you should do that and run the tests - I'm very curious if it helps the speed on your computer at all [14:07:52] hey milimetric, you sound busy with your brain in other things, but I need a quick second opinion: [14:08:01] on mine it went from 75 sec. to 50 sec. [14:08:04] so, it looks like we get duplicates in the logs from remote data centers [14:08:07] sometimes [14:08:11] kafka doesn't drop messages [14:08:14] hm [14:08:15] but it will sometimes deliver more than once [14:08:21] at least once guaruntee [14:08:25] :) [14:08:28] so, i think as part of the etl process we need to de-duplicate [14:08:34] and the messages are EXACTLY the same? [14:08:39] but i'm not sure if we should do that to the logs before they get stored int /wmf/data [14:08:42] we have gerrit for code quality [14:08:45] i believe so…, let me find some [14:09:10] average: non sequitor, this is *automated* code review, it uses a few rules to look at your code [14:10:17] well, ottomata, I'm skeptical that we can assume that the log lines are always 100% duplicates, but we can find duplicates by sequence number [14:10:35] then maybe raise an alarm if they're not exactly the same [14:10:41] and just de-duplicate if they are the same [14:10:44] we're already using flake8 [14:11:11] my opinion is that this should happen as early in the process as possible, but what's the flow right now before stuff lands in /wmf/data? [14:11:24] yes we can find duplicates by hostname+seq, no problem [14:11:29] they hsoudl be exactly the same [14:11:38] they are only produced once by varnishkafka [14:11:46] its the kafka api that duplicates them [14:11:50] they sit in a queue [14:11:53] and wait for ack [14:11:58] if the ack fails they might get sent again [14:12:01] average: you don't have to take a look at CodeClimate, I'm not mandating it. But please do before you compare it to other tools, because it's not related to gerrit or flake8 [14:12:06] especially if the ack fails within some timeout [14:12:56] gotcha [14:13:24] ok [14:13:24] and from kafka it goes through camus before it ends up in /wmf/data? [14:13:24] or how's that work? [14:13:35] yes [14:14:10] also, qchris, I'm starting to think we should keep JsonStringMessageDecoder in kraken, i think I want to be able to modify the data, e.g. add and clean fields there if i want to [14:14:50] I think i'd like to add an integer timestamp, so that we can use that as a date field in hive [14:14:55] * qchris reads backscroll [14:15:29] so maybe we can make it land in /wmf/raw-data? Then transform it to /wmf/data by deduplicating [14:15:29] we might find that pattern useful as other streams may have problems [14:16:02] yeah i think so too [14:16:20] yeah [14:16:22] yeah [14:16:24] ok yeah :) [14:17:05] ottomata: I am fine with keeping JsonStringMessageDecoderWhateverTheClassIsCalled in kraken-etl. [14:17:23] ok [14:17:28] ottomata: But we should clarify some things about lazy initialization with upstream. [14:17:34] ok? [14:17:38] whatcha mean? [14:17:58] Mostly having them phrase out clearly when we can expect "init" to be called. [14:18:05] Currently it's only convention [14:18:12] and no documentation about it. [14:18:22] yeah, there isn't much camus documentation at all :p [14:18:58] Yes. I could prepare some documentation patches that makes the contract between classes and caller clear. [14:19:11] So we know which call orders we have to test/cover. [14:19:42] * qchris adds that to his to-dos [14:20:10] danke :) [14:20:14] milimetric: reviewing 91848 [14:25:18] milimetric: https://gist.github.com/wsdookadr/698cdcbcb4a99d5f8d3a [14:32:21] that's... confusing [14:32:37] sorry, I blew up an egg by forgetting it downstairs [14:32:40] had to vacuum [14:32:48] lemme check into that error average [14:33:03] it works on my computer oddly... [14:41:45] milimetric: you wanna look at this together ? [14:42:50] no it's ok, I'll be a little slow, sorry - still dealing with burnt egg [14:44:57] ok [14:47:27] (PS1) Milimetric: Lint cleanup [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/92312 [14:53:12] milimetric: may I have your oppinion on requirejs and whether you think it's a good/bad idea to use it ? [14:53:28] 'course [14:53:52] so JS doesn't have any "import / use / include" type mechanism [14:54:06] there are a LOT of libraries that add this type of capability [14:54:11] but I don't like any of them [14:54:35] and every time I go to use one, I re-learn all of the options trying to find a better one [14:54:46] I think last time I looked, requirejs was the best one, but I have to look again :( [14:55:18] well, I take that back - I kind of like YUI. But I've never actually used it because others were against it. [14:55:39] So maybe YUI would be nice to use here, maybe bootstrap has something now, I don't know [14:57:26] ok. have there been any load-order peculiar things so far ? [14:57:57] I haven't seen any problems with that in the current codebase [15:01:57] anyway, reviewing 92312 [15:11:17] oh - yeah, it's hacky to just assume that ko and site exist because they're included by whoever includes your script [15:11:23] so a loader would make that explicit [15:11:53] the way the code is right now, it'd be kind of like leaving out "from datetime import timedelta" in python and expecting the person who uses your script to do that [15:12:06] brb, restarting [15:18:22] ok, average: I ran scripts/test on a clean clone, install, checkout of that testing changeset. [15:18:33] I only got the usual revert rate test failing for me [15:18:41] ok, trying again [15:19:04] if you're sure your checkout is clean too, maybe these tests are bad :) [15:20:54] maybe they don't like me ;) [15:21:12] hm... are they still failing? [15:21:15] hold on, finishing up another run now [15:21:35] one theory is that the date arithmetic I'm doing with now() - 48 * one_hour is not good [15:21:52] like, it gives bad results *sometimes* [15:22:26] maybe if the test takes longer to run or something like that, then the results are rounded up... [15:24:35] also - how long do they take for you now? [15:25:10] rerunning now with time [15:25:41] uhm, around 1-2 minutes I think. I'll get a better number after they finish now [15:26:01] I think that's definitely a good improvement [15:29:15] took 3m6s [15:29:42] but doesn't nose just tell you how long it took in seconds under the coverage report? [15:30:04] how long did it take before? [15:30:11] and also - more important - is it still failing? :) [15:30:43] ~4m . I have a feeling it's something with git [15:31:12] I checked out to the gerrit patchset, I checked out into a new branch [15:31:19] I ran the tests [15:32:57] milimetric: batcave ? [15:40:26] ok something is definitely wrong with my local copy of the repo [15:40:31] cloning a new one [15:41:32] sorry average, to the batcave [15:41:54] getting headphones [16:38:28] it looks like standup got moved to 11 PDT [16:39:00] which is in 1.5 hours -- does this work for the european folks? [16:44:27] Europeans had the DST this weekend. Yes. [16:44:55] According to the wall clack time around here, we'd have the daily scrum in ~75 minutes. [16:45:02] that works better for me -- let's do that then (I have to get to the office for a 10:30) [16:45:15] see you then [16:45:19] Ok. Great [16:49:14] milimetric: what is your preferred python json lib? [16:49:32] in python 2.7, I believe the basic built in "import json" is really good [16:49:37] this was not the case in python 2.6 [16:49:38] regular json? [16:49:39] ok [16:49:41] yep [16:49:42] cool [16:49:42] danke [16:52:40] wait what? we're going off European DST? [16:52:43] so confusing! [16:52:54] the bug we had in wikimetrics this morning was DST related too! [16:52:56] lol [16:54:41] milimetric: Yes, at least for today, let's go with European time change. It matches what we see in our google calender (at least for me), and it's easier for tnegrin. [16:54:57] ok [16:55:16] We can discuss afterwards to which timezone we synchronize the event (it currently seems to be European) [16:59:13] (PS6) Milimetric: Making large tests a LOT faster [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91848 [17:18:26] * YuviPanda waves at milimetric [17:19:15] * average waves @ YuviPanda [17:19:22] hey average! [17:19:30] hey YuviPanda :) [17:36:52] oh! I missed your wave YuviPanda, how are you? [17:37:04] milimetric: good! except for the hand [17:37:11] oh! RSI still bothering you? [17:37:26] milimetric: yeah, full blown CTS, sadly [17:37:33] oh :( [17:37:56] are there remedies for that? [17:38:31] milimetric: yeah, meds short term fix, and workspace changes in the long term [17:38:49] well, I don't wanna make you type unnecessarily, so if you need anything, you can always join our hangout: goo.gl/1pm5JI [17:38:53] milimetric: so think I can get access to the hadoop cluster? Just to play around with it a bit [17:39:21] totally, ottomata - I'm sorry to ask this for the millionth time but what's the procedure to let people play with Hive? [17:39:52] YuviPanda: get an advantage kinesis [17:39:59] average: yeah, considering that [17:40:02] YuviPanda: change layout to suit your needs, and you're done [17:40:05] gonna play with it a bit, greg-g has one [17:40:10] and see if that helps [17:41:15] YuviPanda: I'll get you access and ping you when you have it [17:41:26] milimetric: woot! [17:41:26] ty [17:49:45] milimetric: can you run this in ipython please ? time.localtime().tm_isdst [17:49:51] milimetric: after you import time [17:49:55] k [17:50:00] milimetric: should give you 1 [17:50:24] 1 [17:50:25] yep [17:50:28] cool [17:50:53] I get 0, and that's ok too, for my timezone [17:51:25] ok, how's the reviewing look? [17:51:33] almost done [17:51:35] I'd like to get those patchsets merged so we can start focusing on 818 [17:51:39] ok [17:51:59] I'm pretty sure we won't be able to get it done now, because our quarterly review is tomorrow and that'll take up a lot of time [18:59:56] (CR) Stefan.petrea: [C: 2 V: 2] fixed silly JS mistake [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91674 (owner: Milimetric) [19:00:29] (CR) Stefan.petrea: [C: 2 V: 2] Making large tests a LOT faster [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91848 (owner: Milimetric) [19:00:52] brb [19:00:59] milimetric: I just tried to implement that with time.localtime().tm_isdst. Had to get some dates and check if the tm_isdst had changed between them [19:02:04] milimetric: got tangled up in time, timetuples, datetime and tzinfo and tznames. I still think it's important to have those 2 tests passing (I'll look at it a bit later) [19:02:17] meanwhile the change got merged [19:02:25] ok, this makes sense [19:02:36] that bug was not related to the changeset, so it's ok if the fix doesn't go in with it [19:03:05] but the fix can definitely be tricky. You can write a test that will always fail and use dates around October 27th. [19:03:15] (instead of now - 48 hours) [19:03:52] I didn't find a constructor in datetime that would allow me to pass it the current tz and dst [19:04:06] if I could have done that, then I would've been able to write the fix [19:04:43] I'm sure it's possible, but after 30minutes of looking around in docs and SO, I concluded it was more important to postpone it [19:04:51] (PS2) Milimetric: Lint cleanup [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/92312 [19:04:53] actually more like 50m [19:05:01] (CR) Milimetric: [C: 2 V: 2] Lint cleanup [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/92312 (owner: Milimetric) [19:06:02] (PS1) Milimetric: resolve merge conflict [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/92356 [19:06:45] (PS6) Milimetric: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 (owner: Stefan.petrea) [19:06:52] ok Stefan [19:07:03] the nasty crap above ^^ [19:07:12] it basically means: Dan fought with Gerrit and Gerrit won [19:07:13] again [19:07:17] so I just pushed [19:07:42] I absolutely refuse to spend so much time just to commit code to my repository [19:07:52] lemme have a look. [19:07:59] it should all be clean now [19:08:25] so the point is - back to 818 [19:09:00] do you want to hangout quickly and make sure we're synchronized on 818? [19:09:20] we are sync-ed on 818 [19:12:04] (PS7) Stefan.petrea: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 [19:13:29] There must be something I'm doing wrong with gerrit. The merge with --squash should have been much easier [19:13:32] it got mangled up again [19:13:51] I fixed it but it was as annoying as it was for you earlier [19:16:21] milimetric: QueueTest in fixtures.py is usable right ? [19:16:29] yes [19:16:37] hm but it's empty [19:16:48] setUp and tearDown are both just "pass" [19:17:18] right - because the queue always starts now [19:17:30] so for basic queue tests you don't need to do anything special [19:17:34] milimetric: so the queue is started upon running the test suite ? [19:17:37] you probably usually want QueueDatabaseTest [19:17:40] yes [19:17:43] ah, alright [19:17:46] queue starts when you run the suite [19:17:53] it's in the setUp of the whole package, in __init__ [19:18:02] then I can test part of the code [19:18:59] alright, I'll inherit from QueueDatabaseTest [19:23:22] qchris_away: when you have some time, can we talk a bit about gerrit. we're working on this same gerrit review and we alternatively push patchsets. And then we each have to merge and the merge looks a bit unusual (it should be an easy merge but the diff looks really unusual..) [19:24:14] qchris_away: it's basically not identifying correctly what the differences are [19:26:31] (PS8) Milimetric: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 (owner: Stefan.petrea) [19:28:49] average: I pushed the last of my lint fixes, I'm moderately happy with the JS now [19:28:59] and I rebased [19:29:12] you should be fine, but I don't know how gerrit works [19:29:38] stashing and popping after checking out the latest patchset might be the safest way to go [19:30:33] I'll try doing things like that. But I wonder what's the easiest way to pull changes directly in the branch I'm on [19:30:52] no idea dude - if gerrit wasn't all that is evil in the world I might actually care enough to look it up [19:31:42] I think I'm going to need psychotherapy to deal with my gerrit issues [19:37:14] (PS9) Stefan.petrea: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 [19:37:22] gerrit is milimetric the stash idea worked well [19:37:32] damn keyboard [19:37:38] meant to write "the stash idea worked well" [19:44:25] milimetric: there's this thing called tig, which is git but with a ncurses UI [19:44:39] milimetric: it's basically like cheating, but maybe it's easier. I'll give it a spin later today [19:46:19] * average doesn't know why github can't be opensourced so we can use it instead of gerrit [20:12:46] hashar: I can hook you up with a nice ffmpeg hack to make better quality screencasts [20:13:13] average: the Google Hangout footage was a very bad quality one :/ [20:13:18] hashar: I am only refering to resolution, as all post-processing depends on your own tastes :) [20:14:13] the original is 1280x720 , 21 minutes long [20:14:23] with a bitrate of…. 410kb/s :( [20:14:49] hashar: https://gist.github.com/wsdookadr/3946150 [20:15:03] I might reencode it in 1280 [20:15:05] hashar: https://gist.github.com/wsdookadr/9874a5d271ad4649886c [20:15:16] hashar: I do 1920x1080 [20:15:38] niceeee [20:15:47] hashar: with x264 codec. 20min weighing in at around 10-20mb [20:16:44] next time I will record my terminal in HD :-] [20:16:46] got to find a soft to achieve that [20:16:47] (on mac) [20:49:43] greetings from sf [20:49:53] oh hi drdee! [20:50:42] hiyaaaa [20:51:24] drdee, you're here? awesome! [20:51:36] oh oh ohhhh [20:52:18] http://www.youtube.com/watch?v=QkynLMhYWEU Hive tutorial [20:52:29] ta :) [20:55:00] average: Sure. Let me start the google machine, then we try together. [22:12:54] (PS10) Milimetric: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 (owner: Stefan.petrea) [22:13:48] (PS11) Milimetric: A step towards 818 [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/91207 (owner: Stefan.petrea)