16:59:12 #startmeeting network team meeting, 23 march 2020 16:59:12 Meeting started Mon Mar 23 16:59:12 2020 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:15 hello network-team 16:59:22 https://pad.riseup.net/p/tor-netteam-2020.1-keep is our pad 16:59:26 who is here for the meeting? 16:59:27 o/ 16:59:39 hi! 16:59:45 o/ 16:59:50 hi 17:00:45 o/ 17:00:59 https://gitlab.torproject.org/torproject/core/tor/-/boards are folks doing OK with roadmapped items? 17:01:23 * nickm is here 17:01:45 i'm roadmapped on walking onions spec but I don't see that there 17:01:51 looking again... 17:02:12 yes, I think I did not add that ticket 17:02:33 do you remember which # is? 17:02:35 we should talk about this tomorrow at our 1:1:1, gaba + ahf. this kanban is not our roadmap 17:02:47 mmm, ok 17:03:02 we need to roadmap again 17:03:05 * ahf nods 17:03:09 this has all the tickets from our last roadmap exercise 17:03:18 no the ones like walking onions that we didnt do in that roadmap 17:03:26 but let's talk tomorrow 17:03:28 It's #33527 17:04:09 +1 17:04:33 sounds good 17:04:38 dgoulet: you did reviewers already? 17:04:44 i think i saw that with half an eye 17:05:04 looks they are all allocated 17:05:13 ahf: I did 17:05:22 dgoulet: thx for doing reviwers! 17:05:36 thanks to both of you in general for doing this - is good! 17:05:44 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases/043Status let's look at 0.4.3 17:05:50 nickm: anything you want to add there? 17:06:21 what should i do with #29220? 17:06:30 it's off the roadmap but still on the milestone 17:06:31 i don't have anything right now... 17:06:34 off the roadmap and sponsor 17:06:37 should i push it to unspecified? 17:07:14 it is a should ticket, so i assume it can be pushed to 0.4.4? 17:07:35 ack 17:07:38 will do! 17:09:01 okay, we have quite a few discussion topics 17:09:15 first one is from teor around #32804 - travis CI issues with macOS 17:09:32 one question they are raising is if we should disable tor and the chutney travis ci jobs there? 17:09:46 they are still awaiting response from the support team there asfaik 17:10:56 imo I can see it being sensible either way 17:11:04 nobody? i think we should wait with what they say if theey back to us 17:11:21 yep 17:11:28 they are on leave this week but I think it would be lovely if somebody wrote a ci policy about what we do in these cases 17:11:36 how long has it been failing? 17:12:07 good idea 17:12:13 catalyst: not for long i think. i think it was discovered last week 17:12:14 the linked ticket is from 3 months ago, but it is supposed to have gotten worse recently 17:12:19 yeah 17:12:26 it has been flaky before but it now it happens more often 17:13:15 * catalyst looks at travis dashboard 17:14:18 the same question applies sort of for jenkins 17:14:24 a lot of our jenkins builders have had issues 17:14:24 i'm seeing a number of "errored" states for pull requests from what look like new contributors. we might want to think about disabling the erroring job sooner rather than later 17:14:33 nickm: which one of them are essential for the release work? 17:14:46 none of this is _essential_ for release, but they all help 17:14:50 catalyst: so you prefer disabling it for now? 17:15:02 disabling or "can-fail"-ing bogus stuff is probably better than leaving it 17:15:08 nickm: also for jenkins? i had the feeling jenkins was important for releases? 17:15:11 allow_fail is probably better 17:15:17 i worry about the cases when nobody has responsibility for fixing 17:15:26 right 17:15:30 for jenkins it's not so bad since it doesn't bother contributors, only releasers 17:15:53 catalyst: would you be up for enabling the allow_fail for those builds then after the meeting? 17:16:25 catalyst: I think you've advocated for automatically allow_fail on upstream failures in the past. is that right? 17:16:32 if so I think i'm coming around to that pov 17:17:01 nickm: i think something like that? maybe not automatically, but more like fast-tracking setting allow_fail 17:17:32 i still think we should consider it case-by-case, but the default should be to allow_fail 17:17:37 yeah 17:17:46 maybe somehow making sure we re-revaluate at useful intervals 17:17:53 let's try that with these and consider making it our policy 17:18:12 for jenkins, we should fix them, but it takes work 17:18:18 (i think that's all i have) 17:19:15 okay 17:19:25 catalyst: would you be up for enabling that flag for tor.git ? 17:19:50 ahf: sure. there are a few things i have to check first 17:19:59 okay, thanks catalyst! 17:20:10 Should we defer the 0.4.3 stable release plan? Nick suggests rc on April 3, planning for stable release by end of april. No delay to subsequent release 17:20:14 ahf: like do we want to make sure we don't lose coverage for things that we're incidentally doing only on macOS that we could be doing elsewhere 17:20:21 i guess the question here is "does anybody think that is a bad idea?" 17:20:31 (please tell me if so?) 17:20:38 catalyst: yep, that makes sense 17:21:53 Should we auto-close old pull requests on GitHub? 17:22:05 there's a ticket for that and some discussion happening there 17:22:10 i have thought about that before. i think this could be a good idea. i have seen other projects have bots do that 17:22:15 yes, it's #33629 17:22:25 folks should comment there if they have opinions 17:22:26 I think some of these discussion items are from last week? 17:22:36 plausible 17:22:40 the next two are 17:22:44 (should we auto-delete discussion items after sending updates?) 17:22:51 yes 17:23:03 Volunteers need help. Please help them when you are around.Maybe we should have times of day when different people are responders, and expectatios of who helps 17:23:06 is new for sure 17:23:11 yes 17:23:30 I think teor (and me to a lesser extent) are answering a lot of volunteers on the channels 17:23:50 I would say "everybody please remember to help with this"... 17:24:03 but in the past, making things "everybody's job" means everybody hopes somebody else will do it 17:24:25 I wonder if there is some way to "assign" this work fairly like we do for reviews 17:24:32 something to think about if anyone has ideas 17:24:57 something we've done in past project I've been on is "on duty" rotations 17:25:02 especially right now where a lot of people are coming in to ask about things because of outreachy it is good to help out with this 17:25:18 i don't think there will be as many as there is right now in the future, so doing a bit extra there is good 17:25:25 and also be helpful to people who PM you 17:25:41 i have no idea if i get more of those because my nick starts with a, but i have gotten a few of them in the past 2 weeks or so 17:25:42 ahf: do we know what times of day are the peaks for questions from new folks? 17:25:46 also just because somebody says "hey teor" or "hey nickm" doesn't mean that we are the only ones who can help them :) 17:26:03 it just means that we are the ones who helped them most recently 17:26:06 catalyst: i think from 15 UTC or something like that? i have the feeling it is a lot of US TZ times? 17:27:00 jnewsome: yeah, we have had rotating duties before in the network team 17:27:16 but we ended up getting rid of a lot of them a while ago and turning them into more static roles 17:28:20 nickm: that is a very good point 17:28:34 if people ask for other folks on irc, but you can answer the question, please just feel free to 17:28:41 the other person can always follow up when they are around 17:29:08 i seem to recall that some new volunteers are most active on weekends and nights in their local time? or people notice otherwise? 17:29:21 maybe this is too big of a quiestion for this meeting - but have we considered other support channels? 17:29:34 e.g. if there was a support ticket, someone could pick up where things left off and be able to read the context 17:29:35 we also get questions on trac and sometimes the mailing lists 17:29:40 catalyst: yes, there are more activity in the weekends for sure 17:29:58 catalyst: there's definitely weekend demand. since i'm at home all the time now, i allocated a little time each day to check for questions. 17:30:01 jnewsome: there have been alternatives to irc up before 17:30:11 maybe we need to schedule weekend rotations. but that might take a while to arrange and ramp up 17:31:06 yeah. and it's not something I'd want to ask anybody to do 17:31:12 maybe we should try to steer people harder toward those other channels? irc/chat is kind of the worst support channel in a lot of ways; the only advantage is (potentially) immediate gratification 17:31:12 it would work right now, but as soon as we are no longer stuck to our homes i think it will collapse 17:31:22 Hi all 17:31:33 hello amar94 17:31:38 hi amar94 ! Are you here for the network team meting? 17:32:04 Hi yes, I was chating with ggus so he invited me join here 17:32:14 cool 17:32:15 ! 17:32:19 what can we help you with? 17:32:32 catalyst: more than rotations I think it woudl be useful if everybody allocates a little time each day for this. 17:32:49 I offered to help to org. this year, will have more time to spend here 17:33:15 amar94: you do programming in C and/or python and/or rust? or help in general with non-programming things? 17:33:38 (what's next on the meeting agenda?) 17:33:42 yeah, I do haskell for now and oracle tech. 17:33:50 we have nothing more on the agenda 17:33:58 amar94: can we move to #tor-dev and then we can end the boring parts of our meeting? 17:34:00 have experience with rust 17:34:01 would that be OK? 17:34:16 ok: reminder to please vote on the pending policy proposals if you haven't alrady 17:34:19 *already 17:34:20 and that's all from me 17:34:21 sure, everything is ok 17:34:25 amar94: let's chat in there 17:34:27 #endmeeting