16:59:00 <ahf> #startmeeting network team meeting october 5
16:59:00 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:03 <ahf> hello everybody
16:59:04 <nickm> hi ahf!
16:59:08 <gaba> hi
16:59:10 <ahf> pad is at https://pad.riseup.net/p/tor-netteam-2020.1-keep
16:59:38 <asn> (sec at another meeting. will join right after.)
16:59:43 <ahf> oki
17:00:12 <dgoulet> o/
17:00:15 <ahf> o/
17:00:16 <ahf> ok
17:00:28 <ahf> let's start with our board: https://gitlab.torproject.org/groups/tpo/core/-/boards
17:01:05 <mikeperry> o/
17:02:09 <ahf> are everybody OK with the state ?
17:02:17 <ahf> state of the board*
17:02:51 <ahf> :o
17:02:57 <dgoulet> doesn't look in any emergency situation ;)
17:02:58 <nickm> 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 <ahf> ok
17:03:55 <ahf> reviewers looks good, except for tor!165
17:04:03 <ahf> i can grab that
17:04:09 <nickm> it is very small
17:04:11 <gaba> there is one issue in the doing in the board that has noone assigned
17:04:20 <gaba> #40073
17:04:42 <nickm> looks it it got reopened for backport; that should be "needs review"
17:05:16 <ahf> fixing
17:05:33 <ahf> done
17:05:53 <ahf> ok, 0.4.4 status
17:07:09 <nickm> oh, this is our first-meeting-of-the-month. Should we be talking about backports?
17:07:16 <ahf> yes
17:07:18 <ahf> we should
17:07:44 <ahf> we need to figure out how we handle this
17:07:59 <ahf> 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 <ahf> i guess it's the same goal we have here?
17:08:09 <ahf> and assign who does the backport work
17:09:03 <ahf> 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 <ahf> 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 <nickm> i think so.
17:10:37 <ahf> how do we prefer to do this? looks like there are 17
17:11:13 <nickm> 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 <nickm> the risk v benefit assessment is the most important part IMO
17:11:38 <ahf> i don't think you should be doing them all
17:11:53 <nickm> ok w me
17:12:18 <ahf> tor#40098 seems low risk
17:12:50 <ahf> tor#32673 was one we were a bit worried about at one point i think?
17:12:55 <ahf> but maybe it has baked for a while now
17:13:54 <nickm> 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 <ahf> tor#33131 was marked medium-risk last time
17:14:18 <ahf> ok, so the nss one is a high-risk one
17:14:39 <ahf> there is a few sandbox related ones
17:15:21 <nickm> maybe we should come into this with all the tickets labeled with risk/benefit/when-merged?
17:15:31 <nickm> asn, dgoulet: any thoughts about how we should be doing this?
17:16:06 <ahf> i think they should be labeded yes
17:17:23 <dgoulet> 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 <dgoulet> (I mean, they've all been "baking" for a while...)
17:17:53 <nickm> i think we're trying to feel our way toward a process
17:18:04 <ahf> tor#33880 doesn't seem that scary
17:18:27 <dgoulet> 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 <ahf> i think the NSS one we are unsure about?
17:19:04 <dgoulet> but that one is not upstream?
17:19:28 <nickm> hm?
17:20:04 <ahf> what do you mean upstream here?
17:20:06 <ahf> in a release?
17:20:09 <dgoulet> let me rephrase
17:20:30 <dgoulet> the question here is to assess *IF* we should backport right?
17:20:49 <ahf> or if it needs to wait a bit with being backported because we don'th ave confidence in it yet
17:20:58 <ahf> if it hasn't been brewing for long enough
17:21:27 <dgoulet> yeah I have NO metrics whatsoever to assess that level of confidence
17:21:54 <ahf> i think we mostly have time and number of bugs coming in
17:21:57 <dgoulet> 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 <ahf> okay, so instead you think that looking at the list and *removing* items we wont need to backport is smarter/better?
17:23:11 <dgoulet> correct
17:23:25 <ahf> is there anything on the list *other* than the NSS one that we want to wait with?
17:23:45 <nickm> yeah, hang on
17:24:06 <nickm> tor#27194
17:24:14 <nickm> it's only been merged to master, not to a stable release.
17:24:17 <nickm> and the benefit is really small
17:24:49 <ahf> if the benefit is small, then do we want to do it even if it comes out in a stable release? :-)
17:24:56 <dgoulet> my two cents, I would be fine with all of those being backported
17:25:52 <nickm> IMO we should still go over the list and do the cost/benefit assessment
17:26:44 <ahf> 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 <nickm> but I think backporting should be fine
17:28:01 <nickm> 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 <ahf> ok
17:28:57 <nickm> then we can see if anything's nontrivial to backport
17:29:00 <nickm> and see what's next
17:29:07 <nickm> i'll add that to my todo for the week
17:29:33 <ahf> ok, and pick network-team if/when we need to look?
17:29:39 <nickm> okay
17:30:16 <ahf> okay
17:30:22 <ahf> i don't see any questions on the pad
17:30:59 <ahf> 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 <ahf> the thread is all over april, may, and june i think
17:31:40 <ahf> do we have anything else?
17:32:06 * dgoulet is good
17:32:59 <jnewsome> 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 <ahf> 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 <ahf> i don't think the list is complete here
17:34:30 <ahf> nickm probably have a harder structure here
17:34:51 <nickm> naw, it's really all "risk vs benefit plus when was it merged"
17:35:00 <nickm> if you want to help make it more exact that's great :)
17:35:16 <jnewsome> well, there were was some reference to how long something had been in master or in a release
17:35:30 <jnewsome> is there a significant part of the network running @ master?
17:35:43 <dgoulet> not really
17:35:56 <dgoulet> few people run master
17:36:11 <dgoulet> fortunately, one of those is me and another is a person that reports bug very quickly :)
17:36:23 <jnewsome> heh
17:37:05 <ahf> but with things like NSS we have even fewer people running with it on their daily tor :-/
17:37:12 <ahf> tor master*
17:37:21 <dgoulet> yeah NSS is a ghost feature :S
17:37:57 <ahf> ok, i am gonna turn off the bot folks
17:38:04 <ahf> thanks for joining in
17:38:07 <ahf> #endmeeting