16:59:37 <nickm> #startmeeting network team meeting, 21 Aug
16:59:37 <MeetBot> Meeting started Mon Aug 21 16:59:37 2017 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:01 <nickm> hi everybody!
17:00:08 <dgoulet> hello
17:00:09 <pastly> hi
17:00:10 <catalyst> hi
17:00:12 <asn> hello hello hello
17:01:15 <nickm> catalyst: btw, if this meeting intersects with anybody's eclipse time, please take an eclipse break
17:02:00 * asn reads reports
17:02:15 <nickm> I think I'm going to be doing a lot of code review this week  too...
17:02:35 <nickm> but also I have a bunch fo stuff in review-group-22 that's been waiting for a little review
17:02:39 <nickm> *of
17:04:03 <dgoulet> pastly: is the ticket/branch is in need_review right?
17:04:16 <dgoulet> pastly: ticket number ? (so I can put it on my priority stack)
17:04:28 <pastly> dgoulet: just a moment I'll get you the ticket num.
17:04:50 <pastly> dgoulet: #12541
17:04:54 <nickm> Is ahf around today, or still away?
17:05:03 <dgoulet> pastly: thanks
17:05:14 <dgoulet> nickm: pretty sure he is away for BornHack
17:05:18 <nickm> ok
17:05:43 <dgoulet> - 21/8 and 22/8 - Build Up (not online at all)
17:06:58 <nickm> Does anybody remember who wanted #22407 ? I know people have been promoting it for a long time, but I forget who
17:07:09 <nickm> but I figure maybe we could get them to test it :)
17:08:39 <nickm> catalyst: where are with bootstrap progress reporting?  If we wanted to get an initial _something_ to the TB team pretty quickly, what would the timeline be?
17:08:55 <nickm> and would I help or hinder more by jumping in?
17:09:17 <nickm> pastly: you saw my review on #12541, yeah? I can't remember if I told you; it was so long ago...
17:09:20 <nickm> :)
17:09:58 <pastly> Yup I saw them. Thanks a lot nickm :)
17:10:18 <haxxpop> hi !!
17:10:22 <pastly> Mostly that I didn't read the style guide well enough
17:10:22 <catalyst> nickm: right now a lot of the stuff that would be helpful to report out is buried quite deeply in enormous call stacks; it would help to refactor that somehow (but i'm not sure how yet)
17:11:00 <nickm> catalyst: so, it's actually okay to send control events from deep inside enormous call stacks: control events are queued in control.c, and actually sent later, so it doesn't risk introducing circularity...
17:11:10 <nickm> I'm not sure if that's what you were saying though
17:11:38 <catalyst> part of the problem is when you need to report something from deep in a call stack but don't have the context to know whether you're being called in the way that you're meaning to report
17:11:47 <nickm> ah.
17:12:05 <nickm> do you have a list of all the stuff we want to start reporting, and a list of where to report it and what's hard to report
17:12:08 <nickm> ?
17:12:14 <nickm> If so I could try to help figure out ways to report stuff
17:12:36 <nickm> it might also be fine to just add reporting for the things that are easy now, and do the hard stuff afterwards
17:13:00 <catalyst> e.g., the roundabout way we handle BOOTSTRAP_STATUS_HANDSHAKE
17:13:55 <catalyst> there's other stuff that tries to figure out whether it's being called in a particular bootstrap phase to decide whether to report it out
17:14:48 <nickm> ouch, that one _is_ gross.
17:15:12 <catalyst> almost tempted to drop in generic progress reporting to connection setup code and have the upper layers sort it out (they have easier access to the required context after all)
17:15:30 <nickm> that actually sounds pretty smart.
17:15:47 <nickm> like, just tell the control.c code about events, and have a state machine there that turns the events into progress status?
17:17:53 <catalyst> yeah that way controllers can have models of detailed progress of individual ORCONNs
17:18:23 <nickm> hm
17:18:41 <nickm> I think that the controllers (like tor launcher) really do want the bootstrap status...
17:18:58 <nickm> ... but that converting or conn status into bootstrap status at a higher layer would be fine
17:20:51 <catalyst> another example is how we decide whether to report BOOTSTRAP_STATUS_CONN_DIR in circuit_handle_first_hop()
17:24:11 <nickm> but, are you thinking of having a higher layer in Tor convert this stuff to bootstrap progress?  Or exposing fine-grained events to the controller and making them determine the progress?
17:24:21 <nickm> because that latter one will take more engineering on their part
17:24:35 <meejah> IIUC, I think I would like that too: just 'events' that happen or not, and my controller figures out how much "percent progress" we've got
17:24:50 <catalyst> having a higher layer convert the detailed circuit progress into bootstrap progress. sophisticated controllers can get more detailed events
17:24:58 <nickm> ack
17:24:59 <meejah> (because I mess with the precent *anyway* to, e.g., account for 'upload the descriptors')
17:29:36 <nickm> catalyst: that makes sense. So back to my earlier questions: do you think we're ready to declare a rough timeline there for isabela ?  and would it help if I jump in too?
17:32:07 <nickm> also, has everybody had a chance to look at dgoulet's scheduling email?
17:32:24 <nickm> dgoulet: did you mean the one on the thread "lets build our schedule for teams meetings day in montreal"
17:32:29 <dgoulet> yes
17:32:49 <dgoulet> I replied with 3 sessions and put some timeslot in the schedule
17:33:06 <nickm> dgoulet: I think maybe we could benefit from some "what would we like funding to do" discussion as well -- not sure where that fits in, but it could be brainstormable
17:33:43 <dgoulet> nickm: yes, maybe we can roadmap for an hour and then transition to that
17:33:49 <dgoulet> (with session (3))
17:34:28 <msvb-lab> Is this where there is a dev meeting today at 11:00 UTC-7?
17:34:59 <nickm> there's a dev meeting right now!
17:35:08 <nickm> and another one in 25 minutes
17:35:20 <nickm> dgoulet: sounds good; shall I say that on the thread or would you like to?
17:35:26 <dgoulet> nickm: go for it I say
17:35:30 <nickm> ack
17:38:18 <nickm> any other topics for today, or shall we call the meeting finished and move on to code reviews? :)
17:38:27 * dgoulet is good
17:38:40 <catalyst> nickm: i think first phase is to either add PT and proxy progress reporting to control_event_or_conn_status() or make new abstractions for reporting them
17:39:20 <catalyst> that's not directly actionable by the Tor Launcher people yet: that would have to wait for some refactoring of the bootstrap reporting, which might get very hairy
17:41:45 <catalyst> so i'm trying to think of how can we get the Tor Launcher people some useful stuff ASAP without adding more tech debt to what we've got
17:42:32 <nickm> maybe we can improve error reporting or add events they wanted for some other part of the process ?
17:44:06 <nickm> or maybe we can write a quick spec of what the events _will_ look like, so that they can be ready for them
17:44:37 <catalyst> oh, having a translation layer between symbolic bootstrap phase names and progress numbers would probably help a lot; that way people won't be squinting at the new phases 1..4 that we add to handle intermediate PT and proxy phases
17:45:17 <catalyst> (the alternative would be having Tor Launcher do that translation on its own and that would be trickier)
17:45:55 <catalyst> but the translation would depend on whether proxies or PTs are configured
17:51:05 <nickm> true
17:51:21 <nickm> do you think we can get isabela the timeline she wants, or should we plan more first?
17:53:29 <catalyst> what is the tbb-team timeline like? maybe we can shuffle priorities to give them incremental usefulness in that window
17:55:33 <nickm> I think it's september some time, but I'm not 100% sure
17:55:52 <nickm> we're about at the end of our time though, so let's try to bang something into shape later today or tomorrow?
17:55:58 <catalyst> sure
17:56:00 <nickm> anything else for the next 4 minutes? :)
17:56:55 <nickm> #endmeeting