22:59:29 <ahf> #startmeeting network team meeting, 2 october 2019
22:59:29 <MeetBot> Meeting started Wed Oct  2 22:59:29 2019 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:59:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:59:33 <ahf> hello o/
22:59:43 <ahf> we have a pad at https://pad.riseup.net/p/tor-netteam-2019.1-keep
23:00:02 <catalyst> o/
23:00:09 <ahf> o/
23:00:16 <ahf> who is here today?
23:00:25 <nickm> hi there!
23:00:30 <mikeperry> howdy
23:01:05 <ahf> dont think we have dgoulet and asn
23:01:16 <nickm> I also saw gaba just a moment ago
23:01:18 <ahf> teor, gaba: you around?
23:01:21 <ahf> cool!
23:01:52 <ahf> should we start by looking at the roadmap?
23:02:21 <ahf> https://dip.torproject.org/torproject/core/tor/boards
23:02:26 <gaba> yes
23:02:35 <ahf> are things looking OK here?
23:02:57 <gaba> We have quite a bit of tickets that were in the roadmap for september
23:03:05 <nickm> (yeah. not too much progress since people are mostly focusing on 042 stability.)
23:03:16 <ahf> yeah, i have the feeling everyone is in 042 land right now
23:03:35 <nickm> We should make a note that the next time we have a planned freeze, there will be 2 weeks of diminished time for other coding-related roadmap stuff
23:03:52 <gaba> yes, we need to consider this next time
23:04:07 <ahf> yeah, adding some space around freeze time sounds like a good idea
23:04:29 <ahf> ok, nobody have anything roadmappy we need to discuss?
23:04:59 <ahf> lets go to the 042 status:
23:05:03 <ahf> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases/042Status
23:05:47 <ahf> we have two tickets with no owners, right now?
23:06:38 <ahf> #31841 is a 042-must that is new
23:06:58 <ahf> what does people think we do here? should gaba and distribute the new tickets that are coming in?
23:07:20 <ahf> gaba and i*
23:07:21 * gaba checking
23:07:28 <nickm> I could try to do #31841
23:07:37 <nickm> I think I have a handle on how
23:07:58 <ahf> wanna grab it? and you dont have too much on the plate already?
23:08:07 <nickm> hahahahaha. I'll be ok :)
23:08:12 <gaba> #31524 needs more information. maybe it should be removed from 042?
23:08:28 <ahf> nickm: :-D
23:08:44 <nickm> gaba: It's currently "security-low", so I don't want to pull it out
23:08:49 <nickm> but I don't think we have much to go on there
23:09:59 <teor> I am here, sorry, just having some irc trouble
23:10:10 <ahf> okay, let's leave the last ones without an owner for now. people seems to still have long lists of tickets pending
23:10:12 <nickm> Wrt #31524,  I think leaving it as needs_info is okay.  We'll figure it out or we won't.  It is _should_, so if we don't get any more info here, we can't do much.
23:10:24 <ahf> cool
23:10:50 <nickm> oh, also there is #31653, assigned, but with owner none.
23:11:09 <nickm> I think we can defer that to 043 since it requires that you enable a nonstandard padding machine?
23:11:17 <nickm> if I understand correctly?
23:11:20 <nickm> mikeperry: (?)
23:11:23 <mikeperry> it's like a 2/1000 chance of circuit failure otherwise
23:11:34 <mikeperry> for our normal padding machines, only for hs rend circuits
23:11:39 <nickm> oh.
23:11:41 <nickm> that's not so good.
23:11:52 <nickm> remind me, is padding on by default?
23:12:07 <mikeperry> only if the middle relay happens to be 0.4.1.x+
23:12:14 <nickm> so, sometimes.
23:12:43 <nickm> mikeperry: if we assign this one back to you, do you think you can get it done between 22 oct and not-too-long-after?
23:12:45 <mikeperry> so out of all hs rend client circuits that have a second hop of 0.4.1.x+, 2/1000 will have a circuit failure during setup
23:13:15 <nickm> I really do not want to ship with a reliability regression, even if it's only 0.2%.
23:13:20 <mikeperry> yes, I can. I also spotted a related perf issue with the proposed fix
23:13:29 <mikeperry> so I think I might ratyher take more time with this one
23:13:48 <nickm> maybe do the easy thing in 042, and the hard thing in 043?
23:13:59 <nickm> Or maybe you can get help with fixing up the tests?
23:14:05 <nickm> (assuming that's the hard part)
23:14:11 <mikeperry> the even easier thing is to make it not choose 0ms
23:14:26 <mikeperry> then the tests won't cause an issue (I think)
23:14:37 <mikeperry> I can try that fix later next week, maybe
23:14:47 <teor> FYI: about 1/3 of our relays are on 0.4.1 or later right now. After 0.4.2 is released, we might peak as high as 50% 0.4.1 or later. https://metrics.torproject.org/versions.html
23:14:58 <ahf> so it would be OK to reassign it back to you, mikeperry?
23:15:03 <nickm> i just did :)
23:15:06 <ahf> great
23:15:19 <ahf> is everybody OK with the tickets they have received from gaba and i during last week? we distributed them amount, but it might be some people want to swap tickets with others
23:15:30 <ahf> distributed them out*
23:15:33 <ahf> (it is late here)
23:15:33 <nickm> I'm fine with mine
23:15:49 <catalyst> if someone has a Windows test environment handy, they might do a better job with #31036?
23:16:07 <catalyst> also there's a nonfatal assert log spam issue there that might not have an associated ticket?
23:16:10 * ahf looks
23:16:15 <teor> I don't think we can do anything about #31707 in 0.4.2, so I'm going to take it out of 042-should?
23:16:25 <teor> I think it needs a refactor or a redesign
23:16:48 <ahf> i can take that one, catalyst!
23:16:54 <catalyst> ahf: thanks!
23:17:09 <nickm> teor: that ticket refers to "this patch", but there does not seem to be a patch?
23:17:31 <teor> It's a copy of text from another ticket, I'll edit the text so it makes sense
23:17:39 <nickm> As it stands, I don't think I grok what to do with #31707, so it's probably okay to defer
23:19:05 <teor> Probably some of the children of #21969 would help. Or maybe we've mitigated that bug enough? We don't have many new, open tickets about it.
23:19:26 <nickm> this is feeling feature-like to me at this point
23:19:43 <teor> +1, let's defer
23:19:50 <ahf> cool
23:20:04 <ahf> the next question is: * Will everybody be done soon, especially with "must" tickets?
23:20:17 * ahf hopes to be done with his two 042-must tickets by tomorrow afternoon dk time
23:20:38 <ahf> and the -should ones will come next week hopefully :-)
23:21:05 <nickm> It would be very good if the -should ones get done in 042, but it is okay if the ones about documentation  happen a bit later in the cycle.
23:21:20 <nickm> Once all the musts are fixed, I will be happy opening 043 ahead of schedule.
23:21:53 <teor> Yeah we are still discussing changes to the merge policy, so I am happy for #29546 to wait
23:22:06 <nickm> okay, defer that to 043?
23:22:14 <ahf> cool
23:22:15 <catalyst> ahf: do you want to open a new ticket for the log-spamming assert in #31036 or should i?
23:22:28 <ahf> catalyst: please do - i didnt see that part
23:22:35 <teor> Who can review #29427
23:23:22 <nickm> #29427 is pretty simple code-wise, the tricky part is understanding why the delay should be "2" instead of "10" on clients
23:23:43 <nickm> somebody with KIST experience would be best
23:24:30 <ahf> who have kist experience that is not david? :o
23:24:36 <nickm> It can be on me. :)
23:24:49 <nickm> I've already read the patch and started discussing it
23:24:54 <ahf> ok
23:25:42 <ahf> do we have more things to talk about regarding 042?
23:25:44 <nickm> setting myself as reviewer
23:25:51 <ahf> thanks, nickm!
23:26:50 <ahf> ok next item is:
23:26:57 <ahf> * "Pull request requirements before review":
23:26:58 <ahf> * Alex is going to create a proposal based on the retrospective
23:27:16 <ahf> status there is that i started doing that today, but didnt finish, so that will be on the mailing list tomorrow
23:27:31 <ahf> it is based on the discussion we had last night at the retrospective
23:27:56 <ahf> the next section is around active proposals discussions
23:28:02 <ahf> oh
23:28:15 <ahf> we are getting a new item on the agenda, 2 sec
23:28:18 * nickm just added one, sorry
23:28:25 <ahf> * Nick has a quick question about C style poll, for Catalyst and Teor.
23:28:28 <ahf> go!
23:28:33 <nickm> i have a quick question for catalyst and teor. I sent a link to a draft of the poll
23:28:38 <nickm> (about C style)
23:28:59 <nickm> my next step is to send to the list and ask for comments and suggested changes before we run the poll
23:29:16 <nickm> do you want to comment before I send it to the list for comments, or should I just skip a step? :)
23:29:17 <catalyst> ahf: #31939; set to Tor:unspecified at the moment
23:29:25 <ahf> thx catalyst!
23:30:06 <teor> nickm: I'd like to read it, and then I'll probably just say "ok" if there are no blockers
23:30:09 <nickm> ok
23:30:20 <nickm> I'll wait then.  How about you, catalyst?
23:30:50 <catalyst> i've read it briefly, didn't see any major problems. kind of want to read it again first
23:30:56 <nickm> ok.
23:31:06 <nickm> I'll wait for a sign-off from each of you
23:31:09 <nickm> thanks !
23:31:16 <ahf> cool
23:31:17 <ahf> next item is:
23:31:26 <ahf> * Opting-in to faster reviews and merges
23:31:26 <ahf> * We discuss this new proposal from teor
23:31:27 <ahf> * Target discussion end date: 15 October
23:31:39 * catalyst is lost in a sea of browser tabs
23:31:48 <nickm> wrt that proposal...
23:31:59 <ahf> catalyst: XD
23:32:05 <ahf> my chrome also have a ton of tabs right now
23:32:26 <nickm> I think dgoulet thought that having it relate to regular review assignments was unrealistic.
23:33:44 <nickm> teor: a question for you.  Did you envision that this proposal would eventually be the primary way of us getting faster reviews, or do you think we should look for some way to get all reviews assigned and done faster?
23:33:52 <teor> After reading dgoulet's comments, I think the proposal is a bit heavy.
23:34:17 <teor> nickm: I think we have two options:
23:34:42 <teor> 1) Work out how to get reviews and merges done faster, for everyone, all the time.
23:35:29 <teor> 2) Sometimes, some people do reviews faster, usually because they're working on the same sponsored work
23:35:54 <teor> We're already doing 2)
23:36:45 <teor> I would really like 1), because it's universal - it happens for everyone. But if some people like the weekly cycle, I don't know if we can make it happen.
23:37:41 <teor> To be clear, I don't think we should force things to be faster than they need to be. But I think we can cut down on unnecessary delays.
23:37:54 <teor> (done)
23:37:59 <nickm> I think we have some problems to overcome to get to 1), but it would be good if we can do so.
23:38:00 * catalyst hunts for proposal text
23:38:29 <nickm> I don't think dgoulet and asn would be happy doing assignment every day.  I hear that in some organizations, assignments happen automatically.
23:39:02 <ahf> i think in those orgs they happen based on authorship of the code that is being modified in the patch, no?
23:39:04 <teor> Yeah, I think that manual assignment is unnecessary. An auto-assignment would be much better.
23:39:05 <catalyst> if we remove the three-person requirement, we can remove some of the complexity of the proposal
23:39:09 <ahf> like with githubs suggested reviewers?
23:39:17 <nickm> I would be happy getting new assignments every day, with the expectation that I get to them during the next working day at the latest.
23:39:31 <teor> Yes, I think that's reasonable.
23:40:12 <nickm> we don't need to make everybody follow that process though.  If somebody gets really overwhelmed by same day reviews, they can get reviews of stuff that is marked as not needing to be same day, or something.
23:40:40 <catalyst> how about author can assign a reviewer?
23:40:53 <teor> +1 I was just writing that
23:41:10 <ahf> yeah. what if we get rid of the assignment from david and george and you the author are responsible for finding an available reviewer?
23:41:15 <teor> Then the role of the review assigners is to deal with exceptions: no reviewer, old reviews, rebalancing review load.
23:41:32 <ahf> oh, like a hybrid
23:41:47 <nickm> hm. I think we could do one step better if we can find some way to make the balancing happen early
23:41:54 <teor> Well, we will still have volunteer tickets with no reviewer.
23:42:01 <ahf> true
23:42:29 <nickm> (ISTR that I used to be the default reviewer for everybody, and it was not a good situation for anyone.)
23:43:19 <gaba> asn and dgoulet can still assign reviewers for PRs that are not from the team
23:43:25 <gaba> ^ what teor said
23:43:46 <ahf> yeah, and then if you want something reviewed during the week you reach out to someone else from the team?
23:43:54 <nickm> let's mull this over and see what asn and dgoulet think about it. How does that sound?
23:44:01 <ahf> yes
23:44:22 <gaba> sounds good
23:44:23 <teor> I think we should have teams working on sponsored work decide their own reviewers. If you're doing large non-sponsored work you find your own reviewer. And then d & g do the leftovers.
23:44:49 <ahf> lets hear what they think too, yeah
23:45:01 <ahf> ok, we have 15 min. left. next item is:
23:45:06 <ahf> * Commit Bits For CI And Review Roles
23:45:06 <ahf> * We discuss this new proposal from teor
23:45:07 <ahf> * Target discussion end date: 22 October
23:45:26 <nickm> so far this one seems uncontroversial
23:45:39 <ahf> yes, that was also my initial thought
23:46:04 <teor> Should I revise the proposal based on asn's comments?
23:47:01 <nickm> I'm +0 on that
23:47:16 <nickm> nobody seems to oppose the change
23:47:39 <ahf> yeah, unless anybody disagrees with it, it seems reasonable?
23:47:48 <teor> Ok, I think at least the clarifications asn suggested would be useful.
23:48:00 <ahf> yep
23:48:23 <teor> I'll re-issue a lightly edited version, and then ask everyone else to vote.
23:48:31 <ahf> cool! thanks teor
23:48:36 <ahf> next item is:
23:48:37 <ahf> * "Draft merge policy for discussion and vote"
23:48:37 <ahf> * New proposal from nickm based on retrospective.
23:48:38 <ahf> * Target discussion end date: 16 October
23:48:52 <ahf> this one also seemed uncontroversial
23:49:14 <nickm> so far :)
23:50:03 <ahf> nobody have anything to add here ? :-)
23:50:44 <ahf> i take that as a no, i guess we'll continue on the ML with that if anything shows up.
23:50:54 <ahf> okay, i have one last item and i also see no "need help with" items on the pad
23:51:17 <ahf> so, i was wondering now that we are making use of our new shiny meta policy how do we want to announce these decisions in the rest of the organisation
23:51:34 <ahf> they mostly affect us in the team, but i think it is important that other people are aware of how we work so they have an idea about what is going on with us
23:52:03 <ahf> my initial thought was that i could every now and then send out summaries about what we have decided one once a policy goes into effect
23:52:12 <ahf> but if other people have better ideas i am also very open to that
23:52:19 <catalyst> is updating our wiki pages good enough? (maybe plus a brief announcement summarizing the changes?)
23:52:32 <ahf> i think the wiki page is great and the summary would contain a link to that, yeah
23:53:24 <gaba> I think monthly reports from the team to the rest of the organization is good. And this can be announced there.
23:53:29 <teor> +1
23:53:30 <ahf> yes
23:53:37 <ahf> good idea to combine them, gaba
23:53:46 <ahf> cool, i will try to do that then
23:53:51 <gaba> Similar to what other teams are doing, something simple about the work that has been done last month.
23:54:04 <gaba> ahf: you can start a pad and everybody help in the next meeting
23:54:13 <ahf> yep, i want us to have those as well, was planning on beginning on a pad tomorrow and then people can look at it on monday
23:54:18 <ahf> yep
23:54:21 <gaba> sounds good
23:54:23 <ahf> like the anti-censorship team does
23:54:26 <gaba> yes
23:54:29 <ahf> cool! lets do that
23:54:36 <ahf> does anybody have anything else we need to discuss?
23:55:22 <gaba> not from me
23:55:25 <ahf> cool, i take that as a no!
23:55:36 <nickm> ok. have a great day or evening as applicable!
23:55:39 <ahf> i wotn be sending out a summary until i have had some sleep. i am so tired tonight for some reason
23:55:42 <teor> thanks!
23:55:44 <ahf> thanks all for the meeting o/
23:55:45 <ahf> see you around
23:55:47 <ahf> #endmeeting