17:01:48 #startmeeting network team meeting 17:01:48 Meeting started Mon Sep 12 17:01:48 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:52 hello everybody! 17:01:58 o/ 17:02:08 hi 17:02:11 hey hey 17:02:48 it's the network team meeting. Welcome, all! 17:03:07 This past week I reviewed a bunch of code and finished #15055. 17:03:18 Once #15056 is done too, I will be a happy clam. 17:03:43 I also just finished re-reviewing #17178 this morning, as well as https://trac.torproject.org/projects/tor/wiki/Prop271ImplementationPlan 17:04:28 This week I will NOT be reviewing anyone's code other than #17178 till all the remaining stuff in review-group-8 is reviewed. Then I'll start looking at review-group-9, which should be fun 17:04:54 also last week I made the unit tests much faster 17:05:33 This week I hope I can revise #19958 and implement #15056, though doing so will be a challenge without #19958 and #15505 being merged 17:05:36 err not that one 17:05:38 #15055 17:05:56 and I hope I can also help athena with prop#271 work. 17:06:01 and write more docs 17:06:12 maybe there should be another alpha next week too. 17:06:18 Who's next with status? 17:06:47 nickm: FYI: I noticed that the unit tests seem to be leaking memory from the fallback dirserver code.. 17:07:14 I tried master yesterday and got no memory leaks 17:07:21 but i'll try again 17:07:36 status: chewing on #19858 for prop 271; nickm, do you need a code review for #15505? 17:08:03 I also posted patches for #16861 and children. if there tickets that I would be a good reviewer for in review-group-8, I can take a couple 17:08:33 but otherwise I need to update my copperhead work to the new release 17:09:02 athena: yes, I do. 17:09:08 alright 17:09:13 nickm: I will get you an example test that has valgrind leaks in a sec (along with the valgrind command I used) 17:09:15 though the stuff in review-group-8 should get done first 17:10:16 the remaining unreviewed tickets in 8 are: #19998, #20001 (needs another review), #20063. 17:11:12 athena: IOW, please prioritize review-group-8 before review-group-9. I think that #19958 could use an additional review beyond dgoulet's review, since this is a very important change. 17:11:19 alright, sure 17:11:24 mikeperry: I think all of those 3 are easy to review. 17:12:15 anybody else around today? 17:12:54 my update is that i will be working on organizing a meeting for the team in seattle 17:13:07 athena: can you say a little more about what part of prop#271 you'll be doing this week? And do we have a realistic shot of getting it done, tested, and merged for 0.2.9? 17:13:50 more details to come but in general should be stuff we have done before like roadmap retrospective, also revive the trac session thread etc 17:14:44 unfortunately, few reviews on small things last week, I had to deal with personal stuff so I'm back full speed this week with #19958 review this morning and will follow with addressing #17238 review after this meeting 17:15:19 athena: also, do you have a plan for revising your needs_revision tickets currently in TorCoreTeam201609 ? 17:16:40 dgoulet: cool! 17:17:00 nickm: that's #18320 and #19552, yeah? 17:17:23 when is the cutoff for 0.2.9? 17:17:25 last week i did #20087, #20088, debugged why bridgedb's CI was giving weird errors/failures suddenly, continued work on #12030 and #12031, and arranged travel to the dev meeting (which strangely involved physically going to the airport to pay the airline since i don't yet have a bank account in this weird country) 17:17:38 for dgoulet, and anybody else with a ticket that got reviewed in gitlab: have a look at how teor did responses for #17178 on gitlab. I am not a fan of fixup! fixup! fixup! fixup!, but the way that the discussion linked to the commit that did the corresponding fix was really helpful. 17:17:50 athena: I think that's right 17:17:59 athena: We moved it back to 15 Oct, I think. 17:18:26 nickm: athena yes oct 15 17:18:28 nickm: I fortunately started doing that as well with asn so you'll be my second attempt at providing clean fixup commit with IDs in the comment :) 17:18:55 keen 17:19:13 if we do fixup! fixup! fixup! and then link to it, is it okay to squash it down after approval or is this still bad form for being hard to reason about post-squash? 17:19:20 isis: european banks are weird. 17:19:54 If I do the squashes myself, I can make sure that they really are squashed-as-advertised. 17:20:14 hmm, for prop271 it logically splits into several phases of derving different guard sets from each other - i suggest we can work concurrently on those components once we have the data structure stuff from #19858 in place, which is what i'm doing right now 17:20:28 hmmm… then we kill commit signatures… 17:20:51 I am pretty concerned with "what I reviewed got merged" 17:21:06 fair enough :) 17:21:07 when somebody squashes, I need some way to verify that what I said I liked really was what I merged. 17:21:51 maybe rebase it onto the same point on the branch, **as a new branch**, and I can verify that git diff master...old_branch and git diff master...new_branch are identical? 17:22:38 this ^ is a good thing to do to make sure the fixup commits actually merges properly 17:22:48 nickm: 'valgrind --leak-check=full --show-leak-kinds=all ./test --no-fork channel/multi' is one example that leak the fallback dirserver stuff, and some other things. lots of other tests do too. in fact, just doing 'valgrind --leak-check=full --show-leak-kinds=all ./src/test/test' will show a bunch of things 17:22:55 which happens to me _all_ the time that the fixup spread over multiple commits... 17:24:16 (I think we're on discussion now. but if anyone has more updates, please join in!) 17:25:06 (I'm on valgrind-3.10.0) 17:25:08 I have a script I use to do a squash-but-don't-rebase. 17:25:21 https://gitweb.torproject.org/githax.git/tree/scripts/git-resquash.sh 17:26:46 mikeperry: okay. If it's showing up with valgrind but not --enable-expensive-hardening, then it's probably a still-reachable thing that should get added to our free_all functions sooner or later 17:27:10 I'm not going to bang on the tests like that for a little while, because... 17:27:58 https://lists.torproject.org/pipermail/tor-dev/2016-August/011335.html 17:28:31 I spent a lot of time getting that to work, and I'm kinda burned out solving other people's cosmetic bugs 17:28:47 other discussion topics today? 17:28:54 I have on or two 17:28:59 *one or two 17:29:16 oh I added a test in channelpadding that tests a code block with a bug warning in it.. woops 17:29:38 no worries 17:30:59 Okay, I'll start with my discussion topics. 17:31:23 1) I have been commiting thing that change how the unit tests work, without review. I hope somebody is sorta skimming them? 17:32:54 2) We should get more brains on this team. Soon it will be time to hire. Please think if there's anybody you want us to reach out to, or anything we should really consider. 17:33:33 3) Everybody who thinks they might complain about prop#264 getting implemented in a bad way they don't like should at least read it. 17:33:37 And object :) 17:34:39 and 4: I have a concern about teor's RSOS branch, which is that he's using the OnionService* names. I worry that if we introduce OnionService* for RSOS, before we rename the rest of the HiddenService* stuff to OnionService*, people will think that OnionService means RSOS. 17:35:07 teor says that dgoulet and asn would like to defer the complete OnionService* rename for the implementation of prop#224, which I do sympathize with. 17:35:13 any thoughts on best resolutions for that/ 17:35:14 ? 17:35:25 nickm: hrm 4) is a good point and yes OnionService was indeed the goal for 224 17:36:04 there is also a ticket to add alias for all HiddenService to OnionService as well... 17:36:23 #17343 17:36:31 It looks like RSOS will be ready for 029, and prop#224 won't, though. 17:36:33 so one option would be to rename at once those 17:36:55 or RSOS uses HiddenService and we change everything at prop224 which will be most probably 031 17:37:52 I like that idea, but I haven't been able to find a phrase for NotHiddenService that teor likes in his options. If you can think of anything and comment on #17178 about it, that would be really helpful 17:38:19 HiddenServiceSingleHop was it? Coupled with NonAnymousMode 17:38:24 you don't like that? 17:38:38 I think that's not too bad 17:38:45 RendezvousSingleHop? 17:39:06 that's not bad either. But see comment:79 on #17178, and maybe reply on-ticket? 17:39:25 my main argument originally was to have the namespacing of hidden service in torrc 17:39:34 thus starting with HiddenService (or OnionService at prop224) 17:39:36 Also it would help me to get a reality check on whether the concern I mention (that people will think "onionService" means rsos) is valid? 17:40:17 it's also an expert feature if you ask me ... so making it as clear as possible also helps 17:40:30 nickm: yeah I'm with you on this, either HS or OS but not both 17:40:59 If we have the user say "HS" when they want anonymity and "OS" when they don't, they will think "OS" means "no anonymity". 17:41:15 yup agree 17:41:17 ok. please comment on #17178 then :) 17:41:28 other discussion topics? 17:41:43 anyone really hoping for helpful stuff to do? :) 17:42:36 dgoulet: do you want someone else to also review #19958? my handshake stuff needs it, so i should probably review too, but i don't want to step on your toes 17:42:54 the more the merrier :) 17:42:55 isis: I want everybody who is even a little interested or worried to review #19958 :) 17:43:21 #15055 is tricky code, but #19958 has tricky implications that we need to think about 17:43:41 (incidentally, wrt #15055 ... complete coverage.) 17:44:08 nice 17:45:29 (Also incidentally, everybody should know about git worktree, if you don't already) 17:45:38 Any other things for today? 17:45:41 for 2) how many people are we hiring? what are their tasks? 17:46:09 It will depend on budget, on which proposals get approved, and stuff like that. 17:46:35 (This is in parallel with, and not a replacement for, getting more contractors employee status.) 17:46:54 My long-term hope is that we have more people with generalized responsibility for tor. 17:48:03 isabela: is that about right? 17:48:20 for the gitlab review process, i am supposed to make a PR containing nickm's branch and then comment on it, right? 17:48:30 yes and this is also in the agenda for the team meeting in seattle but i think it wont be the last time we talk about it 17:48:41 isis: you should use the PR that dgoulet already made 17:49:02 but for folks who wont be there, some of the preparation will be helpful, like knowing what we put on those proposals to have an idea of what work it will be 17:49:05 etc 17:49:28 isis: check on ticket, I made a merge_request already, the link is there :) 17:49:51 got it 17:51:31 Any other discussion topics today before the next meeting starts? :) 17:51:56 * dgoulet is good 17:52:01 +1 17:54:09 i'm good 17:55:32 okay. Thanks, everybody! 17:55:35 #endmeeting