16:59:00 #startmeeting network team meeting october 5 16:59:00 Meeting started Mon Oct 5 16:59:00 2020 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:03 hello everybody 16:59:04 hi ahf! 16:59:08 hi 16:59:10 pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep 16:59:38 (sec at another meeting. will join right after.) 16:59:43 oki 17:00:12 o/ 17:00:15 o/ 17:00:16 ok 17:00:28 let's start with our board: https://gitlab.torproject.org/groups/tpo/core/-/boards 17:01:05 o/ 17:02:09 are everybody OK with the state ? 17:02:17 state of the board* 17:02:51 :o 17:02:57 doesn't look in any emergency situation ;) 17:02:58 i'm not 100% sure that my next/backlog items reflect what I should be doing, but I hope I can sort that out 17:03:10 ok 17:03:55 reviewers looks good, except for tor!165 17:04:03 i can grab that 17:04:09 it is very small 17:04:11 there is one issue in the doing in the board that has noone assigned 17:04:20 #40073 17:04:42 looks it it got reopened for backport; that should be "needs review" 17:05:16 fixing 17:05:33 done 17:05:53 ok, 0.4.4 status 17:07:09 oh, this is our first-meeting-of-the-month. Should we be talking about backports? 17:07:16 yes 17:07:18 we should 17:07:44 we need to figure out how we handle this 17:07:59 last time i think nickm and i went over the list and prioritized them and did some of them and removed backport from some others iirc 17:08:03 i guess it's the same goal we have here? 17:08:09 and assign who does the backport work 17:09:03 does this query look correct: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Backport ? or should we do it on tickets always and not the MR's ? 17:09:30 https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Backport same but for issues 17:09:49 i think so. 17:10:37 how do we prefer to do this? looks like there are 17 17:11:13 i'm okay with bacakporting, but it helps to have somebody else go through the list with me and help me assess risk vs benefit 17:11:26 the risk v benefit assessment is the most important part IMO 17:11:38 i don't think you should be doing them all 17:11:53 ok w me 17:12:18 tor#40098 seems low risk 17:12:50 tor#32673 was one we were a bit worried about at one point i think? 17:12:55 but maybe it has baked for a while now 17:13:54 I don't want to merge tor!43 unless we can be sure it didn't cause any of the other NSS issues people are seeing 17:14:00 tor#33131 was marked medium-risk last time 17:14:18 ok, so the nss one is a high-risk one 17:14:39 there is a few sandbox related ones 17:15:21 maybe we should come into this with all the tickets labeled with risk/benefit/when-merged? 17:15:31 asn, dgoulet: any thoughts about how we should be doing this? 17:16:06 i think they should be labeded yes 17:17:23 all of those are in master and been there for a while so what is the worry here as in the "risk metric" ? 17:17:33 (I mean, they've all been "baking" for a while...) 17:17:53 i think we're trying to feel our way toward a process 17:18:04 tor#33880 doesn't seem that scary 17:18:27 personally, I would just merge them all :) ... I mean none of them blew up in our faces on master and not sure we'll be able to do anything more by re-assessing them? 17:18:54 i think the NSS one we are unsure about? 17:19:04 but that one is not upstream? 17:19:28 hm? 17:20:04 what do you mean upstream here? 17:20:06 in a release? 17:20:09 let me rephrase 17:20:30 the question here is to assess *IF* we should backport right? 17:20:49 or if it needs to wait a bit with being backported because we don'th ave confidence in it yet 17:20:58 if it hasn't been brewing for long enough 17:21:27 yeah I have NO metrics whatsoever to assess that level of confidence 17:21:54 i think we mostly have time and number of bugs coming in 17:21:57 so personally, I don't think it is very useful exercise to do that but rather simply decide *if* we should backport or not based on our criteria 17:23:04 okay, so instead you think that looking at the list and *removing* items we wont need to backport is smarter/better? 17:23:11 correct 17:23:25 is there anything on the list *other* than the NSS one that we want to wait with? 17:23:45 yeah, hang on 17:24:06 tor#27194 17:24:14 it's only been merged to master, not to a stable release. 17:24:17 and the benefit is really small 17:24:49 if the benefit is small, then do we want to do it even if it comes out in a stable release? :-) 17:24:56 my two cents, I would be fine with all of those being backported 17:25:52 IMO we should still go over the list and do the cost/benefit assessment 17:26:44 this was so easy on voice last time we did it. is irc the right form for doing this then? is this something we should do on our first thursday meeting instead? 17:26:45 but I think backporting should be fine 17:28:01 here's what i can do: I'll look over the list of things that don't alrady have one of those "triage status" notes we did last time, and add them 17:28:48 ok 17:28:57 then we can see if anything's nontrivial to backport 17:29:00 and see what's next 17:29:07 i'll add that to my todo for the week 17:29:33 ok, and pick network-team if/when we need to look? 17:29:39 okay 17:30:16 okay 17:30:22 i don't see any questions on the pad 17:30:59 on thursday we have the NRL people joining our thursday meeting for the flashflow proposal, so we have some homework to do. remember to read the spec, and the old thread where it was initially discussed in april: https://lists.torproject.org/pipermail/tor-dev/2020-April/014243.html 17:31:09 the thread is all over april, may, and june i think 17:31:40 do we have anything else? 17:32:06 * dgoulet is good 17:32:59 i'm curious about how risk is assessed and what our soak/rollout process is like, but maybe better to ask about that in #tor-project? 17:34:13 can have network wide problems, can it have usability problems, have we seen some issues coming in from this already from users that have had a chance to try it, was the code complicated, was it in a complicated subsystem :o 17:34:20 i don't think the list is complete here 17:34:30 nickm probably have a harder structure here 17:34:51 naw, it's really all "risk vs benefit plus when was it merged" 17:35:00 if you want to help make it more exact that's great :) 17:35:16 well, there were was some reference to how long something had been in master or in a release 17:35:30 is there a significant part of the network running @ master? 17:35:43 not really 17:35:56 few people run master 17:36:11 fortunately, one of those is me and another is a person that reports bug very quickly :) 17:36:23 heh 17:37:05 but with things like NSS we have even fewer people running with it on their daily tor :-/ 17:37:12 tor master* 17:37:21 yeah NSS is a ghost feature :S 17:37:57 ok, i am gonna turn off the bot folks 17:38:04 thanks for joining in 17:38:07 #endmeeting