16:59:30 #startmeeting weekly network team meeting, 20 Nov 2017 16:59:30 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:39 ahf: well, fairly close to it :) 16:59:43 hi everybody! 16:59:44 hello hello 16:59:47 18:00:00 <+ nickm> we usually do, right? 16:59:49 very much! 17:00:04 our meeting pad is here: https://pad.riseup.net/p/qSzSVJgF8QYq 17:00:13 o/ 17:00:24 hi 17:00:45 hi 17:01:21 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 hi asn, ahf, isis, dgoulet, catalyst ! 17:03:14 oh great, the thing where pad.riseup.net simply won't load :/ 17:03:27 it's a lottle slow today 17:03:42 i started using the onion some monday meetings back since that was a lot faster for me :o 17:04:52 catalyst: what's a good time tomorrow? Does during/after the patch party time work for you? 17:05:23 is this week american thanksgiving? so it's a three-day week? 17:05:25 ahf: what's a good time to talk? After this meeting? tomorrow morning (my morning) 17:05:28 isis: yup! 17:05:49 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 nice, super long weekend 17:06:00 ahf: sounds good! 17:06:06 you get in around 13-14 UTC, right? 17:06:13 nickm: the patch for the TROVE-2017-12 are on the list waiting for review :) 17:06:28 hey catalyst what's this cold cache guard state thing? 17:06:28 dgoulet: great 17:06:49 ugh my TB went all wonky because i tabbed through a sandstorm tab that wanted to reload 17:07:17 nickm: review-group-25 will delay this week if you are waiting for me on #23100/#23114... 17:07:18 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 nickm: i got #23100 done, but not #23114 yet 17:07:31 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 catalyst: we got ticket? 17:08:04 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 nickm: tomorrow during patch party probalby works 17:08:08 afaik 17:08:24 catalyst: okay! I'll make sure to be around then, unless another time would be better 17:08:47 asn: in fact as far as I can tell the only two blockers in review-group-25 are #23953 and #24119 17:08:51 and I can review #24119 17:09:28 ahf: in English it's "to kill two birds with one stone" 17:09:43 ahf: yes let's talk about that too tomorrow 17:10:05 asn: #23605, but i should update it with more detailed symptoms once i have them 17:10:10 nickm: great :-D and good to know :-S 17:10:48 ! 17:10:51 sorry folks 17:10:58 hi isabela ! 17:10:59 * dgoulet took #23953 for review 17:11:11 dgoulet: thanks! I know that's an area you know about 17:11:24 it's not very complex code, but I might have messed it up 17:11:31 i can take #23953 17:11:37 1 minute late ahf 17:11:42 argh, sorry! 17:11:45 ahf, dgoulet: you can fight for it :) 17:11:56 ahf: but how about you look at some of the consdiff tickets in 032 ? 17:12:03 then I can get them into this week's alpha 17:12:13 catalyst: oh #23605 looks like a fun bug 17:12:16 i looked at it because it looked like code that got in with consdiff, so yes 17:12:21 anything consdiff i will happily review 17:12:28 ahf: #24086 and #24099 I think 17:12:48 ok. let's start talking about highlighted issues! 17:12:50 i'll assign those two to me 17:12:57 err, set reviewer to me 17:13:06 (FYI I commented this morning on #24099) 17:13:19 ahf: did you have a question on #24362 ? 17:13:36 no? 17:13:41 ok 17:13:47 did i bold it? 17:13:54 i can take #24119 17:13:59 it got bold somehow. Did someone else have a question? 17:14:04 isis: thanks! 17:14:32 ok. On to my question 17:14:48 I started a branch for #24337 that would change how the x_free() functions in Tor work 17:15:24 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 right now tor_free() works this way, but nothing else does 17:15:53 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 what's our experience with tor_free() been like? 17:16:14 it stops lots of bugs 17:16:24 agreed 17:16:28 do static analyzers stumble over it? 17:16:35 nope. 17:16:40 it's surprisingly good at stopping some bugs 17:16:40 i think it is a good idea 17:16:42 at least, none that i've seen 17:16:55 maybe the conversion could be made into a .cocci file too? 17:16:56 occasionally tor_free() confuses people in one of two ways: 17:17:10 ahf: that is too hard for me to do in cocci :) 17:17:26 ahf: have a look at the patch so far and let me know if you think it could be cocci instead? 17:17:44 confusing thing one: a person doesn't know it's special, and writes tor_free(x); x = NULL; 17:18:07 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 but, wouldnt we have that already with tor_free() ? 17:18:37 and have we had people reporting that with tor_free() ? 17:18:54 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 ahf: yes. These are things that people get confused about when they aren't familiar with tor_free() 17:19:22 hmm 17:19:27 I don't think they are serious enough to mean we shouldn't do it, but ... 17:19:38 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 catalyst asked about our experience with tor_free, and this is the only negative aspect I can think of 17:20:24 catalyst: how would you feel about a global search-and-replace after this commit, to put all free() macros into allcaps? 17:20:38 catalyst: +1 17:21:08 nickm: global upcasing of free() macros sounds good to me 17:21:39 ok 17:21:53 (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 next topic on the pad: expectations for notice-and-higher messages 17:22:03 but keep the *function* as tor_free_(), right? :-S 17:22:13 ahf: IMO yes 17:22:14 would we have a requirement going forward that new _free()s must set x = NULL ? 17:22:20 isis: IMO yes 17:22:22 with the trailing underscore. otherwise i think i'm going to mess it up at some point 17:22:41 we already have a requirement that new X_frees() must accept X_free(NULL) 17:22:58 armadev: are you actually here? If so, I know you have opinions about log messages 17:23:30 i saw something also in nickm's update about logging in/from rust 17:23:52 isis: yes -- that's in reference to something komlo asked 17:23:59 logging from rust might want to wait until komlo gets here? 17:24:09 isis: see #23881 for background 17:24:16 i would be interested in helping if i can 17:24:31 catalyst: could you summarize the issue wrt NOTICE logs? 17:24:35 isis: awesome! 17:24:46 oh nice, komlo has been doing it :) 17:25:45 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 so, we do periodically find that we have put too many things at notice, and need to claw some back 17:27:33 we have no formal process to audit or review log messages that might be too verbose for their log level? 17:27:35 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 I don't think we do 17:27:53 armadev has a number of heuristics he can articulate reliably, but I don't remember any of them 17:28:07 the comments on each level in torlog.h are potentially somewhat helpful 17:28:31 nickm: armadev mentioned stuff in CodingStandards.md; we should probably expand that somewhat to include more advice about NOTICE 17:28:32 what do other folks think? 17:28:42 +1 17:29:24 catalyst: oh! that also references https://www.torproject.org/docs/faq#LogLevel 17:29:35 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 i feel like this has pretty great bikeshedding potential. on the other hand, improving relay operator UX is a good thing. 17:30:49 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 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 we use log_warn for lots of errors so not sure if static analysis could be helpful 17:31:38 true 17:31:43 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 catalyst: is that what you had in mind? 17:32:04 yep 17:32:31 nickm: i think that's still too much implementation detail to expect an operator to understand 17:32:59 i'll have to think a bit about alternatives 17:33:01 ok 17:33:23 obviously we don't want to say "you're not expected to understand this" in the log message 17:33:34 yeah 17:33:41 nickm: hey, i am here, in and out 17:33:51 too much to read in all my windows, trying to do it all 17:33:59 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 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 catalyst: let's ask on the mailing list to make sure we get everybody? 17:35:02 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 18 UTC is fine with me for mondays 17:35:15 asn: what about you? 17:35:24 and i think the west coast people have be here very early for the meeting 17:36:03 it is very early 17:36:06 moving it forward one hour? 17:36:09 yes 17:36:13 fine with it 17:36:19 it's gonna be a bit late 17:36:21 20:00 here 17:36:22 possibly only during standard time 17:36:29 but probs works most days 17:36:29 (non-dst) 17:36:40 we are going to collide with the browser people during the european summer time period though, no? 17:36:52 not a problem until sometime in 2018 17:36:55 unless we have the meeting track european time 17:36:58 yeah 17:37:08 I'll write an email to the network team list and see what people say 17:37:22 i was thinking we'd change according to daylight saving time in US/Europe? i think tbb-dev already does that? 17:37:28 we could 17:37:46 i think GeKo mentioned last week that their time is tracking european time and not utc 17:38:28 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 with 20 minutes left on the meeting -- 17:38:55 let's move to the items in the announcements/discussion section 17:39:06 any questions on the announcements ? 17:39:50 ok 17:39:51 * dgoulet none 17:40:15 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 Did people generally get those emails, or should isabela and I go digging? 17:40:45 I did not... 17:40:51 i didn't 17:41:01 isa and brad and i have a 5pm call scheduled today, to make new allocations 17:41:03 i haven't, but i did notice some changes on the old spreadsheet 17:41:30 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 yes, i will put that on my list of things to make sure to say 17:43:26 catalyst: when was the last time you got a suggested allocation? 17:43:40 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 armadev: i did not receive any mail from Brad that matches that description. maybe i'm not looking hard enough 17:45:32 ok. Maybe I was confused about what brad said 17:45:49 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 and remember that if you don't think the allocations make sense for you, please say something 17:46:19 hello! i thought the meeting was later. 17:46:21 sept 21 was the date he sent it to vegas-leads. no idea whether it made its way to others. 17:46:25 hi komlo ! 17:46:31 catalyst: i guess the other side is: when was the last time somebody sent you a suggested time allocation? 17:46:39 komlo: o/ 17:46:55 nickm: thanks for the feedback on #23881, i think we have a good plan for it 17:47:01 The next topic will be: "In theory, we release 0.3.2 on 15 Dec" :) 17:47:03 (my vote shouldn't count for much here, but, changing meeting times when dst changes is sure going to confuse people.) 17:47:14 In any case, we want it stable in december if we possibly can 17:47:23 So, how are we doing on that? 17:47:27 komlo: cool! 17:48:12 armadev: nothing sent to me personally that i can readily find, just updates to the spreadsheet that weren't announced 17:48:21 armadev: the idea would be to have the meting be eg 1pm eastern time US, or 6pm central europe time) 17:48:35 armadev: we'd be confused twice a year if we did that. 17:48:42 what is the status on #21969 that is the underlying issues or/and child tickets? 17:48:43 armadev: as opposed to now, when we are confused twice a year 17:49:02 dgoulet: that's a good question for asn 17:49:06 I've seen a lot of progress there 17:50:11 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 also there are the seccomp2/glibc2.26 things we've been 17:51:21 yup sandbox 17:51:32 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 can we start having a new field in proposals for the tracking/parent ticket? 17:51:52 catalyst: what problem? 17:52:06 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 dgoulet: #24228 17:52:26 catalyst: I'm not sure we even have a consensus on "it is a problem" or not 17:52:32 isis: good idea 17:52:47 It's the 10 'new' that bug me most right now 17:52:48 isis: sounds good 17:53:55 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 nickm: most of the new one have been commented on 17:54:01 nickm: catalyst: cool, i'll start doing that and modify the scripts to require it moving forward? 17:54:22 isis: If you can kludge it so that it doesn't apply to old proposals, yes please? 17:54:23 so it is either someone pick it up to do a patch or we need to continue the discussion 17:54:41 isis: huh, i wasn't aware we had scripts to run on proposals 17:54:50 nickm: yeah, i don't really want to hunt down every old ticket 17:55:21 catalyst: the "reindex.py" script regenerates 000-index.txt, and does some light linting 17:55:28 nickm: ah, thanks 17:55:31 catalyst: yep! there is proposals/reindex.py 17:55:44 oh nickm beat me to it :) 17:55:46 dgoulet: yeah, that sounds about right 17:56:23 let's all pay some attention to those new tickets, and maybe we can get them settled down soon 17:56:30 err, "new" ticket 17:56:31 s 17:56:41 oh #23856 <-- seems important to have before stable! :S 17:56:41 #23234 contains some red herrings i think 17:56:42 ok. 3 minutes left in the hour. anything else for this week? 17:56:54 dgoulet: yes I agree 17:57:01 catalyst: I think you're right 17:57:21 catalyst: it might even be more than one issue. or possibly less? :) 17:57:41 if no other issues for this week -- I'll see you on #tor-dev ! 17:57:41 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 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 not sure in this case 17:58:39 let's look more on #tor-dev 17:58:41 and with that... 17:58:46 Thanks for coming, everybody! It's great hacking with you! 17:58:49 #endmeeting