16:59:08 #startmeeting network team meeting december 7 2020 16:59:08 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:14 o/ 16:59:19 hello network team! 16:59:31 our pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep 16:59:40 ehlo 16:59:42 writing report now 16:59:43 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 very good 17:00:45 o/ 17:00:47 o/ 17:00:56 just waiting for everybody to arrive 17:00:59 \o 17:01:29 how are folks doing with their ticket dashboards: https://gitlab.torproject.org/groups/tpo/core/-/boards ? 17:01:36 report done 17:01:59 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 gaba: thanks for adding the missing labels to the flashflow ticket! i was just about to mark that as doing 17:02:31 nickm: is that one of the discussion points? 17:02:38 yes 17:02:38 o/ 17:02:42 oki, cool! 17:02:42 hi dgoulet ! 17:02:55 welcome dgoulet o/ 17:03:06 im meaning to make two s61 tickets that i havent caught up to it yet 17:03:16 they will likely be on the "doing" side of things, or on the "next" 17:03:24 asn: excellent 17:03:51 so for MR assignment: we have 12 tickets it seems that are unassigned in tpo/core/** 17:03:57 eek 17:03:59 ok noted 17:04:01 will do so today or tomorrow 17:04:06 yeah need to get to that 17:04:07 looks like both some spec stuff and some tor stuff 17:04:22 we also have pages of MRs total not in backport (see link from pad) 17:04:51 everybody please remember to make sure you're making progress on reviews as feasible :) 17:05:14 ya, there is of course also assigned MR's that are unreviewed yet 17:05:21 nickm: yep 17:05:52 if you're stuck reviewing somethign I didn't write, you can assign it to me 17:06:01 if you're stuck reviewing somethign I did write, you can ask me about it :) 17:06:59 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 so you are welcome to assign PT/bridge stuff to me, or windows stuff to me directly and so on 17:07:21 and onion service stuff to asn/dgoulet 17:07:26 etc. 17:07:26 yup 17:07:36 I've been doing that a bit recently just to speed things up 17:07:36 agreed 17:08:05 ok, how are we doing with 0.4.5 ? 17:08:39 i didn't see anything new coming in over the last week 17:09:02 can we look at our 045-must tickets and/or the 045-stable tickets? 17:09:34 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 (looks like we removed must) 17:10:28 I see a few unassigned ones there 17:10:38 and a bunch of assigned ones in various states 17:10:59 I'll take tor#40188 17:11:15 2 tickets that are not in backport but are unassigned 17:11:27 tor#40208 is the other one 17:11:48 yeah that one seems related to me 17:11:50 looks a bit related to the s55 changes that went in? 17:11:54 I have to get to all of those from s7r... 17:12:01 I've been slacking on them :( 17:12:30 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 i'm also happy to help out if you want a 2nd person to work with on them 17:12:56 on it 17:13:06 thanks! 17:13:42 * ahf uses the above URL in the pad instead of what is there now ... 17:14:52 okay. we good to move to releases page? 17:15:03 ok by me 17:15:27 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 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 *nods* 17:15:53 I don't see how we can get 045 done on time unless everybody prioritizes their 045 stuff 17:16:02 and even then we may need more time, given TB release schedule 17:16:34 how is the TB release schedule changing things here? that we get less testing done in time? 17:16:56 Our last alpha doesn't get a TB release till next week iiuc 17:17:08 i see 17:17:22 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 and we are all gone until ~1 month before the feb freeze, hm 17:18:24 maybe we need to move things a month at first? 17:18:32 0.4.6 freeze becomes march 15 17:18:33 yeah we should likely add 15-30 days to the stable 17:18:36 considering the holidays 17:18:40 0.4.5 stable becomes 15 february? 17:19:06 I would be okay with that. 17:19:24 let's do that then 17:19:29 would we want to push back 047 and 048 as well? 17:19:29 +1 17:19:40 yeah I would shift it all 17:19:42 (I'll edit the page) 17:19:59 (side effect, the v2 users get 1 more month :P) 17:19:59 yep sounds good 17:20:04 :P 17:20:07 dgoulet: true 17:20:10 either we move them now and rotate it forward or we limit scope there? 17:20:12 i'm ok with either 17:20:31 we could limit 046 scope but just seems more complicated? eheh no strong opinion 17:20:47 edit done 17:21:06 excellent. thanks nickm! 17:21:36 okay, next item: 17:21:38 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 are we planning on rolling stables soon? 17:22:03 well, hm. 17:22:11 not for 044 and earlier 17:22:16 unless there is something major 17:22:37 but if there's anything pending a backport into 045, we should talk about it 17:24:03 possible talk-about-it: tor#300187, tor#34088, tor#30477, tor#40168. 17:24:29 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 the CBT things came to my mind 17:24:39 ya 17:24:41 i'm currently reviewing the CBT code 17:24:42 so we should really reconcile both or simply go over both 17:24:42 * ahf going over the list still 17:24:44 err, tor#30187 17:24:52 i'm not sure if they should be backported -- they are not trivial 17:25:00 so, tor#30477 is a bit different since it's technically not a bugfix 17:25:02 which two? 17:25:05 the cbt ones? 17:25:36 asn: makes sense; complex backports are a risk. 17:25:42 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 asn: these are client-side bugs where clients get bad performance? 17:25:58 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 so we can probably skip it this round 17:26:17 if so I think I'm fine saying "if you want good performance you should use a recent stable branch" 17:26:48 ahf: ok, we can talk about getting it into 045 or possibly sooner if it really is small 17:27:05 ahf: we should just make sure that the branch is against the earliest maint-x branch that is affected? 17:27:06 ya, but let's skip it for now i think - and bring it up again in january 17:27:08 oth 17:27:13 otherwise, baackporting is harder and nastier 17:27:16 it's mostly about timeout values being better tuned after those two CBT tickets 17:27:19 *sp 17:27:27 so yeah it's about reachability and performance 17:27:36 nickm: *nods* 17:27:38 but I don't think it's something drastic enough that we need to backport 17:28:01 asn: yeah, if it's just about those two, then I think we can hold off on a backport. 17:28:13 sounds good 17:28:56 ok, excellent 17:29:19 tor#30187 i have no clue if we have gotten the feedback for we wanted? 17:29:35 :-/ 17:30:07 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 It does drop win xp compat, withich is not a great thing to do in a stable release. 17:30:33 yeah, that is a good point 17:30:44 ... i hope nobody runs relays on windows xp though 17:30:52 same here 17:30:53 but i agree that it is a bad idea to change in a stable 17:31:35 ok! 17:31:37 very good folks 17:31:57 we have no new team issues 17:32:20 i am not sure what to do with core/team#10 ? 17:32:33 since that is just something we continue to do but it also had checklists 17:33:00 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 agreed 17:33:35 okay, we got some new For tickets 17:33:49 we have the browser folks requesting OS proxy settings in tor#40211 17:34:14 I want clarity for that one. 17:34:28 It looks like a single user has requested it, and the browser team has passed on the request. 17:34:41 and we have tor#40209 from anti-censorship that arma is on tha ti will follow up o ntoo with s30 17:34:52 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 (40211) 17:35:10 nickm: ya, i don't think it's a priority either 17:35:38 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 or we could ask the support folks whether this would be a big win 17:37:36 asked in #tor-project now 17:37:40 let's see what they say 17:37:47 ack 17:37:55 thanks! 17:38:17 ok wow, that was a lot of items 17:38:20 let's move to discussion topics 17:38:40 no announcements this week 17:38:53 [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 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 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 So I could use reminders there, either sooner or later 17:40:24 but sooner will help 17:40:25 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 ack 17:41:14 isn't conflux a huge change? :o or maybe not? 17:41:27 mike means that conflus will need prop325 17:41:28 conflux will be big. congestion control won't be 17:41:30 I think 17:41:33 ah, right 17:41:34 if we're just talking about code size 17:41:35 *conflux 17:41:40 ya 17:41:50 I can take on prop325 once I'm done with overload 17:42:05 and I'll put Nick heavily in the loop :) 17:42:53 ok. when do you think overload will end? let's revisit this then. 17:42:59 do we have a ticket for it? 17:43:00 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 I've done two of them 17:44:09 ahf, you're listed on prop#275 17:44:17 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 nickm: should be done in a week or two as in implementation 17:44:33 ack 17:44:42 dgoulet: okay, sounds good. 17:44:43 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 will need to check prop#285 again. it has dropped off my radar due to the other thigs i admit. 17:45:57 ack ack, very good 17:46:20 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 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 specifically: 17:46:42 I'm thinking that we should stop pushing branches to github. 17:46:58 We can if we want to, but I think we should stop calling it a requirement for our review process 17:47:18 yeah 17:47:20 how much "CI-ness" do we lose by losing appveyor and travis-ci in favor of the pipelines? 17:47:28 so since master is mirrored on Github, we will get the GH CI on master at least? 17:47:39 asn: quite some for some period of time, but we have builds happening automatically from the sync 17:47:52 and i catch windows cross-compile failures on a daily basis from the cronjobs 17:48:02 like we saw with the v3 metrics 17:48:12 and you can still do it optionally if you want to be safe 17:48:14 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 a bit of tidious process I'M guessing 17:49:10 because it's quite a bit of overhead i think and we don't remember it every time 17:49:14 also creates the fun bug we got with v3 metrics asn :) 17:49:22 (with new commits on one side but not the other eheh) 17:49:42 hm ok 17:50:03 also, doing this encourages us to spend our time making GL better, not on keeping travis alive 17:50:15 ok sounds good! 17:50:25 we can do that, and if we decide it's a bad idea we can revert 17:50:30 yah 17:50:30 to the previous situation 17:50:33 agile 17:51:01 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 okay, it sounds like we have a yes 17:52:04 ok 17:52:22 i see nothing in bold :o 17:52:26 i think that might mean we are done 17:52:37 very good folks. thanks all o/ 17:52:51 thanks ahf for moving all this today 17:52:56 #endmeeting