17:00:11 <nickm> #startmeeting network team meeting, June 25
17:00:11 <MeetBot> Meeting started Mon Jun 25 17:00:11 2018 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:20 <asn> hello :)
17:00:34 <nickm> Hello!   We have a pad over here: https://pad.riseup.net/p/JLbrbFfUn4fe
17:01:41 * asn reads updates
17:01:55 <nickm> There are a few of us out today, so we might not be able to do super-big decisions, but let's see!
17:02:48 <nickm> First: roadmap checkin.
17:02:53 <dmr> hello! I'm wrapping up an email and then should be full-attention on the meeting :)
17:02:54 <nickm> how are we doing?  any changes needed?
17:03:40 <nickm> I wonder if my work on refactoring src/common belongs under "technical debt reduction" or whether we should have a new roadmap item for it
17:03:59 <nickm> anybody else (paid) working outside the roadmap?
17:03:59 <arma3> it's kind of like modularity too
17:04:10 <ahf> it's very nice. good to see it has started landing
17:04:15 <asn> i'm almost done with #25552
17:04:42 <asn> i need to start looking at my other roadmap deliverables, like wtf-pad and bootstrap stuff
17:04:48 <asn> i need to get in touch with catalyst and mike on these
17:04:49 * ahf is making progress #25502 - hope to get to the point this week where i'm looking into the PT side of things
17:05:28 <asn> ahf: great. let me know if you need help with that. i wrote that code ages ago!
17:05:51 <nickm> next regular thing: reviewer assignments!
17:05:54 <nickm> (thanks asn)
17:06:12 <ahf> asn: might prod you about some stuff, but think for now it's good. it's mostly the big function that parses different commands from the PT that i'm going to look into
17:06:19 <asn> ahf: ack ack
17:06:37 <nickm> everybody okay with their reviewer stuff?
17:06:51 * catalyst requested a swap in #3569
17:07:10 <nickm> Can anybody take that one?
17:08:04 <nickm> also, do we have reviewers on #26479 and #26480 ?
17:08:12 <asn> yes
17:08:13 <asn> i did them
17:08:16 <nickm> oh. Thanks!
17:08:26 <nickm> catalyst: I can have a look at that; just set me as reviewer?  I th
17:08:28 <asn> moved them to merge_ready
17:08:33 <catalyst> nickm: ok
17:08:34 <nickm> I think I wrote that code, long ago.
17:09:29 <nickm> this week's rotations: nickm on triage, ahf on community, asn on coverity, catalyst on CI
17:09:31 <catalyst> nickm: thanks! review reassigned to you
17:09:39 <asn> ack
17:10:03 <nickm> coverity person and CI person : please remember that you aren't required to fix all the issues yourself: just make sure that somebody is looking and fixing them.
17:10:28 <nickm> any hand-off from last week's rotations?
17:10:41 <ahf> asn: for coverity i have some unsovled issues in #26467 that is related to the hidden services test. i'd like to finish them off, but i might ask for some help there
17:11:10 <ahf> coverity thinks the `service` variable isn't released in some of the tests
17:11:16 <asn> ahf: ack
17:11:22 <SimonHF> hello, thanks for letting me sit in in the meeting. not sure when is the best time to raise hand. am looking for feedback on [1].
17:11:25 <asn> ahf: you want me to take over for those issues?
17:11:26 <SimonHF> [1] https://lists.torproject.org/pipermail/tor-dev/2018-June/013205.html
17:11:50 <ahf> asn: i'll happily do them since they came up last week
17:12:07 <ahf> but i might ask for some help. hopefully when that ticket is closed a lot of the coverity issues will be closed too
17:12:24 <asn> ahf: sounds good. let me know when you need help
17:12:35 <asn> ahf: irc or email is good
17:12:42 <ahf> cool!
17:12:46 <ahf> probably going to be tomorrow
17:12:51 <asn> great
17:13:24 <nickm> SimonHF: I've added that to the discussion list!
17:13:39 <nickm> are we ready to move on to discussion?
17:14:06 <nickm> First two things are looking for volunteers for a longer task and a shorter task.
17:14:32 <nickm> In Seattle and before we talked about wanting to have somebody besides me handle backporting efforts for stable releases.
17:14:38 <nickm> Anybody interested in doing that?
17:14:58 <nickm> If so please let me know
17:15:29 <arma3> i am happy to play a supporting role but it's best done as the sort of thing that other network team people get better at
17:16:01 <nickm> Second one is shorter-term: remember how we tagged all the tickets in the 0.3.4 milestone to figure out what was in-scope for 0.3.4 and what wasn't?  I'm hoping somebody besides me might be interested in leading that process this time.
17:16:21 <nickm> (I can also help suppport this stuff)
17:16:44 <nickm> Anyways, please let me know if you're interested in taking either of those on.
17:16:54 * catalyst can also help support release-engineering type stuff, but would rather people newer to that stuff take the lead
17:17:18 <ahf> for 0.3.5? and what time frame do we have there? i think i have triage duty next week and i guess that could be integrated there?
17:17:39 <nickm> I guess I could start this week, and pass it on to you next week?
17:17:50 <nickm> "triage duty" is mostly for triaging incoming tickets
17:17:55 <nickm> doing a whole milestone is a bit bigger
17:18:30 <ahf> i'm fine with that model
17:18:35 <ahf> let's do that
17:18:39 <nickm> okay
17:19:06 <nickm> next topics are aEdded by teor:
17:19:48 <nickm> the integration of ooni with Tor seems to be something where that ticket is out-of-date?  Simone knows about tor_api.h and has been using it, IIUC
17:21:16 <nickm> I'll try to answer the PT one
17:21:27 <nickm> next: Do we want to rebuild the fallback list?
17:21:59 <kushal> At one of the ISP in India, I found 129 of them are blocked.
17:22:01 <nickm> I'm okay with it
17:22:06 <nickm> if we want to rebuild
17:22:18 <nickm> If people need censorship evasion, they probably need bridges though.
17:22:45 <kushal> True.
17:23:07 <nickm> Any thoughts on SimonHF's "trace" proposal?
17:23:17 <Phoul> If there is desire for the rebuild, I have told teor I'm happy taking that over. I've started getting things set up for that this morning. However I also agree that bridges seem like maybe a better solution.
17:24:02 <ahf> i think dgoulet might have some input to anything around tracing in tor
17:24:03 <Phoul> (also I will be attending future network meetings, just to stay in the loop better)
17:24:08 <nickm> cool
17:24:09 <arma3> the big question for the fallbackdir rebuild idea is: are the ISPs in india and/or venezuela likely to rebuild *their* censorship list too? or did they take one snapshot and they won't change, so if we change things suddenly it all starts working again?
17:24:29 <arma3> (in theory it shouldn't help, but in practice sometimes it does help.)
17:25:00 <nickm> arma3: If you have opinions, you should opine them.  And also opine what we do if they block the new list again in N months. :)
17:25:27 <nickm> I do not feel strong about the rebuild one way or another
17:25:59 <arma3> "if it's easy to make a new list, let's try it" "if they block the new list, we've learned something" "oh i wonder how tor behaves when half its fallbackdir list is blocked. like, do we have to throw out the existing ones, in order to give people a list that isn't half blocked in india and venezuela? that would be sad"
17:26:27 <nickm> arma3: ok.  Write that on the pad so teor sees it. :)
17:27:06 <ahf> isn't all of that related to the "PT role" that we talked about in seattle for someone to keep up with different countries and their filtering?
17:27:16 <nickm> SimonHF: so, I am fine with adding some mechanism to trace Tor's function calls into the logs.  I'd be fine putting it at debug, or with adding a new level for it.
17:27:22 <arma3> ahf: yes, but we don't have anybody in that role currently
17:27:54 <nickm> SimonHF: The big question is whether it should be in Tor by default, or whether it should require an external thing, or what
17:28:07 <ahf> arma3: yeah
17:28:40 <nickm> SimonHF: My preference is that it should be an optional feature enabled at compile time
17:28:51 <nickm> SimonHF: as for your strategy 4, I'm not so sure.
17:29:15 <arma3> i like the trace idea in theory. i am happy to leave the details to people with opinions on how to do it most sustainably.
17:29:18 <nickm> It sounds like you're writing a tool that post-processes GCC-generated assembly to add tracing
17:29:39 <nickm> That's cool, but I don't want to support that tool _inside tor_ as part of Tor's build process.
17:29:52 * dmr added small discussion note to the pad; catching up on meeting scrollback
17:29:55 <nickm> That is, Tor is complicated enough already, the way I see it:
17:30:07 <SimonHF> nickm: the method I propose in the email is gcc only, and Intel x86 only initially and if compiled in for other platforms / processors it would display a warning mesage saying not available
17:30:13 <nickm> I don't think we have the resources to support an assembly tool indefinitely.
17:30:34 <nickm> So, it sounds like you should write this tool to be tor-independent, and then we can see about allowing Tor to support it?
17:31:06 <nickm> I don't think we will commit to maintain this tool, but we can integrate with it, if it doesn't cause too much trouble.
17:31:15 <nickm> does that sound reasonable?
17:31:24 <ahf> how does this relate to the tor-trace code that is already in the repository?
17:31:31 <nickm> seems independent
17:31:35 <ahf> ack
17:31:36 <nickm> and/or orthogonal
17:31:56 <nickm> this is specifically for function-call tracing
17:32:08 <SimonHF> nickm: that sounds reasonable. would it be possible to host the tool with other tor tools related to tor, or completely separately?
17:32:44 <nickm> I think if you want to work on this, you should probably just put it on github
17:33:08 <nickm> It isn't a tor-specific tool, is it?  If it would work with any C program, you might as well just have it independent
17:33:55 <SimonHF> that might be a catch 22 because my employer is only willing to pay me to work on stuff of a non-profit organisation, and so github will therefore not qualify... :-(
17:33:57 <nickm> (You might also want to consider an identifier other than cwrap: there are a bunch of existing projects called cwrap)
17:34:29 <SimonHF> nickm: certainly not married to cwrap :-)
17:34:33 <nickm> Say you're doing it for tor then -- and put the code on github, and make it independent
17:35:20 <nickm> I'm not saying it's not for tor -- I'm just saying that if this would be useful to other projects, it should really be its own thing
17:35:21 <SimonHF> nickm: sounds good... I'll try to go that route and see if it will cause any issues...
17:35:29 <nickm> cool; thanks!
17:35:38 <SimonHF> nickm: thank you!
17:36:09 <nickm> looks like dmr has a question --
17:36:15 <arma3> simonhf: oh, one tiny afterthought: we try to get people to name their thing something more creative than "tor-foo" for various values of foo. since everybody who picks a tor-foo makes it so the next person wants to name their thing tor-bar. so, if you want help picking a creative name that is your own name, let us know. :)
17:36:20 <nickm> does anybody know how our automatic mirroring to github works?
17:36:21 <dmr> nickm: yar
17:36:42 <ahf> i think it's a bot htat weasel runs
17:37:10 <nickm> Okay.  dmr: Your next step may be to politely ask weasel if that is so.
17:37:15 <catalyst> ahf: i thought it was a hook script?
17:37:37 <ahf> hm, maybe - i thought it was a cronjob
17:38:03 <dmr> ahf, catalyst: either way, do you think that weasel would be the appropriate person to ask how it's set up?
17:38:05 <SimonHF> arma3: thanks for offering to help with the naming... yes please! any suggestions would be very helpful!
17:38:17 <ahf> dmr: i think so, yeah
17:38:34 <dmr> ok, will do that then! thanks all for helping move this forward!
17:38:48 <nickm> ok
17:38:54 <nickm> any more for this week, anybody?
17:39:23 * nickm waits 30s...
17:40:26 <nickm> okay, thanks everyone!  Please read everybody else's updates, if you haven't already.
17:40:30 <nickm> #endmeeting