16:59:08 <ahf> #startmeeting network team meeting december 7 2020
16:59:08 <MeetBot> Meeting started Mon Dec  7 16:59:08 2020 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:14 <acat> o/
16:59:19 <ahf> hello network team!
16:59:31 <ahf> our pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep
16:59:40 <asn> ehlo
16:59:42 <asn> writing report now
16:59:43 <ahf> today we have a lot of items on the agenda, but the s61 parts was taken care of in the s61 meeting
16:59:46 <ahf> very good
17:00:45 <mikeperry> o/
17:00:47 <ahf> o/
17:00:56 <ahf> just waiting for everybody to arrive
17:00:59 <gaba> \o
17:01:29 <ahf> how are folks doing with their ticket dashboards: https://gitlab.torproject.org/groups/tpo/core/-/boards ?
17:01:36 <asn> report done
17:01:59 <nickm> ahf: doing okay with mine but I don't 100% trust that it has all of my stuff on it. I've got a question for that later.
17:02:12 <ahf> gaba: thanks for adding the missing labels to the flashflow ticket! i was just about to mark that as doing
17:02:31 <ahf> nickm: is that one of the discussion points?
17:02:38 <nickm> yes
17:02:38 <dgoulet> o/
17:02:42 <ahf> oki, cool!
17:02:42 <nickm> hi dgoulet !
17:02:55 <ahf> welcome dgoulet o/
17:03:06 <asn> im meaning to make two s61 tickets that i havent caught up to it yet
17:03:16 <asn> they will likely be on the "doing" side of things, or on the "next"
17:03:24 <ahf> asn: excellent
17:03:51 <ahf> so for MR assignment: we have 12 tickets it seems that are unassigned in tpo/core/**
17:03:57 <asn> eek
17:03:59 <asn> ok noted
17:04:01 <asn> will do so today or tomorrow
17:04:06 <dgoulet> yeah need to get to that
17:04:07 <ahf> looks like both some spec stuff and some tor stuff
17:04:22 <nickm> we also have pages of MRs total not in backport (see link from pad)
17:04:51 <nickm> everybody please remember to make sure you're making progress on reviews as feasible :)
17:05:14 <ahf> ya, there is of course also assigned MR's that are unreviewed yet
17:05:21 <ahf> nickm: yep
17:05:52 <nickm> if you're stuck reviewing somethign I didn't write, you can assign it to me
17:06:01 <nickm> if you're stuck reviewing somethign I did write, you can ask me about it :)
17:06:59 <ahf> dgoulet and i taked a bit earlier about the whole review process and i think both of us are also OK with people adding assignment to reviews based on where our expertise is in the team
17:07:15 <ahf> so you are welcome to assign PT/bridge stuff to me, or windows stuff to me directly and so on
17:07:21 <ahf> and onion service stuff to asn/dgoulet
17:07:26 <ahf> etc.
17:07:26 <dgoulet> yup
17:07:36 <dgoulet> I've been doing that a bit recently just to speed things up
17:07:36 <asn> agreed
17:08:05 <ahf> ok, how are we doing with 0.4.5 ?
17:08:39 <ahf> i didn't see anything new coming in over the last week
17:09:02 <nickm> can we look at our 045-must tickets and/or the 045-stable tickets?
17:09:34 <nickm> https://gitlab.torproject.org/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Tor%3A%200.4.5.x-stable
17:10:21 <nickm> (looks like we removed must)
17:10:28 <nickm> I see a few unassigned ones there
17:10:38 <nickm> and a bunch of assigned ones in various states
17:10:59 <nickm> I'll take tor#40188
17:11:15 <ahf> 2 tickets that are not in backport but are unassigned
17:11:27 <ahf> tor#40208 is the other one
17:11:48 <dgoulet> yeah that one seems related to me
17:11:50 <ahf> looks a bit related to the s55 changes that went in?
17:11:54 <dgoulet> I have to get to all of those from s7r...
17:12:01 <dgoulet> I've been slacking on them :(
17:12:30 <nickm> dgoulet: can you assign them to yourself, and make sure they're in backlog, in the right milestone?  that would let me take them off my todo list :)
17:12:42 <nickm> i'm also happy to help out if you want a 2nd person to work with on them
17:12:56 <dgoulet> on it
17:13:06 <nickm> thanks!
17:13:42 * ahf uses the above URL in the pad instead of what is there now ...
17:14:52 <ahf> okay. we good to move to releases page?
17:15:03 <nickm> ok by me
17:15:27 <ahf> there is a question later for today on 0.4.6 is features there, but i think that is unrelated to what we look for here
17:15:29 <nickm> two main things there fwict: we're supposed to have 045 stable ready by jan 15, and we're supposed to freeze 046 on Feb 15.
17:15:44 <ahf> *nods*
17:15:53 <nickm> I don't see how we can get 045 done on time unless everybody prioritizes their 045 stuff
17:16:02 <nickm> and even then we may need more time, given TB release schedule
17:16:34 <ahf> how is the TB release schedule changing things here? that we get less testing done in time?
17:16:56 <nickm> Our last alpha doesn't get a TB release till next week iiuc
17:17:08 <ahf> i see
17:17:22 <nickm> and I don't know if there's time for us to get an rc tested in TB between then and 15 Jan
17:17:44 <ahf> and we are all gone until ~1 month before the feb freeze, hm
17:18:24 <ahf> maybe we need to move things a month at first?
17:18:32 <ahf> 0.4.6 freeze becomes march 15
17:18:33 <dgoulet> yeah we should likely add 15-30 days to the stable
17:18:36 <dgoulet> considering the holidays
17:18:40 <ahf> 0.4.5 stable becomes 15 february?
17:19:06 <nickm> I would be okay with that.
17:19:24 <ahf> let's do that then
17:19:29 <nickm> would we want to push back 047 and 048 as well?
17:19:29 <dgoulet> +1
17:19:40 <dgoulet> yeah I would shift it all
17:19:42 <nickm> (I'll edit the page)
17:19:59 <dgoulet> (side effect, the v2 users get 1 more month :P)
17:19:59 <asn> yep sounds good
17:20:04 <asn> :P
17:20:07 <asn> dgoulet: true
17:20:10 <ahf> either we move them now and rotate it forward or we limit scope there?
17:20:12 <ahf> i'm ok with either
17:20:31 <dgoulet> we could limit 046 scope but just seems more complicated? eheh no strong opinion
17:20:47 <nickm> edit done
17:21:06 <ahf> excellent. thanks nickm!
17:21:36 <ahf> okay, next item:
17:21:38 <ahf> First Monday meeting each month: Look at tickets/MRs with Backport label and figure out what to do and who is going to do the merging. https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Backport
17:21:54 <ahf> are we planning on rolling stables soon?
17:22:03 <nickm> well, hm.
17:22:11 <nickm> not for 044 and earlier
17:22:16 <nickm> unless there is something major
17:22:37 <nickm> but if there's anything pending a backport into 045, we should talk about it
17:24:03 <nickm> possible talk-about-it: tor#300187, tor#34088, tor#30477, tor#40168.
17:24:29 <dgoulet> also it appears that we have MR labeled Backport but the ticket is not as in it only has the xxx-backport
17:24:37 <ahf> the CBT things came to my mind
17:24:39 <ahf> ya
17:24:41 <asn> i'm currently reviewing the CBT code
17:24:42 <dgoulet> so we should really reconcile both or simply go over both
17:24:42 * ahf going over the list still
17:24:44 <nickm> err, tor#30187
17:24:52 <asn> i'm not sure if they should be backported -- they are not trivial
17:25:00 <ahf> so, tor#30477 is a bit different since it's technically not a bugfix
17:25:02 <nickm> which two?
17:25:05 <nickm> the cbt ones?
17:25:36 <nickm> asn: makes sense; complex backports are a risk.
17:25:42 <ahf> but i spoke with philip about this since it's (a) a pretty small change and (b) it is something that can help the anti-censorship team getting feedback on the new bridge status page
17:25:48 <nickm> asn: these are client-side bugs where clients get bad performance?
17:25:58 <ahf> this is very new though, i don't even think the patch entered tor yet since it wasn't reviewed last week
17:26:06 <ahf> so we can probably skip it this round
17:26:17 <nickm> if so I think I'm fine saying "if you want good performance you should use a recent stable branch"
17:26:48 <nickm> ahf: ok, we can talk about getting it into 045 or possibly sooner if it really is small
17:27:05 <nickm> ahf: we should just make sure that the branch is against the earliest maint-x branch that is affected?
17:27:06 <ahf> ya, but let's skip it for now i think - and bring it up again in january
17:27:08 <nickm> oth
17:27:13 <nickm> otherwise, baackporting is harder and nastier
17:27:16 <asn> it's mostly about timeout values being better tuned after those two CBT tickets
17:27:19 <nickm> *sp
17:27:27 <asn> so yeah it's about reachability and performance
17:27:36 <ahf> nickm: *nods*
17:27:38 <asn> but I don't think it's something drastic enough that we need to backport
17:28:01 <nickm> asn: yeah, if it's just about those two, then I think we can hold off on a backport.
17:28:13 <asn> sounds good
17:28:56 <ahf> ok, excellent
17:29:19 <ahf> tor#30187 i have no clue if we have gotten the feedback for we wanted?
17:29:35 <ahf> :-/
17:30:07 <nickm> ahf: I'm putting it in 0.4.4.x-final, since the fix is already in 0.4.5.  So we might backport it, but we might not
17:30:22 <nickm> It does drop win xp compat, withich is not a great thing to do in a stable release.
17:30:33 <ahf> yeah, that is a good point
17:30:44 <ahf> ... i hope nobody runs relays on windows xp though
17:30:52 <nickm> same here
17:30:53 <ahf> but i agree that it is a bad idea to change in a stable
17:31:35 <ahf> ok!
17:31:37 <ahf> very good folks
17:31:57 <ahf> we have no new team issues
17:32:20 <ahf> i am not sure what to do with core/team#10 ?
17:32:33 <ahf> since that is just something we continue to do but it also had checklists
17:33:00 <nickm> me neither.  We should do something with our colossal backlog some time, but this is not the time for me to attack it :)
17:33:08 <ahf> agreed
17:33:35 <ahf> okay, we got some new For <other team> tickets
17:33:49 <ahf> we have the browser folks requesting OS proxy settings in tor#40211
17:34:14 <nickm> I want clarity for that one.
17:34:28 <nickm> It looks like a single user has requested it, and the browser team has passed on the request.
17:34:41 <ahf> and we have tor#40209 from anti-censorship that arma is on tha ti will follow up o ntoo with s30
17:34:52 <nickm> Before we move forward with our own resources for it, I'd like to know (from whom?) whether it would help a bunch of users or no
17:35:09 <nickm> (40211)
17:35:10 <ahf> nickm: ya, i don't think it's a priority either
17:35:38 <ahf> i found a library that could provide the functionality for us, so we could also say that is something someone else is free to integrate against
17:36:42 <nickm> or we could ask the support folks whether this would be a big win
17:37:36 <ahf> asked in #tor-project now
17:37:40 <ahf> let's see what they say
17:37:47 <nickm> ack
17:37:55 <nickm> thanks!
17:38:17 <ahf> ok wow, that was a lot of items
17:38:20 <ahf> let's move to discussion topics
17:38:40 <ahf> no announcements this week
17:38:53 <ahf> [7 Dec] Nickm requests that people let him know what Tor tasks he's needed for in 0.4.6, particularly wrt sponsors. :)
17:39:31 <ahf> that is a bit of an announcement, or do you want the feedback right away if we know something coming up now?
17:40:13 <nickm> either one is fine; but as it stands I'm not sure how my various pending proposals fit in with what people need for sponsor work and other stuff
17:40:21 <nickm> So I could use reminders there, either sooner or later
17:40:24 <nickm> but sooner will help
17:40:25 <mikeperry> idk about 0.4.6 but congestion control and conflux would like prop#325 eventually. I am a little scared of trying to do that one myself
17:40:44 <nickm> ack
17:41:14 <ahf> isn't conflux a huge change? :o or maybe not?
17:41:27 <nickm> mike means that conflus will need prop325
17:41:28 <mikeperry> conflux will be big. congestion control won't be
17:41:30 <nickm> I think
17:41:33 <ahf> ah, right
17:41:34 <mikeperry> if we're just talking about code size
17:41:35 <nickm> *conflux
17:41:40 <ahf> ya
17:41:50 <dgoulet> I can take on prop325 once I'm done with overload
17:42:05 <dgoulet> and I'll put Nick heavily in the loop :)
17:42:53 <nickm> ok. when do you think overload will end?  let's revisit this then.
17:42:59 <nickm> do we have a ticket for it?
17:43:00 <ahf> the next question is a bit related to that. we talked about some proposals we would like to get into tor soon'ish not that long ago and the next question is if we'll make those for 0.4.6
17:43:47 <nickm> I've done two of them
17:44:09 <nickm> ahf, you're listed on prop#275
17:44:17 <nickm> asn: you're listed on prop#285
17:44:26 * ahf hopes to do the published field one in early january, but want to be out of s91 first
17:44:32 <dgoulet> nickm: should be done in a week or two as in implementation
17:44:33 <nickm> ack
17:44:42 <nickm> dgoulet: okay, sounds good.
17:44:43 <ahf> and now that we just pushed freeze i think it might be more realistic, it seems like not a very big change
17:45:20 <asn> will need to check prop#285 again. it has dropped off my radar due to the other thigs i admit.
17:45:57 <ahf> ack ack, very good
17:46:20 <ahf> okay, the last one: should we drop github and thus appveyor and travis-ci and say gitlab's CI is what we follow now?
17:46:32 <ahf> the sysadmin team will hopefully have 2 boxes for us this week where i can move my macos and windows images too
17:46:33 <nickm> specifically:
17:46:42 <nickm> I'm thinking that we should stop pushing branches to github.
17:46:58 <nickm> We can if we want to, but I think we should stop calling it a requirement for our review process
17:47:18 <ahf> yeah
17:47:20 <asn> how much "CI-ness" do we lose by losing appveyor and travis-ci in favor of the pipelines?
17:47:28 <dgoulet> so since master is mirrored on Github, we will get the GH CI on master at least?
17:47:39 <ahf> asn: quite some for some period of time, but we have builds happening automatically from the sync
17:47:52 <ahf> and i catch windows cross-compile failures on a daily basis from the cronjobs
17:48:02 <ahf> like we saw with the v3 metrics
17:48:12 <ahf> and you can still do it optionally if you want to be safe
17:48:14 <asn> and are we doing this because it's hard to maintain travis green (it's broken since like 2 weeks now at least), or because we no like GH?
17:49:03 <dgoulet> a bit of tidious process I'M guessing
17:49:10 <ahf> because it's quite a bit of overhead i think and we don't remember it every time
17:49:14 <dgoulet> also creates the fun bug we got with v3 metrics asn :)
17:49:22 <dgoulet> (with new commits on one side but not the other eheh)
17:49:42 <asn> hm ok
17:50:03 <nickm> also, doing this encourages us to spend our time making GL better, not on keeping travis alive
17:50:15 <asn> ok sounds good!
17:50:25 <asn> we can do that, and if we decide it's a bad idea we can revert
17:50:30 <dgoulet> yah
17:50:30 <asn> to the previous situation
17:50:33 <dgoulet> agile
17:51:01 <ahf> the new machines we get will also make our gitlab ci faster. it's not as fast right now as i had hoped for but i think that is because we share our builders with another community
17:51:38 <ahf> okay, it sounds like we have a yes
17:52:04 <ahf> ok
17:52:22 <ahf> i see nothing in bold :o
17:52:26 <ahf> i think that might mean we are done
17:52:37 <ahf> very good folks. thanks all o/
17:52:51 <gaba> thanks ahf for moving all this today
17:52:56 <ahf> #endmeeting