17:58:31 #startmeeting weekly network team meeting, 19 Nov 17:58:31 Meeting started Mon Nov 19 17:58:31 2018 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:34 hi everybody! 17:58:36 hi 17:58:37 hey 17:58:45 meeting pad at https://pad.riseup.net/p/tor-netteam-2018.1-keep 17:59:02 this will be a short week for a bunch of us 17:59:18 it's thursday and friday that are holidays in the US? 17:59:23 (and canada too?) 17:59:31 thursday is an actual holiday, everybody takes friday off too 17:59:33 * catalyst is only taking the company holiday days off 17:59:42 * juga around 17:59:49 dunno if friday is a company holiday or not; does anybody? 18:00:01 I'll be off Wednesday as well 18:00:02 it's on the calendar as a company holiday 18:00:10 catalyst: ty 18:00:19 Canada does thanksgiving earlier in the month IIUC 18:00:23 ok 18:00:44 yes was earlier 18:01:34 the tl;dr is that I will be ignoring IRC and most mailing lists from wed through sun, so please send personal email if you want me to see something. I won't mind spending 30 minutes of my time here and there 18:01:45 onwards! 18:01:53 how are we with the roadmap? 18:02:17 Once i have the dormant branch merged, I hope I can check off #28335. 18:02:35 how are we with the other top priorities? 18:02:53 the big #28179 is now in my hands for review (s8) 18:02:56 (from ahf) 18:03:01 cool 18:03:07 ahf: what does it do right now? 18:03:17 david is looking at #28179, still missing some windows bit and a test, but i think i need your eyes on the windows code i'm doing, nickm 18:03:25 is there progress reporting, or is this only a framework where we can do progress reporting later? 18:03:50 this is the big bits for attaching the processes to the event loop 18:04:19 and then once this is good we'll remove a lot of the old utils code for process handling and at the same time attach it with transports.c, which should be pretty easy when this part works 18:05:05 at what point does tor actually reporting PT progress? :) 18:05:13 and i think it splits out the unix backend and windows backend in a bit more clean way than the current process code is where everything is in a big function with two implementations 18:05:34 oh, so this are the bits for us to do the signaling part afterwards, let me find the ticket 18:06:11 hi! 18:06:24 right now it doesn't do anything, but we want this to do: #28180 18:06:57 we have the spec and know where to go with this ^ once we have #28179 merged 18:06:59 right now the code that #28179 is replacing has been very flaky historically 18:08:19 how is everybody else doing with the roadmapped stuff? 18:09:17 hhow is #27100 going? 18:09:49 not much progress on that one, started to look a bit at that code, but not sure what a good solution is there 18:10:01 and where to report it to? :o 18:10:36 ahf: i can be available to chat about that if it would help 18:10:54 catalyst: i would like to that this week, yes 18:11:03 maybe tomorrow when you get in? 18:11:16 ok 18:11:19 catalyst: how is your stuff with bootstrap ? 18:11:55 been spending most of my time trying to understand the big pubsub patches for review 18:13:29 should we still be aiming to get pubsub into 040? I mean, I want it, but if the review is this hard, then probably it isn't a very clean system 18:13:42 there's an outline in #28281 of how some of the higher level abstractions will work 18:14:11 what do you both think about having a meeting specifically to go through the pubsub system? 18:14:16 will that help with the rview? 18:14:24 something that goes through the system and code and can discuss it 18:15:43 I'd try that it it would wrap this up? Or we could just put off pubsub and start the bootstrap coding immediately without it, and nothing else first 18:15:52 *if it would wrap this up 18:16:10 yes, both options sounds good. something that can move things forward 18:16:12 the pubsup feature is made for better bootstrap coding? 18:16:19 nickm: pubsub has to go in 040+ 18:16:19 s/coding/code/ 18:16:25 035 is feature freeze :) 18:16:44 i think the question is whether it's 040 or 041? 18:16:51 right 18:17:07 ahf: it's made for better code throughout the codebase in general. It would make bootstrap cleaner... 18:17:07 when is 040 freeze? medio december? 18:17:17 Dec 15th 18:17:21 right 18:17:23 ...but if it makes us delay bootstrap code much longe,r bootstrap code will have to be done in a rush 18:17:30 errr Jan 15th 18:17:35 and that will make booststrap code less clean. 18:17:47 dgoulet: Right; Dec 15 was our 0.3.5 stable target 18:17:48 yeah... lets just put pubsub aside, no biggy tbh 18:17:59 and finish bootstrap 18:18:14 catalyst: what do you think about this plan? 18:18:28 means move into bootstrap and put pubside aside 18:18:32 i have some designs that can use a much more minimal set of abstractions. they might not be as clean as using a fully featured pubsub framework, but can use some of the underlying concepts 18:19:04 are they "keyboard-ready", as it were? Does anything block starting to make code for them today? 18:19:28 nickm: nothing blocking them that anyone else is working on 18:19:45 anything you need to work on first? 18:20:16 gaba: yes, i can set aside reviewing this pubsub work and focus on a more minimal approach to the bootstrap work 18:20:40 we need a plan to have good code that can go into 040 for us to finish this for the sponsor 8 18:21:09 nickm: mostly not? there are a few nice-to-haves like cleaner abstractions in the async event sending code in control.c, but i can work around that 18:21:14 For this, and for PT status reporting 18:21:33 catalyst: right. The time to do the clean approach for this is probably past. We need it by end-of-year 18:21:49 catalyst: and if you think that is not moving forward and you need a 1:1 with nickm or anybody on the team to push this through please do not hesitate on bringing it up. 18:21:51 If we delay past end of year, we are in bad shape 18:22:10 gaba: IIUC this goes for PT status reporting too, right? 18:22:18 yes 18:23:21 getting quick feedback on #28179 from anybody who is going to look at this would be of great help with PT status reporting 18:23:53 add it to my needs-review queue? 18:24:00 dgoulet is already on it i think 18:24:01 oh, nm, dgoulet has it 18:24:03 great 18:24:13 yeah it is quite on my high prio. stack ;) 18:24:47 are we set on roadmap stuff for this week? 18:24:53 it seems so 18:24:54 next is reviewer assignments 18:25:48 it looks like we're putting #28226 on the back burner for a bit 18:26:20 catalyst: will #28247 and #27130 eat more than a couple of hours,do you think? I don't want to take you off one timeconsuming review but then put you on others that will prevent coding on bootstrap. 18:26:47 code reviews in general is something I'm happy to do from my parents' place :) 18:27:11 #27130 needs a bit of careful handling because the contributor seems to disagree with me on some important stuff 18:27:35 #28247 should be fairly quick 18:27:38 oh, it's that guy 18:28:13 I think it's ok to let #27130 to sit for a while then, if the answer isn't fast to write :/ 18:28:26 thanks 18:29:07 any other questions/issues on reviews? 18:29:28 dgoulet: if you need to slack on #28362 that's also fine :) 18:29:50 i might need to stop writing all this infrastructure stuff if it eats people's lives so much 18:30:16 it might slip until I get the PT stuff done but I think it will be fine 18:30:21 asn, mikeperry: Is #28142 going well? Would another look from me be helpful? 18:30:51 nickm: I am trying to decide on things to do for merge vs after and also wondering if anything is blocking asn 18:31:07 nickm: there's a lot of small things to do, and this is a short week, and I'm taking off mon+tues 18:31:22 mikeperry: stability & quality stuff pre-merge, features post-merge? :) 18:31:33 nickm: so I thought I might either try to prioritize something v important for asn, or just work on the datagram paper 18:32:06 nickm: yeah there are some things that are on the line... like backing off if negotiation fails a bunch of times, and that menu idea you had (which may minimize negotiation failures) 18:32:10 wrt the datagram paper: I think we need to send it to our mozillan friends by next Monday for it to get meaningful thought before the all hands. Do you think that's reasonable? 18:33:14 nickm: yeah, in that case I will just focus on that this week, unless asn needs something from me to continue working on wtf-pad tests/stuff 18:33:23 ok 18:34:18 pfew. long start-of-meeting 18:34:46 rotations this week are mikeperry bug triage, teor CI 18:35:21 any discussion stuff for this week? 18:35:30 reviewer role draft? 18:35:42 did everybody was able to see the stuff on reviewer role responsabilites? 18:35:45 i also have a question/topic, but we can start with the reviewer draft 18:35:45 yes, taht one :) 18:36:31 I think it's a good start 18:36:37 first bullet under responsibilities (3) is a bit confusing 18:37:04 what does "change of state" mean there? any change in Trac state? or a "final" disposition of the ticket? 18:38:04 if something better replaces it? or something the ticket depends on changes by some other ticket? 18:38:11 IMO I think just taking care of it until it is either merge_ready or needs_revision is enough. 18:38:42 someone needs to track when a needs_revision ticket has revisions submitted though. who should do that according to this document? 18:38:56 I don't think that makes sense for the reviewer to do 18:39:06 at least, I haven't been expecting reviewers to do it 18:39:11 so the review assigners? or a different rotation role? 18:39:31 I think it's part of paying attention to trac, so maybe it would be triage? That could be extra work though 18:39:37 well on the contrary, the reviewer should track that there is a revision 18:39:58 it is _easy_ to miss if the ticket state isn't changed though :S 18:39:58 ok so we have some genuine disagreement here? 18:40:23 dgoulet: doesn't that just happen automatically because you and asn looks at all tickets in needs_review even if they are already assigned? 18:40:23 dgoulet: If I put something into needs_revision a year ago, I probably won't remember it was me when somebody revises it 18:40:28 i'm ok with making it the assigned reviewer's responsibility; i'd like it to be made clear if it is 18:40:52 nickm: that is why Reviewer field is used 18:41:01 trac tells you which ticket you track... ? 18:41:11 (also to account for this ticket revision tracking in people's time) 18:41:43 that is one of the main point of this reviewer role, is once the reviewer is assigned to the ticket as the Reviewer, whatever states it ends up in, the reviewer is responsible for it 18:41:47 dgoulet: basically you expect people to regularly check the list of tickets they're listed as reviewers for and update states if needed? 18:41:57 (not forcing to do patches ofc) 18:42:17 catalyst: honestly, I thought that was implicit for the last hmmm 5 years? lol 18:42:19 dgoulet: I think noticing revisions that happen within a week or two is reasonable, but once something has been needs_revision for a long time, we shouldn't depend on the reviewer to notice 18:42:39 wow, so it seems is really helpful to be explicit about this role :) 18:42:48 nickm: I kind of disagree on that because else someone *else* needs to notice it and who? ... 18:42:55 Well, historically, me. 18:43:04 also if we're shifting the responsibility in this way, we need some way to keep low people's load of tickets where they're assigned as reviewers 18:43:17 can we get notifications if something changed for a ticket that you are reviewer on? 18:43:20 I have periodically gone through everything in needs_revision for an active milestone once every month or two 18:43:58 nickm: well this is not ideal imo... the main point of this reviewer role is to spread ticket responsability accross all developers 18:44:00 not only you :S 18:44:07 And I still read all the "core tor / tor" trac email and when somebody says "here's a patch" but they don't put the ticket into needs_review again, I do that 18:44:35 To me, since this is part of the trac workflow, it sounds like ticket triage, but we could look for other solutions too 18:44:38 I do the same each morning... 18:44:40 tor-bugs@ 18:44:45 and filter on Core Tor/Tor 18:44:48 nickm: what would be the cons if reviewer start doing it for the tickets they get? 18:45:33 most people do, if they notice soon 18:45:42 like I said, I think it's a fine thing to do if you get a reply in a week or so 18:45:59 after that amount of time though, the ticket shouldn't need to be on your mind any more. 18:46:02 IMO 18:46:07 (also, we have just 13 min left) 18:46:43 in case is useful, i found teor tracks their tickets in a page https://trac.torproject.org/projects/tor/wiki/user/teor, i found it useful to do it with mines too 18:46:45 if it is in needs_revision to wait for a revision then it won,t be on anybody's mind until it gets a revision? 18:47:04 ok, let's continue discussion on the pad 18:47:06 not if you have to check once a week to see if it got a revision 18:47:11 and bring it up next meeting, ok? 18:47:14 we can't do much anyway with a ticket waiting for a revision even if 4 months old apart from doing the patch oursselves or closing it or keeping it that way :S 18:47:16 ack 18:47:23 gaba: sounds good 18:47:26 maybe we need to think about it a little more and think about alternatives 18:47:27 ok 18:47:43 I added a place for questions/discussions 18:47:53 Please add yours until next week 18:48:00 In htat case we are including teor and other people 18:48:09 other discussion topics? 18:48:26 Teor added something to the pad 18:48:36 on sbws 18:49:05 i'm fine with that 18:49:44 hmm, something we should discuss about it? 18:49:46 Hm. I don't think I have answers to those questions. I can read and try to answer the tor-dev email in question, but I don't know that I'd really know better than others at this point 18:50:03 yes, maybe they were just trying to bring that mail into attention 18:50:15 i have one: we have one month now until s8 ends, next week we have scheduled the kick off meeting for s19. how many people will be interested in that and will find it useful right now? i'm a bit uncertain about how many will join in, but i know of at least one other person from another team that wants to join in 18:50:43 the point about s8 is to figure out how stressed people are about s8 ending mixed with starting to think about s19. 18:51:01 gaba: what do you think there? 18:51:10 we will need at least one more person working on it. If you are not thinking you will be working on it please still attend 18:51:21 it will be mostly about the work that needs to be done too, right ahf ? 18:51:31 i will work on it i hope, but more about who else is right now at a point where they are gonna join in :-) 18:51:37 yep, gaba 18:51:42 kick off, nothing technical 18:51:51 well, mmostly planning technical things 18:51:59 yes, we may need somebody else to hold that work until we get the anti-censorship team in shape 18:52:20 so we are 2 on the network team? 18:52:21 cricri 18:52:38 well, i'm going to be there; we need to get the thinking started at least 18:52:41 yes, we can see on tuesday how much work needs to be done and plan from there more precisely 18:52:44 nickm: great 18:52:45 i'm interested in s19 but probably don't have much time until s8 ends 18:52:56 catalyst: yep, it's not about getting tasks for december i think 18:53:06 can you still be in the meeting on tuesday? it doesnt mean you are going to be working soon on that 18:53:09 more about looking over what we have on the roadmap, also talk a bit with UX, etc. 18:53:19 when is the meeting? 18:53:39 27th at late in the evening for me (same time we had a network team meeting some weeks ago) 18:53:42 tues 27th, patch party time, I think. Is that correct? 18:53:42 23 UTC i think 18:53:47 ok so patch party time? 18:53:53 let me double check 18:54:06 yes, 23 utc, the 27th, in #tor-meeting 18:54:22 ok i can be there 18:54:30 cool! 18:54:33 UX will be there too 18:54:44 then i think we should do the meeting still, just wanted to be sure! 18:54:45 also I have a quick non-discussion topic 18:54:47 thanks :-) 18:55:17 I sent an email to network-team with my attempt at diplomatically resurrecting discussion about a research thing. I'd like to sent it to the researchers this week, but I'd like feedback about whether I'm being diplomatic 18:55:23 so if anybody can advise there, great 18:55:36 and if not I'll just send it before I leave on wednesday morning :) 18:55:54 +1 18:55:57 any other topics for this week, or shall we turn over the channel to TB for their meeting? 18:56:05 * ahf is good 18:56:26 still not talked about proposed tickets but I assume people are looking at them 18:56:38 we can talk next week briefly 18:57:13 ok. If there's anything else, let's find each other on signal or on #tor-dev. See you over the course of the week, folks! 18:57:17 #endmeeting