17:58:44 #startmeeting weekly network team meeting, 12 Feb 2018 17:58:44 Meeting started Mon Feb 12 17:58:44 2018 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:44 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:46 hi everybody! 17:58:51 hello 17:58:51 hello 17:58:57 The pad is at https://pad.riseup.net/p/EnY0SmPlSweq this week 17:59:00 hello people :) 17:59:09 hi all 17:59:24 I'm typing to you from a comfy couch in the MIT student center 17:59:35 aha 17:59:45 I have well-timed insomnia 17:59:49 ! 17:59:51 teor4: gosh! 17:59:52 nickm: comfy but how clean? ;-) 18:00:04 hey 18:00:05 wild teor4 , love it 18:00:07 catalyst: well, I wouldn't lick it. 18:00:31 lol 18:00:37 * asn reads reports 18:01:15 (If you're done with your report, please read everyone else's. If you're not, please write your updates!) 18:01:54 oh awesome, teor4 is here! 18:04:03 isis: mind if I remove your trailing whitespace 18:05:58 thanks 18:06:20 * isis reads 18:06:58 ok! another minute or two, then let's start discussing stuff! I'd like my stuff to go last, since it's open-ended 18:07:05 remember to put discussion stuff in boldface 18:08:38 let's start with isabela 18:08:52 isabela: you sent out that plan about doing both short-term and long-term planning in Rome. 18:09:01 Anything you want to say or discuss about that? 18:09:44 (reminds that friday feb 16 is deadline for us to finalize the list of 'areas of work') 18:10:04 put a link in the pad? 18:10:06 so the hackfest is now over the memorial day weekend? or no, it starts the wednesday after memorial day, and goes over the next weekend? 18:10:13 yes is there 18:10:20 nickm: is on discussion part 18:10:57 isis: Wednesday 30th, after memorial day, to Sunday 3rd 18:11:43 accommodation and travel are expensive otherwise, and we'd have to get someone to open the office 18:11:48 isabela: can we just add things we find relevant there with our nick to it? i'd like to "shove" some mobile things into it 18:11:51 teor4: cool thanks 18:11:56 teor4: i have the keys 18:11:59 teor4: oh, it's also in the office? 18:12:48 ahf: yes sure (undercore or mark like [ahf: xxxxxx] just some visual way to know is an add/edit 18:13:05 ahf: for folks w collors off 18:13:16 yep, cool 18:14:00 isabela: cool 18:14:06 i will do a mid week check on this pad 18:14:16 and try to close the deal by friday :) 18:14:23 Do we need to find places for crypto, ipv6, and dirauths? 18:14:42 isabela: this is looking like a list of stuff that is current medium-term focus, more so than long-term focus? 18:14:43 teor4: armadev thinks of crypto more of a how 18:14:49 that is why is not under anywhere 18:14:56 but the others are kind of open still to be placed 18:15:20 nickm: sure, i think we need to look at areas of focus that works all the time 18:15:24 not just now or future 18:15:30 that we should care all the time 18:15:41 if they exist now we list them anyways 18:15:45 it means our work is to build them 18:16:05 ok 18:16:17 ok, so TLS 1.3 and ipv6 both fit in as "standards upgrades" 18:16:25 so let's talk some time then: I think a lot of these things only matter for "next year or two" 18:16:28 not sure about dirauths 18:16:47 nickm: is ok, we will review it periodically too 18:17:17 yeah, we should note that some things are not this team's job. We don't oversee dirauths for instance. 18:17:28 is this document going to be encoded into what? future grant proposals? the roadmap? something third? 18:17:42 nickm: but we responsible for dirauths code 18:17:53 yes, but not for actually running them 18:17:55 yes, folks needs to think of this as an area of work where we would set a goal and have tasks under it for the team 18:18:02 so if your topic can't have that 18:18:05 maybe is not for this list 18:18:47 nickm: do we build featuers for dirauth ppl tho? 18:18:54 sometimes! 18:18:57 or do we need to set goals to have features 18:19:13 hm, ok 18:19:20 so it's "areas where we will build features sometimes" 18:19:28 so maybe that stays and we do what we think should be done now or whenever in the future there is something to be done 18:20:18 is ok if we are just on maintainance for an area for a while to focus on others if there is nothing urgent to be done there, you know what i am saying? is a map of things we should think of when planning 18:20:22 plans will change over time 18:20:34 but this should be the things we think when doing those 18:20:51 i can see for instance 18:21:06 areas here where we will have a lot of work for the 6 months roadmap and some where there wont be none 18:21:18 I merged the leftover and unsorted sections 18:21:23 and some where we will have more stuff for the 2019/2021 planning 18:22:20 more discussion on this? 18:22:38 isis -- you wanted to discuss something about the meeting later on, or just make sure folks know about it? 18:22:51 just make sure people knew it existed :) 18:23:42 happy to see UTF-8 more places, i remember seeing weird encoding issues when i used my surname in the contact info of my old relay :'( 18:23:52 nickm: cool! you are taking a class on coq, sounds rad 18:24:23 catalyst: got a patch for the check-changes issue? 18:24:29 if not i can write one quick 18:24:38 nickm: sorry, i don't have one handy 18:26:11 ok, more topics: 0.3.3 is now wrapping up. We're hoping to have it stable soon -- scheduled date is Apr 15, but it would be great to finish ahead of time for once 18:26:28 this means we need to identify the must-fix stuff ASAP, and fix it together... 18:26:41 I can try, but my sense of must-fix is pretty loose 18:26:47 and I am likely to miss stuff 18:26:51 any suggestions how we should do this? 18:26:57 keyword? 18:27:27 should we do a meeting? or each person for themselves? 18:27:33 how have we done this best historically? 18:27:43 we've never done it terribly well historically :( 18:28:07 Maybe we should all do individual markup this week, with plan for a meeting about it next week? 18:28:26 it's basically a triaging job. i remember we did a good one in real life in seattle? 18:28:39 individual markup with a keyword? :-) or in a google docs sheet or something? 18:28:41 also the spreadsheet approach worked 18:28:45 If there's something you think needs to get fixed for 0.3.3, please tag it with must-fix-before-033-stable 18:28:53 ok 18:29:00 unless you'd rather do spreadsheet? 18:29:11 * catalyst prefers shorter tag names 18:29:17 how about 033-must ? 18:29:22 I do too, but people are apparently using that one already... 18:29:37 I'm fine with 033-must, but if you use that, please make sure the must-fix-before-033-stable ones change to 033-must 18:29:41 +1 "033-must" 18:29:52 follows our "033-backport" kind of pattern 18:30:08 And finally, let's use "033-must" sparingly, especially if it is something that you yourself will not fix. :) 18:30:20 next topic: 0.3.4 merge window opens soon! Woo! 18:30:33 nickm: +1 and we should "Owner" as much as possible as well 18:30:37 nickm: i.e., if we're already assigned it's our own job to keep track of? 18:30:38 how can we make sure that this release goes well? 18:30:56 I consider the "New" ticket often like orphans so this is the pile I look to for fixing things 18:31:11 so the idea is that after this week, anything that is not 033-must can be pushed to 034? 18:31:16 catalyst: more like, "If you are saying 'I must do this' that is a lighter matter than saying 'You must do this'." 18:31:46 asn: can be, but might not be for a little while. I'll still take typo fixes even if they aren't "must" for instane. 18:31:49 *instance 18:32:51 isabela: I tried to add areas to the uncategorised topics on the pad 18:33:07 teor4: thank you 18:33:10 for 0.3.4 -- what can we do better this time? What should we make sure to do again? 18:33:12 can you check and move them if you like them? 18:33:19 yes 18:33:58 nickm: if we can have a list of features we want tin 034 that is "A, B and C" are the big blocks going in, we can focus on those while in merge window 18:34:28 if we know what is expected to go in 034 (as enhancement), it is much easier to do follow up on them 18:34:41 my two cents ^ 18:34:50 if you want to do a ticket in 0.3.4, go for it, but if you want someone else to do a ticket, put it in 0.3.5? 18:34:54 teor4: i will wait for more feedback before saying what is what / since everyone here knows better then me so i am hoping we think this through together. thanks for the suggestions and i will make sure to remind folks to also look at them and think about it 18:34:57 dgoulet: okay. Do we have such a list? 18:35:02 teor4: +1 18:35:17 (or unspecified?) 18:35:32 nickm: not that I know of :S ... we did for 032, then 033 we did not and 034 I have no idea what we plan as enhancement that is non trivial patch set 18:35:50 privcount in tor 18:35:54 that is oen ^ 18:35:59 that's a big one :) 18:36:02 i would like to get the large create cells in, and also the changes to ntor 18:36:05 we could do an email thread about this 18:36:16 let's try that 18:36:22 or pad or what not but we should flag those tickets and try as much as possible an early merge 18:36:26 I hope I get to code this time :) 18:36:44 I feel like I've been release-engineering for ages :/ 18:36:58 nickm: do you want others to do some release engineering? 18:36:59 nickm: that's how it often is 18:37:15 in 034? 18:37:19 nickm: is there any way for us to help with releases? did ahf and i doing alphas help? 18:37:22 Linus world with the kernel, no coding, just mergin... :( 18:37:23 nickm: what can we do to help with this? 18:37:35 we tried the thing where isis and i did a release and i don't think we have done that afterwards? 18:38:08 yeah that was not so hard, we could do maybe alpha rotations? 18:38:13 that could be fun, but it's not just doing the releases. It's reviewing all the patches, staring at the bugtracker, prioritizing everything, etc 18:38:34 maybe we can brainstorm stuff and come up with ideas? 18:38:40 I'd love to have more folks making alphas 18:39:04 yeah 18:39:05 I think there is an argument to be made that review group could be done in rotation or just some other people 18:39:13 by some* 18:39:26 how can we get more reviews in 034? Or better reviews? 18:39:44 dgoulet: +1 18:40:20 So, first thing I do each day is check for code reviews to do and patches to merge. 18:40:35 I could back off from that and let others give it a try? 18:40:51 dgoulet: rotation is good: "review all the tickets, call in help if you need it" 18:40:52 We could make expectations that everybody should look at tickets in every review-group, barring exceptional circumstances? 18:41:31 so yes that ^ I think we should try as much as possible to pick tickets to review in a review group as part of our weekly meeting for instance 18:41:55 teor4: yes, which as a bonus makes us each more aware of what is going on 18:41:59 nickm: if it would help you, i think it could be worth it - we obviously cannot merge the patches though 18:42:01 we have a "reviewer" field; do we not use it for assignment purposes? 18:42:06 we do 18:42:28 i try to remember to use it if i'm reviewing a ticket and i'll be taking more than a few minutes to do so 18:42:32 okay. so, review-group-32 is open. I'll take whatever tickets nobody else takes. There are 17 needs_review tickets and 8 of us here (minus isa). 18:42:42 everybody take two tickets, and please don't just take the very easiest? 18:42:53 I'll take whatever nobody else wants. 18:42:59 (and maybe prioritize 033 tickest since the merge window is not opened yet?) 18:43:09 that's a rough job 18:43:11 for 034* 18:43:12 Maybe when I make a new review group, I should say how many each person should take to do it fairly? 18:43:24 teor4: what is? 18:43:32 the tickets no-one else wants 18:43:47 yeah 18:43:52 but it's what I've been doing anyway 18:44:06 and 18:44:23 how about if a ticket goes without a reviewer for X number of weeks, we make a point to talk about that explicitly? 18:44:30 and "the 2-3 tickets nobody else wants" is much easier than "80% of the tickets I did not write myself." 18:44:45 catalyst: we should do that; I've been trying to explicitly hunt down reviewers for stuff too 18:45:13 And the "review-group" fifo is kind of an attempt to make it everybody's business: while there is unreviewed stuff from RG32, don't expect other stuff to get merged. 18:45:23 e.g., maybe the reason nobody wants to review it is it's horribly complicated and not suitable for a single person to review 18:45:47 i took #24658 #25150 and #25071, lmk if anybody else really wanted those since i'm happy to take whatever 18:45:49 thus the important of having a owner on the ticket ^ on which you can seay that 18:46:08 catalyst: it happens actually ofen that we do explicitly mention on the ticket "to complicated, can you split this and this" 18:46:10 I am 100% happy with folks teaming up, yeah 18:46:25 i can actually take more tickets too, those are all likely quick to review 18:46:56 isis: cool; maybe circle back once you're through the moat stuff that's due on the 15th? 18:47:06 I don't want to pull you away from stuff you're committed to 18:47:39 ah yeah, good point 18:48:03 I'll take #25171 18:48:16 and whatever else :) 18:48:17 oh also apparently the bridgeauth is not able to find its key again, *sigh* 18:48:32 We're running short on time -- any more discussion for this week, awesome haxxorz? 18:48:51 034 features, who starts that thread? 18:48:56 (or pad) 18:49:04 also the bridgeauth appears to have intermittent hardware failures and a failing RAID1 drive :( 18:49:06 dgoulet: if you did, I would be grateful 18:49:11 I did the keyword switch to 033-must 18:49:23 teor4: thank you! 18:49:33 nickm: ok so I'll start the tor-dev thread, lets try to also have ticket for each so we can track them and not over commit ahha 18:49:44 great 18:50:24 in my experience ,most of the review group tickets that go without reviewer is not because they are complicated but because they belong to a subsystem that no one feels comfortable with 18:50:52 and we have many subsystems with no "maintainers" except from nick 18:51:17 maybe we need to explicitly change that 18:51:25 like, just stick people onto systems 18:51:27 yes 18:51:31 i think so 18:51:31 maybe we should arrange for nick to cluedump about those 18:51:41 the code can be hairy, but everybody here has learned stuff that they didn't know before by diving in 18:51:57 I'm always glad to hear the sound of my own voice, either literally or metaphorically :) 18:52:00 just ask! 18:52:27 +1 on the subsystem 18:52:37 the networking stuff (conns/channels/circs) is one of those unmanaged subsystems 18:52:42 which basically fall into nick 18:52:51 speaking for myself, the reason i don't review some tickets (even after reading the entire ticket and patch) is because i'm not 100% confident in my knowledge of that area of the codebase 18:53:15 for instance, I expect to get all the HS/SR/DoS stuff dumped on me and I can "un-owner" if I have no time but at least it falls under me to do the proper triage at that point 18:53:23 (of HS/SR is shared with asn :P) 18:53:39 asn: actually I think dgoulet understands it pretty well thanks to all the kist stuff 18:53:45 didn't we have a pad or document somewhere trying to asssign owners to subsystems? 18:53:53 yeah the chan/sched/conns is something I do understand quite a bit now 18:54:04 isis: yeah, but there's a little imposter syndrome talking there: 18:54:08 so I'm happy to get all tickets related to that and then I'll do triage if needed 18:54:21 isis: _nobody_ should be 100% confident in their knowledge of any of this wacky codebase 18:54:22 i think we should aim for n > 1 for number of owners of each subsystem 18:54:33 isis: I sure am not! 18:54:38 catalyst: +1 18:54:39 (which would facilitate quite a bit the triage and "oh shit 033 has 300 tickets" imo) 18:54:50 that's a lot of tickets! i did some homework for the roadmapping exercise, and I found that networking tickets was most of the stuff in the review-groups. 18:55:00 as for assigning people to areas : I think we failed in the past because we didn't follow through 18:55:29 catalyst: problem is that we dont even have n == 1 for many of them 18:55:51 catalyst: the doc we had before aimed to have at least two people per area and it asked us to rank our perceived familiarity with the part of the code 18:55:57 maybe if we just automatically assign tickets for review to the people who know the area, that could help build their knowledge. 18:56:05 isis: that seems not too bad an idea 18:56:16 but yeah, there were iirc a lot of areas that had two people who were both like 18:56:19 ¯\_(ツ)_/¯ 18:56:58 everyone should be very free to randomly assign me as reviewer for things as well, i think it's very interesting to review things in unknown parts of the code that is unknown to me (as long as it's C/build system things) :o 18:57:08 i don't feel comfortable enough in rust yet 18:57:27 (2 min left) 18:57:29 i have that doc 18:57:48 isabela: cool! Send it to the network-team list and maybe we can take another pass at it? 18:58:04 we should think of a better approach to fill it in 18:58:21 yeah 18:58:24 because last one was "eh how good you are with each subsystem" with no specific goal 18:58:31 but we should do it with the goal to fill in the blanks 18:58:35 ok, time for the TB people to have a meeting 18:58:37 yeah 18:58:40 feel free to assign stuff to me, esp rust/crypto/circ stuff 18:58:40 https://storm.torproject.org/shared/snpgGmzZ1hVGYcD9J9MK50T0PLr6Es1iLx9ydUJcrpo 18:58:44 thanks,everybody! Let's work towards answers here 18:58:45 nickm: will send 18:58:46 yay :) 18:58:50 #endmeeting