16:59:30 <nickm> #startmeeting weekly network team meeting, 20 Nov 2017
16:59:30 <MeetBot> Meeting started Mon Nov 20 16:59:30 2017 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:39 <nickm> ahf: well, fairly close to it :)
16:59:43 <nickm> hi everybody!
16:59:44 <asn> hello hello
16:59:47 <ahf> 18:00:00 <+       nickm> we usually do, right?
16:59:49 <ahf> very much!
17:00:04 <nickm> our meeting pad is here: https://pad.riseup.net/p/qSzSVJgF8QYq
17:00:13 <isis> o/
17:00:24 <dgoulet> hi
17:00:45 <catalyst> hi
17:01:21 <nickm> okay!  As usual, please finish your updates on the pad (if they're not done yet) , and then take a few moments to read other people's updates, and boldface anything that you want to talk about (in your updates or anyone else's)
17:01:39 <nickm> hi asn, ahf, isis, dgoulet, catalyst !
17:03:14 <isis> oh great, the thing where pad.riseup.net simply won't load :/
17:03:27 <nickm> it's a lottle slow today
17:03:42 <ahf> i started using the onion some monday meetings back since that was a lot faster for me :o
17:04:52 <nickm> catalyst: what's a good time tomorrow? Does during/after the patch party time work for you?
17:05:23 <isis> is this week american thanksgiving? so it's a three-day week?
17:05:25 <nickm> ahf: what's a good time to talk?  After this meeting? tomorrow morning (my morning)
17:05:28 <nickm> isis: yup!
17:05:49 <ahf> nickm: let's do tomorrow morning for you? sarah will come home after this meeting and i think she expects me to have food ready for her
17:05:58 <isis> nice, super long weekend
17:06:00 <nickm> ahf: sounds good!
17:06:06 <ahf> you get in around 13-14 UTC, right?
17:06:13 <dgoulet> nickm: the patch for the TROVE-2017-12 are on the list waiting for review :)
17:06:28 <asn> hey catalyst what's this cold cache guard state thing?
17:06:28 <nickm> dgoulet: great
17:06:49 <catalyst> ugh my TB went all wonky because i tabbed through a sandstorm tab that wanted to reload
17:07:17 <asn> nickm: review-group-25 will delay this week if you are waiting for me on #23100/#23114...
17:07:18 <ahf> nickm: should we get "two flies with one smack" (don't know if that is a danish thing to say) and talk about wakeups as well as CPU profiling? the wakeup tooling is a lot more terrible than the cpu profling tooling
17:07:18 * nickm looks forward to the new stable firefox stuff getting into TB :)
17:07:27 <asn> nickm: i got #23100 done, but not #23114 yet
17:07:31 <catalyst> asn: when the client clock is in the future, tor sits there trying to build circuits with an uninitialized guard state that can never get initialized
17:07:47 <asn> catalyst: we got ticket?
17:08:04 <nickm> asn: that's okay.  Those already got at least one review during review-group-25, so they don't block the review group
17:08:05 <catalyst> nickm: tomorrow during patch party probalby works
17:08:08 <nickm> afaik
17:08:24 <nickm> catalyst: okay!  I'll make sure to be around then, unless another time would be better
17:08:47 <nickm> asn: in fact as far as I can tell the only two blockers in review-group-25 are #23953 and #24119
17:08:51 <nickm> and I can review #24119
17:09:28 <nickm> ahf: in English it's "to kill two birds with one stone"
17:09:43 <nickm> ahf: yes let's talk about that too tomorrow
17:10:05 <catalyst> asn: #23605, but i should update it with more detailed symptoms once i have them
17:10:10 <ahf> nickm: great :-D and good to know :-S
17:10:48 <isabela> !
17:10:51 <isabela> sorry folks
17:10:58 <nickm> hi isabela !
17:10:59 * dgoulet took #23953 for review
17:11:11 <nickm> dgoulet: thanks! I know that's an area you know about
17:11:24 <nickm> it's not very complex code, but I might have messed it up
17:11:31 <ahf> i can take #23953
17:11:37 <dgoulet> 1 minute late ahf
17:11:42 <ahf> argh, sorry!
17:11:45 <nickm> ahf, dgoulet: you can fight for it :)
17:11:56 <nickm> ahf: but how about you look at some of the consdiff tickets in 032 ?
17:12:03 <nickm> then I can get them into this week's alpha
17:12:13 <isis> catalyst: oh #23605 looks like a fun bug
17:12:16 <ahf> i looked at it because it looked like code that got in with consdiff, so yes
17:12:21 <ahf> anything consdiff i will happily review
17:12:28 <nickm> ahf: #24086 and #24099 I think
17:12:48 <nickm> ok. let's start talking about highlighted issues!
17:12:50 <ahf> i'll assign those two to me
17:12:57 <ahf> err, set reviewer to me
17:13:06 <dgoulet> (FYI I commented this morning on #24099)
17:13:19 <nickm> ahf: did you have a question on #24362 ?
17:13:36 <ahf> no?
17:13:41 <nickm> ok
17:13:47 <ahf> did i bold it?
17:13:54 <isis> i can take #24119
17:13:59 <nickm> it got bold somehow.  Did someone else have a question?
17:14:04 <nickm> isis: thanks!
17:14:32 <nickm> ok.  On to my question
17:14:48 <nickm> I started a branch for #24337 that would change how the x_free() functions in Tor work
17:15:24 <nickm> briefly, it would turn every x_free() function into a new x_free_() function, and create a new x_free() macro that calls x_free_(ptr); (ptr) = NULL;
17:15:33 <nickm> right now tor_free() works this way, but nothing else does
17:15:53 <nickm> I'm wondering if anybody thinks this is a bad idea -- I'd like to know before I implement much more of it
17:16:08 <catalyst> what's our experience with tor_free() been like?
17:16:14 <nickm> it stops lots of bugs
17:16:24 <asn> agreed
17:16:28 <catalyst> do static analyzers stumble over it?
17:16:35 <nickm> nope.
17:16:40 <asn> it's surprisingly good at stopping some bugs
17:16:40 <ahf> i think it is a good idea
17:16:42 <nickm> at least, none that i've seen
17:16:55 <ahf> maybe the conversion could be made into a .cocci file too?
17:16:56 <nickm> occasionally tor_free() confuses people in one of two ways:
17:17:10 <nickm> ahf: that is too hard for me to do in cocci :)
17:17:26 <nickm> ahf: have a look at the patch so far and let me know if you think it could be cocci instead?
17:17:44 <nickm> confusing thing one:  a person doesn't know it's special, and writes tor_free(x); x = NULL;
17:18:07 <nickm> confusing thing one-prime:  a person doesn't know it's special, and sees a case that _would_ be a bug if tor_free() did not set x = NULL, and reports it as a bug.
17:18:30 <ahf> but, wouldnt we have that already with tor_free() ?
17:18:37 <ahf> and have we had people reporting that with tor_free() ?
17:18:54 <nickm> confusing thing two: they try to use tor_free() some place that the compiler won't let them (e.g., as a function pointer, or on a non-lvalue) and they don't understand the error they see.
17:19:11 <nickm> ahf:  yes.  These are things that people get confused about when they aren't familiar with tor_free()
17:19:22 <ahf> hmm
17:19:27 <nickm> I don't think they are serious enough to mean we shouldn't do it, but ...
17:19:38 <catalyst> nickm: i think a macro that looks like a function but can't be implemented as a function ought to be clearly identifiable as such, maybe by using all-caps
17:19:49 <nickm> catalyst asked about our experience with tor_free, and this is the only negative aspect I can think of
17:20:24 <nickm> catalyst: how would you feel about a global search-and-replace after this commit, to put all free() macros into allcaps?
17:20:38 <isis> catalyst: +1
17:21:08 <catalyst> nickm: global upcasing of free() macros sounds good to me
17:21:39 <nickm> ok
17:21:53 <catalyst> (there are a few function-like standard library macros that are lowercase and can't be implemented as functions but their functionality is obviously Kinda Weird)
17:22:01 <nickm> next topic on the pad: expectations for notice-and-higher messages
17:22:03 <ahf> but keep the *function* as tor_free_(), right? :-S
17:22:13 <nickm> ahf: IMO yes
17:22:14 <isis> would we have a requirement going forward that new _free()s must set x = NULL ?
17:22:20 <nickm> isis: IMO yes
17:22:22 <ahf> with the trailing underscore. otherwise i think i'm going to mess it up at some point
17:22:41 <nickm> we already have a requirement that new X_frees() must accept X_free(NULL)
17:22:58 <nickm> armadev: are you actually here?  If so, I know you have opinions about log messages
17:23:30 <isis> i saw something also in nickm's update about logging in/from rust
17:23:52 <nickm> isis: yes -- that's in reference to something komlo asked
17:23:59 <catalyst> logging from rust might want to wait until komlo gets here?
17:24:09 <nickm> isis:  see #23881 for background
17:24:16 <isis> i would be interested in helping if i can
17:24:31 <nickm> catalyst: could you summarize the issue wrt NOTICE logs?
17:24:35 <nickm> isis: awesome!
17:24:46 <isis> oh nice, komlo has been doing it :)
17:25:45 <catalyst> nickm: Sebastian said he and other relay operators found NOTICE logs too verbose and refer to things that aren't readily understood without knowledge of the code. his example was scheduler selection
17:26:53 <nickm> so, we do periodically find that we have put too many things at notice, and need to claw some back
17:27:33 <catalyst> we have no formal process to audit or review log messages that might be too verbose for their log level?
17:27:35 <nickm> Since notice-and-higher is the default level, we should make sure that NOTICE logs are understandable, though reasonable people will of course sometimes disagree about what that means
17:27:40 <nickm> I don't think we do
17:27:53 <nickm> armadev has a number of heuristics he can articulate reliably, but I don't remember any of them
17:28:07 <nickm> the comments on each level in torlog.h are potentially somewhat helpful
17:28:31 <catalyst> nickm: armadev mentioned stuff in CodingStandards.md; we should probably expand that somewhat to include more advice about NOTICE
17:28:32 <nickm> what do other folks think?
17:28:42 <nickm> +1
17:29:24 <nickm> catalyst: oh!  that also references https://www.torproject.org/docs/faq#LogLevel
17:29:35 <catalyst> one tradeoff is there's some global state info that probably should get logged at NOTICE for ease of debugging. we should have some way to label it as "you're not expected to understand this without having read the code"
17:30:08 <asn> i feel like this has pretty great bikeshedding potential. on the other hand, improving relay operator UX is a good thing.
17:30:49 <ahf> i think it's a good idea to get it written down in one of the hacking docs, but catching it in a review is probably more important? i don't know if our whitespace checking script could have a warning for things that have not been commited yet (things that show up git diff) that can say "Do you really think this should be notice or?"
17:31:26 <nickm> catalyst: eg "[NOTICE] Tor is using the frobozz magic scheduler. It's a comparatively new feature, so please let us know you're using it if anything goes wrong."
17:31:26 <asn> we use log_warn for lots of errors so not sure if static analysis could be helpful
17:31:38 <ahf> true
17:31:43 <catalyst> ahf: it would be great to have an automated way to help review new log messages but stuff needs human review ultimately
17:32:03 <nickm> catalyst: is that what you had in mind?
17:32:04 <ahf> yep
17:32:31 <catalyst> nickm: i think that's still too much implementation detail to expect an operator to understand
17:32:59 <catalyst> i'll have to think a bit about alternatives
17:33:01 <nickm> ok
17:33:23 <catalyst> obviously we don't want to say "you're not expected to understand this" in the log message
17:33:34 <nickm> yeah
17:33:41 <armadev> nickm: hey, i am here, in and out
17:33:51 <armadev> too much to read in all my windows, trying to do it all
17:33:59 <nickm> armadev: hi!  We're wrapping this topic up, but maybe on #tor-dev you'd like to talk about what's a good NOTICE message :)
17:34:24 <nickm> catalyst: as for the meeting time, I'm okay moving the meeting, but we should ask other people, particularly people in Europe
17:34:37 <nickm> catalyst: let's ask on the mailing list to make sure we get everybody?
17:35:02 <catalyst> nickm: it's not a big deal for me personally but i recall some people asking about it last week and i'm not sure we polled the list
17:35:09 <ahf> 18 UTC is fine with me for mondays
17:35:15 <nickm> asn: what about you?
17:35:24 <ahf> and i think the west coast people have be here very early for the meeting
17:36:03 <isis> it is very early
17:36:06 <asn> moving it forward one hour?
17:36:09 <nickm> yes
17:36:13 <asn> fine with it
17:36:19 <asn> it's gonna be a bit late
17:36:21 <asn> 20:00 here
17:36:22 <nickm> possibly only during standard time
17:36:29 <asn> but probs works most days
17:36:29 <nickm> (non-dst)
17:36:40 <ahf> we are going to collide with the browser people during the european summer time period though, no?
17:36:52 <ahf> not a problem until sometime in 2018
17:36:55 <nickm> unless we have the meeting track european time
17:36:58 <nickm> yeah
17:37:08 <nickm> I'll write an email to the network team list and see what people say
17:37:22 <catalyst> i was thinking we'd change according to daylight saving time in US/Europe? i think tbb-dev already does that?
17:37:28 <nickm> we could
17:37:46 <ahf> i think GeKo mentioned last week that their time is tracking european time and not utc
17:38:28 <nickm> okay.  I'll write this up as an email now or right afte rthe meeting, and we'll see if anybody is strongly yes/no
17:38:45 <nickm> with 20 minutes left on the meeting --
17:38:55 <nickm> let's move to the items in the announcements/discussion section
17:39:06 <nickm> any questions on the announcements ?
17:39:50 <nickm> ok
17:39:51 * dgoulet none
17:40:15 <nickm> So, I hear that Brad has sent out another set of time allocations to people some time over the last month or so
17:40:29 <nickm> Did people generally get those emails, or should isabela and I go digging?
17:40:45 <dgoulet> I did not...
17:40:51 <ahf> i didn't
17:41:01 <armadev> isa and brad and i have a 5pm call scheduled today, to make new allocations
17:41:03 <catalyst> i haven't, but i did notice some changes on the old spreadsheet
17:41:30 <nickm> armadev: ok.  Could you please add an agendum of "make sure these allocations are reported to the people who need them, asap" ?
17:41:48 * isabela is very distracted right now with deadline stuff - please ping me if you need anything, sorry folks
17:43:08 <armadev> yes, i will put that on my list of things to make sure to say
17:43:26 <armadev> catalyst: when was the last time you got a suggested allocation?
17:43:40 <armadev> that is, there was one that i saw go out in octoberish, and i wonder if that made its way to you
17:44:25 <catalyst> armadev: i did not receive any mail from Brad that matches that description. maybe i'm not looking hard enough
17:45:32 <nickm> ok. Maybe I was confused about what brad said
17:45:49 <nickm> we should have new allocations soon though, according to armadev, so let's make sure to keep an eye out for those
17:46:08 <nickm> and remember that if you don't think the allocations make sense for you, please say something
17:46:19 <komlo> hello! i thought the meeting was later.
17:46:21 <armadev> sept 21 was the date he sent it to vegas-leads. no idea whether it made its way to others.
17:46:25 <nickm> hi komlo !
17:46:31 <armadev> catalyst: i guess the other side is: when was the last time somebody sent you a suggested time allocation?
17:46:39 <isis> komlo: o/
17:46:55 <komlo> nickm: thanks for the feedback on #23881, i think we have a good plan for it
17:47:01 <nickm> The next topic will be: "In theory, we release 0.3.2 on 15 Dec" :)
17:47:03 <armadev> (my vote shouldn't count for much here, but, changing meeting times when dst changes is sure going to confuse people.)
17:47:14 <nickm> In any case, we want it stable in december if we possibly can
17:47:23 <nickm> So, how are we doing on that?
17:47:27 <nickm> komlo: cool!
17:48:12 <catalyst> armadev: nothing sent to me personally that i can readily find, just updates to the spreadsheet that weren't announced
17:48:21 <nickm> armadev: the idea would be to have the meting be eg 1pm eastern time US, or 6pm central europe time)
17:48:35 <nickm> armadev: we'd be confused twice a year if we did that.
17:48:42 <dgoulet> what is the status on #21969 that is the underlying issues or/and child tickets?
17:48:43 <nickm> armadev: as opposed to now, when we are confused twice a year
17:49:02 <nickm> dgoulet: that's a good question for asn
17:49:06 <nickm> I've seen a lot of progress there
17:50:11 <dgoulet> apart from that I don't see anything "oh shit must go in soooooon" but we also have intersting things stalled like #24228
17:51:07 <nickm> also there are the seccomp2/glibc2.26 things we've been
17:51:21 <dgoulet> yup sandbox
17:51:32 <catalyst> dgoulet: i think we have some disagreement about how much of a problem that's being in practice. do we have any good way to estimate/measure?
17:51:41 <isis> can we start having a new field in proposals for the tracking/parent ticket?
17:51:52 <dgoulet> catalyst: what problem?
17:52:06 <nickm> on trac right now, we have 2 accepted tickets (dgoulet); 4 assigned tickets (asn, isis, catalyst, dgoulet) ; and 10 "new" with no owner
17:52:08 <catalyst> dgoulet: #24228
17:52:26 <dgoulet> catalyst: I'm not sure we even have a consensus on "it is a problem" or not
17:52:32 <nickm> isis: good idea
17:52:47 <nickm> It's the 10 'new' that bug me most right now
17:52:48 <catalyst> isis: sounds good
17:53:55 <nickm> here is the standard too-big trac URL: https://trac.torproject.org/projects/tor/query?status=needs_information&status=needs_revision&status=merge_ready&status=reopened&status=needs_review&status=assigned&status=new&status=accepted&group=status&milestone=Tor%3A+0.3.2.x-final
17:53:56 <dgoulet> nickm: most of the new one have been commented on
17:54:01 <isis> nickm: catalyst: cool, i'll start doing that and modify the scripts to require it moving forward?
17:54:22 <nickm> isis: If you can kludge it so that it doesn't apply to old proposals, yes please?
17:54:23 <dgoulet> so it is either someone pick it up to do a patch or we need to continue the discussion
17:54:41 <catalyst> isis: huh, i wasn't aware we had scripts to run on proposals
17:54:50 <isis> nickm: yeah, i don't really want to hunt down every old ticket
17:55:21 <nickm> catalyst: the "reindex.py" script regenerates 000-index.txt, and does some light linting
17:55:28 <catalyst> nickm: ah, thanks
17:55:31 <isis> catalyst: yep! there is proposals/reindex.py
17:55:44 <isis> oh nickm beat me to it :)
17:55:46 <nickm> dgoulet: yeah, that sounds about right
17:56:23 <nickm> let's all pay some attention to those new tickets, and maybe we can get them settled down soon
17:56:30 <nickm> err, "new" ticket
17:56:31 <nickm> s
17:56:41 <dgoulet> oh #23856 <-- seems important to have before stable! :S
17:56:41 <catalyst> #23234 contains some red herrings i think
17:56:42 <nickm> ok.  3 minutes left in the hour.  anything else for this week?
17:56:54 <nickm> dgoulet: yes I agree
17:57:01 <nickm> catalyst: I think you're right
17:57:21 <nickm> catalyst: it might even be more than one issue. or possibly less? :)
17:57:41 <nickm> if no other issues for this week -- I'll see you on #tor-dev !
17:57:41 <catalyst> i.e., "No route to host" logged in a bootstrap status message is likely from only the last relay it tried to talk to and isn't representative of the actual problem
17:58:31 <nickm> catalyst: yeah.  Sometimes the right thing to do for a bug we can't figure out is to improve the diagnostic message, and then leave the bug open to see what it says next time
17:58:35 <nickm> not sure in this case
17:58:39 <nickm> let's look more on #tor-dev
17:58:41 <nickm> and with that...
17:58:46 <nickm> Thanks for coming, everybody!  It's great hacking with you!
17:58:49 <nickm> #endmeeting