17:01:48 <nickm> #startmeeting network team meeting
17:01:48 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:52 <nickm> hello everybody!
17:01:58 <isabela> o/
17:02:08 <dgoulet> hi
17:02:11 <isis> hey hey
17:02:48 <nickm> it's the network team meeting. Welcome, all!
17:03:07 <nickm> This past week I reviewed a bunch of code and finished #15055.
17:03:18 <nickm> Once #15056 is done too, I will be a happy clam.
17:03:43 <nickm> I also just finished re-reviewing #17178 this morning, as well as https://trac.torproject.org/projects/tor/wiki/Prop271ImplementationPlan
17:04:28 <nickm> 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 <nickm> also last week I made the unit tests much faster
17:05:33 <nickm> 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 <nickm> err not that one
17:05:38 <nickm> #15055
17:05:56 <nickm> and I hope I can also help athena with prop#271 work.
17:06:01 <nickm> and write more docs
17:06:12 <nickm> maybe there should be another alpha next week too.
17:06:18 <nickm> Who's next with status?
17:06:47 <mikeperry> nickm: FYI: I noticed that the unit tests seem to be leaking memory from the fallback dirserver code..
17:07:14 <nickm> I tried master yesterday and got no memory leaks
17:07:21 <nickm> but i'll try again
17:07:36 <athena> status: chewing on #19858 for prop 271; nickm, do you need a code review for #15505?
17:08:03 <mikeperry> 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 <mikeperry> but otherwise I need to update my copperhead work to the new release
17:09:02 <nickm> athena: yes, I do.
17:09:08 <athena> alright
17:09:13 <mikeperry> 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 <nickm> though the stuff in review-group-8 should get done first
17:10:16 <nickm> the remaining unreviewed tickets in 8 are: #19998, #20001 (needs another review), #20063.
17:11:12 <nickm> 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 <athena> alright, sure
17:11:24 <nickm> mikeperry: I think all of those 3 are easy to review.
17:12:15 <nickm> anybody else around today?
17:12:54 <isabela> my update is that i will be working on organizing a meeting for the team in seattle
17:13:07 <nickm> 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 <isabela> 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 <dgoulet> 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 <nickm> athena: also, do you have a plan for revising your needs_revision tickets currently in TorCoreTeam201609 ?
17:16:40 <nickm> dgoulet: cool!
17:17:00 <athena> nickm: that's #18320 and #19552, yeah?
17:17:23 <athena> when is the cutoff for 0.2.9?
17:17:25 <isis> 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 <nickm> 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 <nickm> athena: I think that's right
17:17:59 <nickm> athena: We moved it back to 15 Oct, I think.
17:18:26 <isabela> nickm: athena yes oct 15
17:18:28 <dgoulet> 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 <nickm> keen
17:19:13 <isis> 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 <nickm> isis: european banks are weird.
17:19:54 <nickm> If I do the squashes myself, I can make sure that they really are squashed-as-advertised.
17:20:14 <athena> 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 <isis> hmmm… then we kill commit signatures…
17:20:51 <nickm> I am pretty concerned with "what I reviewed got merged"
17:21:06 <isis> fair enough :)
17:21:07 <nickm> when somebody squashes, I need some way to verify that what I said I liked really was what I merged.
17:21:51 <nickm> 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 <dgoulet> this ^ is a good thing to do to make sure the fixup commits actually merges properly
17:22:48 <mikeperry> 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 <dgoulet> which happens to me _all_ the time that the fixup spread over multiple commits...
17:24:16 <nickm> (I think we're on discussion now.  but if anyone has more updates, please join in!)
17:25:06 <mikeperry> (I'm on valgrind-3.10.0)
17:25:08 <nickm> I have a script I use to do a squash-but-don't-rebase.
17:25:21 <nickm> https://gitweb.torproject.org/githax.git/tree/scripts/git-resquash.sh
17:26:46 <nickm> 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 <nickm> I'm not going to bang on the tests like that for a little while, because...
17:27:58 <nickm> https://lists.torproject.org/pipermail/tor-dev/2016-August/011335.html
17:28:31 <nickm> 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 <nickm> other discussion topics today?
17:28:54 <nickm> I have on or two
17:28:59 <nickm> *one or two
17:29:16 <mikeperry> oh I added a test in channelpadding that tests a code block with a bug warning in it.. woops
17:29:38 <nickm> no worries
17:30:59 <nickm> Okay, I'll start with my discussion topics.
17:31:23 <nickm> 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 <nickm> 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 <nickm> 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 <nickm> And object :)
17:34:39 <nickm> 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 <nickm> 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 <nickm> any thoughts on best resolutions for that/
17:35:14 <nickm> ?
17:35:25 <dgoulet> nickm: hrm 4) is a good point and yes OnionService was indeed the goal for 224
17:36:04 <dgoulet> there is also a ticket to add alias for all HiddenService to OnionService as well...
17:36:23 <dgoulet> #17343
17:36:31 <nickm> It looks like RSOS will be ready for 029, and prop#224 won't, though.
17:36:33 <dgoulet> so one option would be to rename at once those
17:36:55 <dgoulet> or RSOS uses HiddenService and we change everything at prop224 which will be most probably 031
17:37:52 <nickm> 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 <dgoulet> HiddenServiceSingleHop was it? Coupled with NonAnymousMode
17:38:24 <dgoulet> you don't like that?
17:38:38 <nickm> I think that's not too bad
17:38:45 <athena> RendezvousSingleHop?
17:39:06 <nickm> that's not bad either. But see comment:79 on #17178, and maybe reply on-ticket?
17:39:25 <dgoulet> my main argument originally was to have the namespacing of hidden service in torrc
17:39:34 <dgoulet> thus starting with HiddenService (or OnionService at prop224)
17:39:36 <nickm> 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 <dgoulet> it's also an expert feature if you ask me ... so making it as clear as possible also helps
17:40:30 <dgoulet> nickm: yeah I'm with you on this, either HS or OS but not both
17:40:59 <nickm> 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 <dgoulet> yup agree
17:41:17 <nickm> ok. please comment on #17178 then :)
17:41:28 <nickm> other discussion topics?
17:41:43 <nickm> anyone really hoping for helpful stuff to do? :)
17:42:36 <isis> 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 <dgoulet> the more the merrier :)
17:42:55 <nickm> isis: I want everybody who is even a little interested or worried to review #19958 :)
17:43:21 <nickm> #15055 is tricky code, but #19958 has tricky implications that we need to think about
17:43:41 <nickm> (incidentally, wrt #15055 ... complete coverage.)
17:44:08 <isis> nice
17:45:29 <nickm> (Also incidentally, everybody should know about git worktree, if you don't already)
17:45:38 <nickm> Any other things for today?
17:45:41 <isis> for 2) how many people are we hiring?  what are their tasks?
17:46:09 <nickm> It will depend on budget, on which proposals get approved, and stuff like that.
17:46:35 <nickm> (This is in parallel with, and not a replacement for, getting more contractors employee status.)
17:46:54 <nickm> My long-term hope is that we have more people with generalized responsibility for tor.
17:48:03 <nickm> isabela: is that about right?
17:48:20 <isis> 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 <isabela> 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 <nickm> isis: you should use the PR that dgoulet already made
17:49:02 <isabela> 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 <isabela> etc
17:49:28 <dgoulet> isis: check on ticket, I made a merge_request already, the link is there :)
17:49:51 <isis> got it
17:51:31 <nickm> Any other discussion topics today before the next meeting starts? :)
17:51:56 * dgoulet is good
17:52:01 <isabela> +1
17:54:09 <isis> i'm good
17:55:32 <nickm> okay.  Thanks, everybody!
17:55:35 <nickm> #endmeeting