16:58:59 #startmeeting weekly network team meeting, 8 August 2018 16:58:59 Meeting started Mon Aug 6 16:58:59 2018 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:03 hello 16:59:07 hi 16:59:07 hello 16:59:13 why hello there everybody! 16:59:37 hello world :) 16:59:39 ongoing pad is at https://pad.riseup.net/p/tor-netteam-2018.1-keep 17:00:33 ! 17:00:46 why hello to you too 17:00:47 :) 17:00:49 and hello komlo and isabela ! 17:01:07 \o/ 17:01:31 So we start with the roadmap. I sent around a roadmap revision pad last friday. I think we're mostly _not_ going to be adding stuff by default, but we should still discuss. 17:01:42 has everybody on network-team had a chance to look at that? 17:02:17 no. is it still in the google doc? 17:02:30 i think it's https://pad.riseup.net/p/huDStrBDgqi5 17:02:34 havent had the time to read it yet 17:02:36 see network-team email from 3 Aug. ... yeah, that 17:02:50 (hi mikeperry !) 17:03:46 mikeperry: a bunch of your items are in "maybe" on that pad because I didn't know the status; please let me know which are still planned for the deadline 17:03:53 merge window for 035 closes on 15 Sep 17:05:20 can everybody get to this today please? I'd like to revise the roadmap tomorrow or the day after, since I'm visiting inlaws thu->fri 17:05:26 thu->mon 17:05:36 ack 17:06:35 nexst are the reviewer assignments 17:06:49 this list is really stacking up. 17:07:07 nickm: I'm going to try to get the WTF-PAD stuff in still, but it is not super essential that it is. it just has to be in better shape to experiment with by then. 17:07:33 mikeperry: okay. do you have time to update the status on that pad? 17:08:04 ahf, catalyst, mikeperry: some of your review items look like they've been there for a few weeks. Are you stuck on anything? Anything the rest of us can do to help? Should we rebalance? 17:08:53 asn: will you be able to get to #27003 today? I don't know if I mentioned, but it is the only thing blocking 0.3.4.6-rc 17:09:02 oh i didnt get that last part 17:09:13 let me ee the PR 17:09:14 I probably forgot to say :/ 17:09:26 if it's not too complex i might be able to do it 17:09:32 thanks; it is pretty simple 17:09:38 at least, the change is 17:09:45 and ahf has already had a look 17:09:47 nickm: no, i think it's good. i have already been through the ones that have been there for a while, just didn't get back to them last week 17:09:54 I just want a "will it break the world" thing 17:09:56 crunched some of the easy ones last week since the list got a bit big 17:10:22 ok will do 17:11:40 nickm: the NSS ones are still in progress; cross-compiling doc still has stuff to resolve 17:13:17 On #26376, it looks like hello71 updated it 4 weeks ago; maybe reiterate whatever it is that still needs to be fixed and put it back in needs_revision? 17:13:56 nickm: yeah for my reviews a couple of them have been going back and forth with needs_revision. I am going to go through them again today 17:13:58 and #26464 is just siltting there 17:14:11 mikeperry: thanks! 17:14:11 nickm: probably best if one of us just makes the edits at this point 17:14:22 that would be fine too :) 17:14:28 *sitting 17:14:52 nickm: i'm happy to have someone else review #26464 if they have time 17:15:03 I'll take it on 17:15:28 thanks! 17:16:35 next is rotations: I'm on bug triage, teor's community, ahf is meeting scheduling, and asn is CI+Coverity 17:16:54 I don't have any community stuff to hand off, I'm afraid 17:17:06 ack 17:17:22 the proposed ticket list, we're looking at as a part of the roadmap discussion (see above) 17:17:25 i wrote a comment on that. if anybody is up for switching with my duties the next 3 weeks i'd be very happy for that 17:17:33 i'm gona from wednesday until the 23rd 17:17:36 gone* 17:17:52 I love bug triage; I'll happily do an extra week of it next week. 17:19:03 it's CH next week for me, bug triage in two weeks 17:19:04 err, in 2 weeks 17:19:18 do we need a replacement for the design docs person this week? 17:19:29 i think it'll be ok 17:19:39 ok, then it's just finding a CH person next week :-) 17:20:36 ok, if nobody feels like it, we'll look next week 17:20:50 ack, cool 17:21:13 Let's see. We've done the next 2 discussion topics already (roadmap & reviews) 17:21:39 teor asks about whether we can change the rotation schedule so that we're not always on 4 weeks in a row 17:21:50 gman999: ggus: sorry! I'm still at dayjob here and could not follow it as I wanted to. point haty here for me <:( 17:21:51 I would be fine with that; any objections? 17:22:12 * ahf OK with that 17:23:03 * catalyst also ok with that 17:23:12 How about I revise the schedule starting on 1 September? 17:23:24 that will give us some warning time 17:23:59 wfm 17:24:04 sure 17:24:10 ok, if there are no objections let's do that 17:24:17 on to other discussions! 17:24:26 I already mentioned my stuff 17:24:32 mikeperry: you have a few items! 17:24:37 I have questions. yes :) 17:25:11 so I have some deep discussion about RPs that we can move to #tor-dev later if people are still here 17:25:25 let's do the short version of each :) 17:25:28 but I also want to discuss #25573 17:25:39 me too 17:26:06 the short version of the RP thing is: do relays extend to anything you ask them to, or does it have to be in their consensus? 17:26:27 oh. That one I answered on the pad, but asn might have more to say 17:26:33 no i agree with the pad answer 17:26:46 they will extedn to anything you ask them too because consensuses are not synchronized accross client 17:26:47 s 17:27:01 so then the answer is "yes, you can ask a relay to extend to anything on the internet, and if it speaks Tor, it will work"? 17:27:06 yep 17:27:10 thats my understadning 17:27:16 it's a well-known anti-feature 17:27:31 hrmm.. that's not great.. allows portscanning and makes my life harder.. 17:28:06 the deeper question of "what should I do about that" is deep. let's table that for after because there's a lot there 17:28:07 if you want to change that, it will need a proposal and some tough analysis. 17:28:21 ok 17:28:43 nickm: hey please let me know if it's ok to review #27003 tomorrow. it looks legit, but it's not as simple as i thought and i want to run a few tests to make sure. 17:29:44 asn: okay. I don't like delaying the rc any more, but I sure don't want to release a broken rc :) 17:29:50 so yeah, please run those tests 17:30:00 mikeperry: what's the next topic? 17:30:09 for #25573, it doesn't have to block 0.3.4-stable, but I would like a backport.. again, it doesn't change any behavior. it only changes what gets added to fields in CIRC_BW, and not beyond what the spec says (in fact, it brings it in line with what the spec says) 17:31:24 so it can bake in master if we want. I just found instances where PATH_BIAS circs are also not being properly counted in CIRC_BW either. so I have another fixup for that branch.. 17:31:26 I'd say in that case: let's keep developing it against maint-0.3.4 so that a backport will be feasible if we do it... 17:31:56 but let's let it cook in master first, and discuss a backport after it's had a review and some testing 17:31:59 but it makes vanguards a *lot* less noisy with it in, hence it would be ideal if it is in 0.3.4 eventually 17:32:13 or we could just say "vanguards should run 0.3.5 or later" 17:32:32 that's mainly for client-side vanguards right? perhaps we can ask client-side vanguards to run 035 or later? 17:32:43 I would like to avoid that. it means it takes much longer to figure out how well these defenses work 17:32:58 yes but you know why I am saying "let's be careful", right? 17:33:06 asn: no there are instances where overloaded services can trigger the half-closed problem also.. 17:33:17 hm ack 17:33:23 nickm: I am not sure what the risk is, actually, other than like memory issues or something 17:33:47 It is after freeze, 9 days before the scheduled release date, and you are asking me to merge a new feature of several hundred lines which nobody has reviewed yet. 17:34:24 this code is spread across crucial functions in several files 17:34:37 I don't see it as a feature. I see it as a bugfix of the spec, and of a feature that was in 0.3.4 from early enough on for us to find bugs in it 17:34:59 I do see it as a feature. It is adding code to track something Tor hasn't tracked before. 17:35:12 It sounds like a good feature, mind you 17:35:13 I see this as like refusing to take a bugfix in an 0.3.4 feature and disabling that feature instead.. which feels crummy because i tried hard to get this in as early as possible to find bugs like this 17:35:43 (where that feature is "let the control port know what cells tor decided to drop" (and not even change behavior based on that) 17:36:26 I am not proposing that we disable the feature 17:36:53 like unless we're worried about memory leaks (which is legit, but that can happen with anything), I still don't see the risk.. 17:37:25 nickm: functionally that is what refusing to take this bugfix means. it means CIRC_BW is wrong, and can't be used in 0.3.4, which is akin to disabling it... 17:38:04 I could put the whole thing behind a check to see if CIRC_BW events are being listened to 17:38:11 which will further reduce risk of memory issues 17:38:12 It doesn't seem like we're going to get this resolved right now. 17:38:27 let's work on getting it reviewed and merged to master, than talk more later? 17:39:20 I certainly do not want to advocate a meta-principle that "If somebody merges a feature early in a release cycle, then they can land arbitrarily big bugfixes for it arbitrarily late in the release cycle." 17:39:38 But I don't think you're advocating for that; I think you're saying that this is in fact much simpler than it looks to me right now 17:39:53 yes, the latter 17:40:18 im unable to comment on this rn because i dont even know what a half-closed stream is at this point 17:40:22 i need to check the paper 17:40:27 and it could be made less risk if we want (like turning it off if CIRC_BW is not on), but that is also a different kind of complexity, I guess.. 17:40:33 then the right approach probably is to merge forward with review in 0.3.4 and merging in master and considering a backport afterwards. 17:40:34 hence i cant really comment on what the patch does 17:41:16 Also we should figure out why this didnt' turn up in the original testing, so we can test the next thing better :) 17:42:19 nickm: short answer wrt testing: I thought it didn't matter for service-side, only for clients, untill I heavily stress-tested a live service-side instance with it 17:42:27 ok 17:42:48 mikeperry: more discussion topics for this week? 17:43:16 that's it for me. I will ask my RP detail questions in #tor-dev after 17:43:21 ok 17:43:52 catalyst: wrt prop#295 I'll send ashur a quick "hey did you see those" email today 17:44:10 also catalyst has a question for mikeperry and komlo 17:44:29 nickm: thanks 17:44:54 ah, just saw that q 17:45:02 catalyst: yes. I think all three posts should link to eachother, too 17:45:18 catalyst: sure, go for it- maybe link to the posts as well? 17:45:21 related: I forgot I had a question about our research topics page. forgot about that one. who maintains that? 17:45:22 +1 17:45:30 komlo, mikeperry: thanks! 17:45:32 mikeperry: arma3 would know 17:46:16 mikeperry: planning a meeting in Mexico about it -- could be part of the website redesign, after we finish the dev portal 17:46:17 we had a comment on a post that we should have a "quick links" page, probably all three posts should be on that? along with others i don't know about 17:48:31 * nickm has just emailed tomer 17:48:42 there is a section for research on the dev.tpo site 17:48:44 any more discussion topics for today? 17:48:50 antonela: ok. the material that needs to be replaced is currently on research.torproject.org, which may or may not be a different beast than a dev portal 17:49:24 ahf: quick query for you btw. When will there be some preliminary memory profiling data that we can start trying to improve? 17:49:25 when we did the wireframes we spent some time with arma on it - maybe would be good to review that too 17:49:26 just a quick note to think about outstanding Rust questions/issues we have- i'm going to send an email to aggregate these, and will try to get answers when I'm at RustConf 17:49:38 mikeperry, isabela : yes! we want to sync on that content re: irl 17:49:57 komlo: awesome! Make sure to give a timeline; I've already forgotten when rustconf is :/ 17:49:59 nickm: doubtful withh the current tasks i have for today and tomorrow :-/ 17:50:37 nickm: RustConf is the 16th/17th, so we have some time to prep. i'll send that email Wednesday hopefully 17:50:53 ahf: ok. Can you make sure in that case that you leave the task in a state where dgoulet can pick it up once he's back? Or will it need to wait till you return? 17:51:10 nickm: he can pick it up from where we are now, we talked about it before he left 17:51:15 In the latter event I think I'll split the roadmap item into "low hanging fruit" for 0.3.5 and "trickier stuff, if any" for 0.3.6 17:51:24 oh. great! 17:51:29 komlo: thanks! 17:51:33 nickm: we actually talked about whether any of us would be able to make progress with this before we leave, because we left at different times 17:52:21 7 minutes left. any more topics for today? 17:53:23 hearing none, I thank everybody, and proclaim the meeting adjourned! 17:53:32 o/ 17:53:35 thanks! 17:53:40 thanks everyone! 17:53:42 #endmeeting