13:33:03 <nickm> #startmeeting
13:33:03 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:33:05 <nickm> hi everybody
13:33:17 <nickm> anybody else here atm?
13:33:48 <Sang0ku> yes, i'm here
13:34:12 <nickm> always nice to see somebody new at these dev meetings
13:34:36 <nickm> 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 <Sang0ku> thx man
13:35:55 <Sang0ku> 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 <athena> 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 <nickm> Sang0ku: cool; can you program? :)
13:37:29 <nickm> athena: good question.  I see a couple of options.
13:37:35 <nickm> 1. Add a new api to libevent 2.1
13:37:39 <nickm> 2. copy the code into tor
13:37:45 <nickm> 3. .... ?
13:38:52 <Sang0ku> i'm a newbie, beginner c and java and basics .NET so i don't know if i can be useful
13:39:09 <athena> 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 <nickm> hm.
13:40:06 <nickm> 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 <nickm> which wouldn't necessarily be a bad thing
13:40:40 <athena> 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 <nickm> I'd suggest renaming and exposing evutil_configure_monotonic_time and evutil_gettime_monotonic, whatever they're called.
13:41:44 <athena> yeah, i think that sounds right
13:42:11 <nickm> 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 <athena> i looked and saw some flags about *whether* we had good monotonic time/use precise or coarse calls
13:44:10 <athena> 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 <nickm> yeah.  I'd say, add what you think is best :)
13:44:41 <athena> 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 <athena> yeah, i think just exposing evutil_* APIs to get the monotonic time is probably the best move
13:45:22 <nickm> ok
13:45:30 <nickm> dgoulet: you want to go next, or should I?
13:45:34 <dgoulet> sure
13:45:56 <dgoulet> so I basically started full time since Monday so that's one thing :)
13:46:09 <infinity0> congrats :)
13:46:23 <athena> congrats, dgoulet.  kick the NSA's ass :)
13:46:31 <dgoulet> athena: oh yeah! :)
13:46:36 <nickm> 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 <dgoulet> 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 <dgoulet> I started explore HS system with #8902
13:47:59 <dgoulet> so I did build an IRC server behind an HS and hammered it with hundreds of connections each on different circuit
13:48:32 <dgoulet> 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 <dgoulet> err #13664
13:49:01 <dgoulet> currently answering asn questions on it, still need to figure a bit things out
13:49:07 <Sang0ku> nickm: ok, i'll see what i can understand lol cause obviously, this is some beautiful high level well organized coding
13:49:16 <dgoulet> but I have questions regarding
13:49:34 <nickm> Sang0ku: Thanks!  THese days I only seem to see the uglier parts. :)
13:49:56 <Sang0ku> :)
13:50:27 <dgoulet> 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 <dgoulet> 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 <dgoulet> ^
13:51:48 <nickm> dgoulet: I think that that's an attempt to make the hidden service rendezvous happen as soon as possible
13:52:17 <nickm> wait, do you mean client-side or server-side?
13:52:20 <dgoulet> client side
13:52:58 <nickm> 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 <dgoulet> right ok makes sense
13:54:16 <dgoulet> so I'm still working on that issue, I found other issue yesterday regarding the rend cache and desc. fetching
13:54:25 <dgoulet> that's about it for now
13:54:51 <nickm> sounds like a fine start; I look forward to your visiting boston in a bit!
13:55:13 <nickm> Also, everybody, please remember to remind me if you need code review
13:55:14 <dgoulet> nickm: yes! that's will help quite a lot :)
13:55:55 <nickm> I guess that's down to me now, unless there's somebody else around for this meeting?
13:56:37 <nickm> ok
13:57:08 <nickm> 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 <nickm> 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 <nickm> 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 <nickm> 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 <nickm> 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 <nickm> 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 <dgoulet> nickm: I can take a look fwiw
14:00:54 <nickm> that would rock.  #13339
14:01:11 * dgoulet adds this ticket to the review board
14:01:13 <nickm> Also, I NEED to write up a draft schedule for the next N months.
14:02:02 <nickm> Three things I'd like to talk about, either at this meeting or after:
14:02:19 <nickm> 1. For sponsor S, we need to figure out a non-spaghettilike way to organize network tests.
14:02:50 <nickm> 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 <nickm> 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 <nickm> anybody want to talk about one of those at the meeting?
14:04:10 * nickm afk 3 minutes
14:04:23 <Lunar^> (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 <dgoulet> awesome
14:06:30 <dgoulet> 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 <nickm> (re)
14:10:20 <athena> nickm: no, don't think you did - or it got buried in a flood of e-mail or something :/
14:10:22 <nickm> 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 <nickm> athena: okay, I'll try to find and resend
14:10:45 <athena> okay
14:11:41 <nickm> 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 <dgoulet> yeah ~6 months, if you think it's doable that sounds reasonable :)
14:12:34 <nickm> 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 <nickm> 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 <dgoulet> don't know unfortunately :S
14:14:46 <nickm> #action nickm needs to email comments on cmux stuff to athena
14:15:00 <nickm> athena: do you have any guess here?
14:15:44 <nickm> 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 <athena> hmm; ISTR we did spend a fair amount of time chasing bugs for 0.2.5
14:17:45 <nickm> Did we merge stuff that was too big too late in the series?
14:18:03 <nickm> or did we fix too many non-regression non-severe issues?
14:18:17 <nickm> or did we just defer fixing regressions until post-freeze?
14:19:52 <athena> not sure
14:20:00 <nickm> I wonder how we could find out.
14:20:18 <nickm> Or we could try to avoid all 3 mistakes at once?
14:24:22 <nickm> 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 <nickm> 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 <nickm> and maybe, post-freeze, we should only fix regressions and critical issues?
14:25:01 <nickm> I dunno.
14:25:34 <nickm> 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 <dgoulet> maybe a list of what features should be in 0.2.6 and aim for those then bug fixes?
14:25:52 <athena> i wonder if that might actually work...
14:25:57 <athena> (the surprise thing)
14:26:19 <nickm> 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 <dgoulet> so yeah soft deadline for the freeze in january, simply reschedule if it turns out it's undoable I guess
14:28:02 <nickm> 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 <nickm> maybe we need to impose a target date for the release itself so we can prioirize non-freeze items
14:28:32 <Lunar^> (sounds like Debian :p)
14:28:42 <nickm> And maybe we need to use our priority system or tickets to indicate must-fix vs would-be-nice-to-fix
14:28:54 <nickm> I won't want to burn another day triaging all the tickets right now though.
14:29:24 <athena> maybe we should do the triage pass after the freeze then?
14:29:33 <athena> ...and decide what's most important to try to fix?
14:29:52 <nickm> 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 <nickm> Another is that we should identify important bugs early, and fix them before the freeze.
14:31:24 <nickm> 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 <tjr> 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 <nickm> we use milestones for Tor releases.
14:31:58 <nickm> and we already have a milestone for 0.2.6
14:32:02 <dgoulet> 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 <nickm> we can use keywords or priorities for this, I guess
14:32:23 <tjr> Ah I see it now, sorry
14:32:28 <nickm> maybe we should plan to have a triage party, and invite a lot of people, some time later next week?
14:32:42 <nickm> and just go triage as many bugs as possible?  Maybe we could go faster that way
14:33:01 <nickm> 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 <dgoulet> triage party is a good idea
14:33:32 <nickm> athena: I trust you do to the same.  Let's keep an eye on one another's changes
14:33:39 <nickm> ok.  Thursday?
14:33:51 <nickm> athena: thursday ok for you?
14:34:46 <dgoulet> ok with me
14:35:04 <athena> nickm: okay
14:35:14 <nickm> ok. let's see if we can pull other people in to it too
14:35:16 <athena> triage next thursday (i.e., nov. 13) ?
14:35:19 <nickm> yeah
14:35:23 <dgoulet> time ?
14:35:26 <athena> works for me
14:35:32 <nickm> 1330 UTC is fine for me, I expect
14:35:39 <athena> ok
14:35:46 <nickm> (I can do later, but not earlier)
14:35:58 <dgoulet> fine
14:36:57 <nickm> great
14:37:19 <nickm> should we endmeeting, or should we talk about one of the other two things?
14:37:57 <dgoulet> I think we covered everything
14:38:06 <nickm> okay.
14:38:10 <nickm> #endmeeting