16:59:53 <ahf> #startmeeting network team meeting, 21st of june 2021
16:59:53 <MeetBot> Meeting started Mon Jun 21 16:59:53 2021 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:53 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:58 <ahf> hello hello
17:00:04 <GeKo> o/
17:00:08 <ahf> our pad is at https://pad.riseup.net/p/tor-netteam-2021.1-keep
17:00:15 <juga> o/
17:00:51 <ahf> o/
17:00:54 <dgoulet> hello
17:00:58 <ahf> hello hello
17:00:58 <jnewsome> o/
17:01:01 <ahf> o/
17:01:19 <nickm> hihi
17:01:44 <ahf> are the boards you guys are having look right?
17:01:56 <nickm> fine by me
17:02:18 <dgoulet> all good
17:02:49 <ahf> dgoulet: we agree that after tor!400 was merged, we don't have to backport it further so tor#40410 can be closed, right?
17:03:06 <nickm> ahf: where did it get merged to?
17:03:20 <ahf> 0.4.6 and forward
17:03:28 <nickm> right, the bug is new in 046
17:03:34 <dgoulet> correct
17:03:37 <ahf> yeah, so there isn't anything older we care for
17:03:42 <ahf> excellent. i'll close it
17:04:11 <ahf> huh, or, strange, my browser had it as open, but looking now it's closed
17:04:11 <ahf> weird
17:04:14 <ahf> never mind then
17:04:34 <ahf> Let's check out 0.4.5-post-stable and 0.4.6-stable release status and open tickets!
17:04:35 <ahf> See: https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.5.x-post-stable and https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.6.x-stable
17:05:29 <nickm> maybe we should have an 046-post-stable milestone now?
17:05:33 <nickm> since 046-stable is done
17:05:39 <dgoulet> +1
17:05:40 <ahf> don't see anything new there, but maybe we should drop the 0.4.6.x-stable now and have a po-stable one?
17:05:41 <ahf> yeah
17:05:53 <ahf> let's do that
17:06:31 <ahf> pad is updated and 0.4.6.x-post-stable is empty right now of course
17:07:47 <gaba> hi!
17:08:07 <ahf> hello
17:08:34 <ahf> there is nothing new for us from anti-censorship team or network health team
17:09:30 <ahf> ok
17:09:39 <ahf> i have one announcement, and it's just something people can take a look at but:
17:09:45 <ahf> [21 june] [ahf] David had a good comment on what went wrong in #40410 which caused some build failures in recent releases. I think it's worth a read: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/398#note_2740025
17:10:17 <ahf> it has a bit to do with how we work with gitlab and i thought it was worth a read if people hadn't read it already
17:10:44 <nickm> Do we have a process for what I should have done here next time?
17:10:48 <ahf> i think that was all we had for today. i don't know if mikeperry is back yet and up for doing the s61 part of this
17:10:52 <ahf> nickm: nothing, it was my mistake
17:11:04 <ahf> nickm: i missed your comment on changes request and thought it was just pending getting merged
17:11:08 <nickm> ahf: yeah, but if it was easy to miss, maybe we should flag the MR somehow
17:11:12 <dgoulet> yeah
17:11:27 <dgoulet> I think that once we believe something should get backported, we should just flag it right away
17:11:30 <dgoulet> and not ask if we should do so
17:11:40 <dgoulet> and then at the backport triage, we can assess if not done before
17:11:44 <dgoulet> so nothing slips
17:11:54 <nickm> So, the issue is that this was not mergeable as-is
17:11:56 <kushal> ahf, btw, I used that commit from #398 into CentOS 7 rpm.
17:12:01 <dgoulet> I mean it is not one person mistake here, I think that ticket fell into all the possible cracks eheh
17:12:05 <ahf> kushal: cool
17:12:05 <nickm> It needed a changes file and to be based somewhere different
17:12:12 <nickm> so the next step was not "merge" but "make new branch"
17:12:16 <dgoulet> nickm: right so it was mergeable but not for backport
17:12:21 <dgoulet> right
17:12:22 <nickm> That's not mergeable
17:12:25 <ahf> yeah, it needed a new branch + a changes file because it was no longer targetting main
17:12:33 <dgoulet> nickm: but it was not flagged backport so in that sense, it was
17:12:50 <dgoulet> MR was also missing the Assignee
17:13:04 <ahf> yeah, but i am not even sure assignee would hvae helped here
17:13:04 <nickm> ahf: would you have seen it if you were assignee?
17:13:10 <ahf> i was the submitter already so i did get the email
17:13:20 <ahf> so even if i had been assigned, i would have missed that comment
17:13:24 <dgoulet> ahf: but it would have appear in your Todo or list of Assigned ticket
17:13:34 <ahf> ah, that is true, and it would be without labels
17:13:36 <dgoulet> MR*
17:13:54 <dgoulet> so more chances to spot it before we release stable as we usually all look at our MRs/Tickets at least
17:13:57 <ahf> yeah
17:14:18 <dgoulet> I find it weird that MR don't get auto assigned to the person who create the MR but... yeah that is that
17:14:55 <ahf> i think that makes sense when it's a team member submitting, but for volunteers it makes sense
17:15:15 <ahf> err, for volunteers it makes sense that we can add one of us as assignee for their MR
17:15:24 <kushal> dgoulet, shouldn't it be assigned to the person reviewing?
17:15:31 <dgoulet> kushal: we have a field for that
17:15:37 <kushal> ah, thank you :)
17:15:48 <kushal> dgoulet, I can see it now :)
17:15:50 <dgoulet> ahf: problem is that MR's without an Assignee seems very easy to miss
17:15:58 <dgoulet> ahf: especially if they've been missed label
17:16:00 <ahf> yep
17:16:18 <dgoulet> I keep assigning my MRs to myself all the time :P
17:16:57 <ahf> if you create a ticket to ahf/triage-ops with that you want unassigned MR's from yourself to be assigned to yourself, i can make the bot do that
17:18:29 <jnewsome> heh, we're actually about to turn on autoassignment of the author in Shadow. 99% of the PRs are from team members though https://github.com/shadow/shadow/pull/1463
17:18:35 <mikeperry> o/
17:18:36 <ahf> ok, anything else we need to talk about today? i don't think mike is around, so i think we wont sync on s61 stuff. i know mike have been hacking on some CC support in tor which looks very exciting
17:18:42 <ahf> oh boom there he is
17:18:43 <mikeperry> just got back
17:18:54 <ahf> jnewsome: ah, interesting :-)
17:19:01 <ahf> mikeperry: you wanna go for s61 part?
17:19:19 <mikeperry> did not have a chance to go over the pad for all s61 stuff, but yeah I showed dgoulet the current congestion control branch
17:19:42 <mikeperry> the commits and code are well structured, but it still needs a bit more work
17:19:58 <mikeperry> https://gitlab.torproject.org/mikeperry/tor/-/commits/congestion_control_v2
17:20:13 <mikeperry> oh yeah I want to correct a thing I said about perf we can expect
17:20:17 <mikeperry> last week
17:20:25 <ahf> and excellent directors cut commentary
17:20:50 <mikeperry> basically, we should expect equilibrium around much higher network utilization, once all clients upgrade
17:21:11 <mikeperry> so since we're at like 40-45% utilization, max avg throughput won't go up more than 2X with the current network
17:21:36 <mikeperry> but, even in that case, if we tune it well, it should have less queueing and congestion at that rate
17:22:08 <ahf> nice
17:22:19 <mikeperry> that's all I got rn for drop-in commentary. happy to talk with dgoulet and/or jnewsome a bit more later
17:22:32 <mikeperry> geko,juga: anything you want to talk about?
17:22:51 <dgoulet> mikeperry: yup def
17:22:58 <jnewsome> mikeperry: sure
17:23:17 <juga> mikeperry: not from my side, GeKo ?
17:23:34 <GeKo> i think juga fixed the issue we hit on bastet
17:24:02 <GeKo> https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40091
17:24:09 <GeKo> so, we are testing that now
17:24:19 <ahf> nice juga!
17:24:27 <GeKo> and barring any unforseen issues we'll try to switch bastet back to sbws this week
17:24:32 <juga> ah, also testing #40092
17:24:49 <juga> tpo/network-health/sbws#40092
17:24:52 <GeKo> so, we are getting on track back to replacing torflow
17:25:15 <GeKo> yes, and we are continuing investigating maatuska's bwauth weirdnesses...
17:25:26 <GeKo> nothing else to highlight i think
17:25:32 <GeKo> (at least not from my side)
17:25:45 <juga> (same)
17:26:46 <ahf> shall we stop the meeting then and go back to our regular async irc life?
17:26:56 <GeKo> wfm :)
17:27:00 <mikeperry> sounds good :)
17:27:11 <jnewsome> 👍️
17:27:17 <ahf> excellent, thanks all!
17:27:19 <ahf> #endmeeting