13:33:03 #startmeeting 13:33:03 Meeting started Thu Nov 6 13:33:03 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:33:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:33:05 hi everybody 13:33:17 anybody else here atm? 13:33:48 yes, i'm here 13:34:12 always nice to see somebody new at these dev meetings 13:34:36 so, who wants to talk about their progress first? I'll step afk for a minute to get some tea or coffee while you do 13:34:42 thx man 13:35:55 well first of all, as you said i'm new, so i don't have any progress, but i'm a big user of tor recently so willing to learn a little if i can help or something 13:36:54 progress: so, it sure looks like libevent 2.1 alpha has some great cross-platform monotonic time functions internally - how the heck do i call them from outside it? :) 13:37:17 Sang0ku: cool; can you program? :) 13:37:29 athena: good question. I see a couple of options. 13:37:35 1. Add a new api to libevent 2.1 13:37:39 2. copy the code into tor 13:37:45 3. .... ? 13:38:52 i'm a newbie, beginner c and java and basics .NET so i don't know if i can be useful 13:39:09 i like the idea of adding a new api better than cloning the code, especially since that entails cloning some windows-specific code i can't test easily 13:39:37 hm. 13:40:06 that's probably the right engineering practice. It does mean that I'd need to get active about putting out another libevent 2.1 release 13:40:11 which wouldn't necessarily be a bad thing 13:40:40 yeah. i don't mind writing the patch to add such functions, but you're the one to deal with actually releasing a libevent 2.1.5 :) 13:41:23 I'd suggest renaming and exposing evutil_configure_monotonic_time and evutil_gettime_monotonic, whatever they're called. 13:41:44 yeah, i think that sounds right 13:42:11 In theory, you might be able to pull that same info out of the event_base , but I'm not sure that's a winning proposition 13:43:18 i looked and saw some flags about *whether* we had good monotonic time/use precise or coarse calls 13:44:10 wasn't very clear that i ought to expect those to be stable in future versions like i'd hope for an API, though, or how to get at the actual current time doing anything like that 13:44:30 yeah. I'd say, add what you think is best :) 13:44:41 i suppose it *might* be exposed through starting a timer and querying it or something, but i didn't look close enough to be sure if that would be a viable route yet 13:45:01 yeah, i think just exposing evutil_* APIs to get the monotonic time is probably the best move 13:45:22 ok 13:45:30 dgoulet: you want to go next, or should I? 13:45:34 sure 13:45:56 so I basically started full time since Monday so that's one thing :) 13:46:09 congrats :) 13:46:23 congrats, dgoulet. kick the NSA's ass :) 13:46:31 athena: oh yeah! :) 13:46:36 Sang0ku: well, there are always people interested in reviewing easy patches, so don't worry about doing too much damage. You can look for tickets on the bugtracker with the keyword "easy" to find stuff that might be newbie-friendly. The doc/HACKING file in the tor source explains our coding practices. 13:47:03 so I'm on SponsorR as you all know, working with asn and karsten on coming up with HS measurement and stats we want to gather 13:47:28 I started explore HS system with #8902 13:47:59 so I did build an IRC server behind an HS and hammered it with hundreds of connections each on different circuit 13:48:32 and actually found that the tor client can't do that at all in a single instance of tor thus comes #13644 13:48:41 err #13664 13:49:01 currently answering asn questions on it, still need to figure a bit things out 13:49:07 nickm: ok, i'll see what i can understand lol cause obviously, this is some beautiful high level well organized coding 13:49:16 but I have questions regarding 13:49:34 Sang0ku: Thanks! THese days I only seem to see the uglier parts. :) 13:49:56 :) 13:50:27 one of the question is when building intro points, we do build them in parallel circuit and basically the first one that respond is the one we use and close the others? 13:50:37 Nov 04 15:36:08.000 [info] rend_client_close_other_intros(): Closing introduction circuit 25 that we built in parallel (Purpose 7). 13:50:40 ^ 13:51:48 dgoulet: I think that that's an attempt to make the hidden service rendezvous happen as soon as possible 13:52:17 wait, do you mean client-side or server-side? 13:52:20 client side 13:52:58 yeah. If we did it in serial, then we would have to wait for the first intro circuit to timeout before we tried another, and that would mean that a circuit timeout would make HS introduction feel extra extra slow 13:53:16 right ok makes sense 13:54:16 so I'm still working on that issue, I found other issue yesterday regarding the rend cache and desc. fetching 13:54:25 that's about it for now 13:54:51 sounds like a fine start; I look forward to your visiting boston in a bit! 13:55:13 Also, everybody, please remember to remind me if you need code review 13:55:14 nickm: yes! that's will help quite a lot :) 13:55:55 I guess that's down to me now, unless there's somebody else around for this meeting? 13:56:37 ok 13:57:08 So, my #12498 stuff has gotten a bit stuck because the description of how to handle authorities voting is just plain wrong. 13:57:56 I need instead to write a two-stage version of our current "select which identities are in the consensus" algorithm, and implement it, with tests this time. 13:58:21 I've been turning that over in my mind, and trying to review and merge a bunch of little patches to keep my hand in while I do 13:58:47 There are two big patches I'd like to get in to 0.2.6.2-alpha if possible: Athena's cmux thing and mvdan's consensus diff thing. 13:59:20 athena: what's current status on you talking with rob about the cmux business? And did you get the comments that I sent you? (Did I remember to send them? :/ ) 14:00:02 and would anybody like to help me review through mvdan's huge thing? Sebastian helped mentor him, so if he's available that could be nice, but another set of eyes could help. 14:00:38 nickm: I can take a look fwiw 14:00:54 that would rock. #13339 14:01:11 * dgoulet adds this ticket to the review board 14:01:13 Also, I NEED to write up a draft schedule for the next N months. 14:02:02 Three things I'd like to talk about, either at this meeting or after: 14:02:19 1. For sponsor S, we need to figure out a non-spaghettilike way to organize network tests. 14:02:50 2. Depending on the 0.2.6 schedule we pick, we need a cutoff date, and we need to retriage a lot of stuff out of 0.2.6-final 14:03:52 3. That 'vegas plan' that mike and roger came up with? Each team has a checklist, and we should run through that checklist with ours. I think the plan is going to turn into "Put nickm in charge of all the tor stuff, with assistance/coordination from DaveC", but I don't know. 14:04:06 anybody want to talk about one of those at the meeting? 14:04:10 * nickm afk 3 minutes 14:04:23 (it seems I'll be working on automating network tests by January; I can try to think about things before that, but no promises) 14:04:40 awesome 14:06:30 should we discuss now 2) and come up with a soft and hard release deadline (if "cutoff date" means that) or that makes more sense after triage to have a clearer idea? 14:09:42 (re) 14:10:20 nickm: no, don't think you did - or it got buried in a flood of e-mail or something :/ 14:10:22 Well, we've been wanting for a long time now to have a 6-month-ish schedule, when in fact we've struggled to get off a 12-month schedule. 14:10:27 athena: okay, I'll try to find and resend 14:10:45 okay 14:11:41 0.2.5-rc first came out in september. So we could aim to have 0.2.6-rc around the dev meeting in march? 14:12:33 yeah ~6 months, if you think it's doable that sounds reasonable :) 14:12:34 OTOH, 0.2.5 had its feature-freeze much earlier. Like, march. Did it really take 6 months to fix all the bugs we introduced? Or did we prioritize wrong? 14:14:22 my recollection is unclear. Maybe we spent too much time on other stuff? Maybe we said "bugfixes only" and then fixed too many hard non-regression bugs? 14:14:41 don't know unfortunately :S 14:14:46 #action nickm needs to email comments on cmux stuff to athena 14:15:00 athena: do you have any guess here? 14:15:44 Lunar^: Okay; it would be cool if you're in on the discussions before then. I'm going to be building a lot of that infrastructure too, so we should probably work to achieve a unified vision 14:17:27 hmm; ISTR we did spend a fair amount of time chasing bugs for 0.2.5 14:17:45 Did we merge stuff that was too big too late in the series? 14:18:03 or did we fix too many non-regression non-severe issues? 14:18:17 or did we just defer fixing regressions until post-freeze? 14:19:52 not sure 14:20:00 I wonder how we could find out. 14:20:18 Or we could try to avoid all 3 mistakes at once? 14:24:22 I guess if we're aiming to get the -rc out in march, then we have to freeze around january. But it needs to be a smart freeze, where we don't try to cram more stuff in... 14:24:39 and we need to prioritize bugs into blocker and nice-to-fix, and work on the blockers first and in parallel with feature stuff. 14:24:59 and maybe, post-freeze, we should only fix regressions and critical issues? 14:25:01 I dunno. 14:25:34 Maybe I should tell everybody "freeze some time in january" and then be vague about it and do it as a surprise, so nobody tries to cram stuff in right before the deadline? 14:25:36 maybe a list of what features should be in 0.2.6 and aim for those then bug fixes? 14:25:52 i wonder if that might actually work... 14:25:57 (the surprise thing) 14:26:19 dgoulet: we've tried for that a bit with the tickets marked 026-triaged, but we haven't done that in any way that's calculated to finish by january 14:27:54 so yeah soft deadline for the freeze in january, simply reschedule if it turns out it's undoable I guess 14:28:02 We've been okay at meeting freeze deadlines, but after that, we've taken a "it takes as long as it takes" approach. 14:28:20 maybe we need to impose a target date for the release itself so we can prioirize non-freeze items 14:28:32 (sounds like Debian :p) 14:28:42 And maybe we need to use our priority system or tickets to indicate must-fix vs would-be-nice-to-fix 14:28:54 I won't want to burn another day triaging all the tickets right now though. 14:29:24 maybe we should do the triage pass after the freeze then? 14:29:33 ...and decide what's most important to try to fix? 14:29:52 Possibly. one issue is that if we don't triage features, we'll wind up with a crazy-quilt of who-knows-what in the release 14:30:17 Another is that we should identify important bugs early, and fix them before the freeze. 14:31:24 else we'll hit the freeze, and then start destabilizing the code to fix important issues that we're not happy to wait on. :) 14:31:37 There's the Trac milestone feature: https://trac.torproject.org/projects/tor/milestone/Deliverable-Mar2011?by=priority which may help for organization? 14:31:52 we use milestones for Tor releases. 14:31:58 and we already have a milestone for 0.2.6 14:32:02 yes I think that triaging bugs before the freeze and the "priority" field could be used for that. Fixing by-design issues before the freeze is always a good idea 14:32:03 we can use keywords or priorities for this, I guess 14:32:23 Ah I see it now, sorry 14:32:28 maybe we should plan to have a triage party, and invite a lot of people, some time later next week? 14:32:42 and just go triage as many bugs as possible? Maybe we could go faster that way 14:33:01 or, does everybody trust me to randomly kick stuff out of 0.2.6, mark stuff 'must-fix', mark stuff deferrable, etc? 14:33:30 triage party is a good idea 14:33:32 athena: I trust you do to the same. Let's keep an eye on one another's changes 14:33:39 ok. Thursday? 14:33:51 athena: thursday ok for you? 14:34:46 ok with me 14:35:04 nickm: okay 14:35:14 ok. let's see if we can pull other people in to it too 14:35:16 triage next thursday (i.e., nov. 13) ? 14:35:19 yeah 14:35:23 time ? 14:35:26 works for me 14:35:32 1330 UTC is fine for me, I expect 14:35:39 ok 14:35:46 (I can do later, but not earlier) 14:35:58 fine 14:36:57 great 14:37:19 should we endmeeting, or should we talk about one of the other two things? 14:37:57 I think we covered everything 14:38:06 okay. 14:38:10 #endmeeting