17:00:08 #startmeeting network team meeting, 19th of april 2021 17:00:08 Meeting started Mon Apr 19 17:00:08 2021 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:11 hello everybody 17:00:17 hi ahf ! 17:00:20 we have a pad at https://pad.riseup.net/p/tor-netteam-2021.1-keep 17:00:24 o/ 17:00:38 asn says he's stuck in traffic 17:00:46 ya 17:01:09 o/ 17:01:31 hihi 17:01:32 hello hello 17:01:37 o/ 17:01:50 how are folks doing with their boards? 17:02:12 mostly ok I think? 17:02:30 just updated mine, all good 17:03:47 what is the single biggest annoyance you guys are having right now that i might be able to help with? my plan so far was to dive heads first into tor#40280 and tor#40048 this week since i am home where i have a desktop that can run VM's well, but if there is something MORE urgent, please let me know 17:04:18 the 2nd ticket is for macos and windows, the first one is mostly done and just needs to run as a builder 17:04:32 that sounds pretty awesome honestly 17:04:52 o/ 17:04:56 I'm hoping you can help me think about gitlab+signing issues, but that shouldn't take all week 17:04:59 hi gaba ! 17:05:25 ok. please let me know if there is something you want to offload to me. i am behind on points with some of our more boring tasks and you guys have taken a lot of those in the past weeks without me 17:05:27 hey gaba 17:05:29 ok, cool! 17:05:34 and maybe review the arti proposal at some point this week ahf 17:05:55 gaba: yes, i have that on the list, but not on hax work :-) 17:06:12 nice. thanks 17:06:18 how are things looking with our releases ? 0.4.5-post-stable and 0.4.6-stable ? 17:06:24 i know there aer some discussion items related to that 17:07:18 no assignee on tor#40352 -- can I give it to dgoulet or asn? 17:07:47 hm! looks oniony 17:07:53 sure 17:08:29 done 17:08:56 Are we seeing any urgent or must-fix items on those lists? 17:09:55 (I am not; they are all worth doing, but none seems to be "omg!") 17:10:13 agree 17:10:22 agreed 17:10:43 i see no new items from other teams for us 17:11:10 i have some request for s61 17:11:14 hmmm yeah ^ 17:11:22 but we can do that when s61 time is come 17:11:29 (not sure about the procedure here) 17:11:31 GeKo: huh, maybe it was hidden from me? i saw two network health labels there 17:11:38 GeKo: say what it is i think is easiest :-) 17:11:42 now is an OK time 17:11:47 heh :) 17:12:09 okay, so i was quite surprised seeing only the overload items for s61 landed in 0.4.6 17:12:19 that is only *part* of prop328 17:12:27 while the relay metrics has not 17:12:33 originally i was under the impression 17:12:46 that the overload items would be squeezed into the first alpha 17:12:50 to get us going 17:13:04 and then the remainder of prop328 would be in one of the follow-up alphas 17:13:08 for the 0.4.6 series 17:13:15 after all its one feature 17:13:19 *it's 17:13:32 so, i would like to see the remaining pieces in 0.4.6.x stable 17:13:38 Are you advocating that we break feature freeze to try to implement this in 046x stable? 17:13:46 (Is this patch implemented?) 17:13:47 ... isn't it multiple features in one proposal? :o i don't remember it entirely but i think there is some metricsport stuff in it too? 17:13:59 yes the metricsport stuff 17:14:23 it's the metricsport values that is missing? 17:14:23 the thing is that it's hard to go to relay operators and say, "hey, your relay has an overload condidtion" 17:14:38 and then they are coming back to us asking about what's going on 17:14:53 and we can't point them to things because the metrics port values aren't implemented 17:14:55 So before we continue, here is a perspective I want you to consider: 17:14:55 ahf: yes 17:15:32 i think i would tell the relay ops that this is coming in the next release then? i think we hvae a plan for it 17:15:44 ahf: tpo/core/Tor#40367 it is 17:15:53 When we got to the point of deciding what would go in before the 0.4.6.x feature freeze, we decided that these indicators could go in because they were done and working, and that this part of prop#328 would be better than nothing. 17:15:54 tpo/core/tor#40367 17:16:10 ya, reading it now 17:16:30 ahf: okay, but then this means i can't start poking relay operators for another couple of months 17:16:41 i think this wont be the first time we split a proposal intl two releases, and i don't think we should block our current plans for it 17:16:48 because it's hard for them to fix their issues 17:16:57 Here is a compromise proposal: 17:16:59 i can see it is annoying not to have an answer to them, but they will get one soon 17:17:03 (ish) 17:17:25 compromise proposal: if it isn't too hard, base the branch against maint-0.4.6 for a possible backport, but target it for 047. 17:17:41 If the branch causes absolutely 0 trouble when merged 047, consider a backport. 17:17:45 ahf: well, i won't start asking in that case 17:17:46 plausible? 17:17:49 ah, that is a good idea, nickm 17:18:08 nickm: works for me, thanks 17:18:19 GeKo: we can keep track on things like how often the overload-general timestamps update in the meantime. that is useful to learn 17:18:21 it is a quite new interface the metricsport, so i think that is our absolute power users who would be interested in that. i think that is a good idea 17:18:26 i think the questions is who puts it on their plate 17:18:35 mikeperry: yes, i agree 17:18:46 like, to get a handle on ephemeral overload vs constant overload 17:18:46 nickm: i will add a note with what you just said on the ticket 17:18:56 ahf: sounds good 17:18:58 stats on that will help inform how sbws should react. so we can make progress 17:18:59 but i feel it's not useful to poke relay ops if we don't have the metricsport data for them available 17:19:11 i am not concerned about sbws here 17:19:15 well, once it's merged, you can poke the ones who are running 047 :) 17:19:33 the 047 powerusers who are overloaded! 17:19:42 yep 17:19:46 ok, very good 17:19:48 yeah. I think the backport is an ok option for the outreach issue. people like toralf might also run the patch if we ask. toralf seems to recompile often 17:20:01 should i do a doodle to tor-internal@ with upcoming thursdays for next arti hackathons? 17:20:05 toralf runs nightly iirc 17:20:12 ah 17:20:26 akka and ukko can also be made to run latest if we are prodded 17:20:36 ahf: sounds good, especially if we can maybe talk about what we want to do. Organize it more or less like the last arti hack-day, or something diffeerent? 17:20:40 *different 17:21:02 I'm thinking it might be fun to pick up asn or dgoulet's hackweek project, unless folks have a better idea 17:21:15 nickm: we can send a link to the video of the intro we made too and tell people they can watch that to get some info? i don't know if there is a good theme to put on this hackday since i am behind on arti stuff, but do you have suggestions? 17:21:21 ah 17:21:33 dgoulet's was tooling based on arti and asn was working on v3 onions? 17:21:38 wait, we looking for hackweek ideas again? 17:21:46 we are looking for hackday ideas 17:21:47 dgoulet: arti hackday ideas in advance :) 17:22:01 can't do a week :-( 17:22:31 ok 17:22:46 taking david's work is to also build some idea about what API's are missing, right? 17:22:46 shall think about it and talk more on thursday? 17:22:53 yes, sounds like a good idea 17:23:00 my two cents is that we should have projects using arti as a lib 17:23:03 to learn from that experience 17:23:07 oh like ahf said lol 17:23:45 dgoulet: artisocks? ;) 17:23:46 if we can think of API things to build tor tooling around arti in parallel with the client development is happening without it affecting the latter, then i think it is a very good idea 17:25:35 jnewsome: sounds almost like artischoke 17:25:37 ok! 17:25:51 2021-04-19, nickm, who will coordinate with our master->main branch transition in mid-May? And whom do we need to coordinate with? 17:26:02 i saw a conversation with the browser folks about this 17:27:27 We decided we wanted a mid-may deadline on thursday. I can take care of actually doing the switch, but there are other things to migrate, and tooling to do, and probably things will break. 17:28:22 i think it is hard to avoid playing a bit of whac-a-mole when doing something like this 17:28:28 fortunately, it isn't something we do often 17:28:43 if we can let the community know we do it, then people might be able to catch it? 17:29:01 i don't even know if metrics services pulls things such as geoip tables from tor.git and maybe they need the master branch for that? 17:29:01 yeah. we should probably figure out whatever moles we can whack in advance, though, and make sure there's a list 17:29:09 ya 17:29:24 maybe if we create a ticket for it and let the community know to report things there if there is something that they cannot fix? 17:29:32 i can't imagine that being the case though 17:29:52 maybe the community should be #tor-project here -- I don't really want to solicit feedback on the namechange from the whole wide world 17:30:27 Can we do a push hook on gitolite or gitlab to reject pushes to master after the move? 17:30:28 hm, true. we could prod the team leads directly and irl/acute on the metrics side of things? 17:30:37 sounds reasonable 17:30:41 i *think* so, but i will have to look into that 17:30:47 ack 17:31:12 i think right now we cannot delete a remote via gitolite 17:31:16 that needs an extra permission 17:31:21 so we need to coordinate that, but i can do that 17:31:48 so we need to disable the protection, delete master, enable protection against (re)creating the master branch 17:31:48 sounds great. 17:31:55 cool 17:32:10 will you prod TL's ? 17:32:21 sure 17:32:42 excellent 17:32:47 ok, last item before s61 things: 17:32:57 2021-04-19, nickm, next target release dates: how about Apr 30, then May 14? 17:33:37 This would be for 046. I think we should aim to have everything fixed by 14 May if we possibly can, so we can call that one an rc 17:33:40 plausible? 17:34:27 sounds good to me 17:35:09 ok, i'm out of stuff 17:35:17 * ahf too 17:35:25 mikeperry: you wanna run s61 things? 17:35:45 yeah, not much more to discuss. I'm in covno's with ana about new onionperf instances 17:35:54 hi! 17:36:07 generally tyrying to kn ock out non-s61 stuff off my TODO before getting into congestion control 17:37:06 oh yeah we have the report due at the end of the month 17:37:50 gaba: you have all the tickets, yes? would you like help from ppl with any of the descriptions too? 17:38:17 acute: o/ 17:39:04 mikeperry: I'm about to reply on onionperf/40018, we're pretty much ready to deploy the instances 17:39:09 ok 17:39:50 I left some graphs for you in onionperf/33421 too, if you wanted to have a look 17:40:38 hey mikeperry: now im looking at indicators 17:40:42 ok I'll take a look at those 17:40:46 i will do the report after and then i send it to people 17:41:09 i think i have evertyhing i need for the report in the pad 17:41:46 gaba: wrt indicators, I don't think much has changed, though we can give them some stats from the sbws vs torflow analysis that may fit some of those categories. juga and geko may be able to help with that 17:42:28 i've added all 17:42:36 nice 17:42:37 my s61 parts for the report i think 17:42:42 *of my 17:42:45 yes, i have a lot of questions wrt indicators "_ 17:43:33 gaba: ping juga/me and we can talk about it 17:43:37 and help with that part 17:44:07 yup 17:44:18 thanks 17:44:23 i am not sure what indicators you are talking about, though :) 17:45:58 i will send you later the file with them 17:46:05 thanks 17:47:58 ok I think we're good for s61 then, unless there are other questions? 17:48:13 i'm good 17:48:30 not from me 17:49:06 im good 17:49:10 gonna tell the bot to stop logging then 17:49:12 thanks all o/ 17:49:14 #endmeeting