23:15:29 #startmeeting Sponsor 31 23:15:29 Meeting started Tue Nov 5 23:15:29 2019 UTC. The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:15:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 23:15:33 We have a way to make sure it doesn't happen twice a year: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#MeetingsSchedule 23:15:44 it only works if people check it. 23:15:46 yes, i should have check as I had the same problem this morning 23:15:58 Indeed: "The primary meeting will track US daylight saving time. The canonical Patch Party time is in UTC and will not change with daylight saving time. The optional catch-up will track European daylight saving time." 23:16:10 I added an agenda to the pad 23:16:24 please check if there is anything else that we need to add 23:18:22 gaba: I think we're ok? 23:18:23 Today is the last meeting for this sponsor. We will be writing the report at the end of the month. 23:18:30 ok 23:18:45 First we could go by updates on the 3 parts that we decided to complete a few months ago 23:18:55 Oh, you don't want another meeting on 20 November? 23:19:40 I was thinking on not having other meeting but we could if people think we can do one for wrapping up 23:20:06 it might be a good idea, and help with the report. 23:20:13 ok 23:20:20 yeah i'd be ok with a wrap up meeting 23:21:16 +1 23:21:39 20th? oh it would be UTC Nov 19th 23:21:50 ok 23:21:58 2300 UTC November 19 23:22:09 I just added 14 days to my local time :-) 23:22:58 pesky bodies liking to synchronize to solar days 23:23:55 ok, should we start with updates? 23:24:19 yes 23:24:26 +1 23:25:34 So, catalyst: want to talk about docs stuff? I can talk about doxygen too. 23:25:41 ok 23:26:07 i was helping with GSoD stuff but i did start writing up some of the design goal docs. not yet ready for review 23:26:28 i haven't looked at the Doxygen work in detail but so far it looks good! 23:26:50 catalyst: do you think that is something that can be wrap up at the end of november? 23:27:05 gaba: i think so 23:27:35 when do you think it will be ready for review? 23:27:39 wrt doxygen: I've been focusing on exposing our existing code documentation and integrating it with our architectural documentation. 23:28:58 (sorry; I'll wait for catalyst to answer your question, gaba) 23:29:08 nickm: same question, is this going to be wrap up in november? 23:29:15 ack 23:29:40 we could take what we have now and call it. It will be much better by end-of-november, though. 23:29:42 gaba: looking at #29215, i think i wanted to find people to take #32207 and #32209? nickm? 23:29:56 I'm on #32209 23:30:25 I can do #32207 too if I should. 23:30:32 nickm: thanks. you're not the owner so i didn't see that in the parent ticket summary 23:30:45 * gaba just assigned that ticket to nickm 23:31:31 I'll take #32295 23:32:47 i didn't see #32295? 23:33:03 I think that's more about item 2. Are we still on 1? 23:33:14 yes 23:33:57 I will try to have drafts of the architecure stuff #32207, #32209, and the subsystems one, ready for review by monday. 23:34:11 I'll also be writing more current-architecture docs 23:34:20 gaba: i should have some drafts of my docs by next week 23:34:35 ok. thanks 23:34:46 (Sorry, I thought we were giving out all of the -must tickets) 23:34:55 is that all for the update on docs? 23:34:56 nickm: did you have a summary about #29214? 23:35:37 I think that #29214 is turning into the doxygen integration. I've moved most of the old tor-guts into doxygen; there are a few more pieces to go. 23:35:54 nickm: cool 23:35:56 mostly it has turned into our missing high-level doxygen documentation 23:36:54 * catalyst adds themselves to CC on the children of that parent ticket 23:37:50 i will go through recent doxygen stuff and make sure it has #29214 as parent. 23:38:21 any more on documentation work? 23:38:24 ok. What about 2. Modularization to do in 0.4.3 ? 23:38:30 oops, sorry 23:39:01 i think we're fine on doc stuff 23:39:15 teor, want to do the modularization update? 23:39:25 Sure! 23:39:59 Nick and I are working on modularisation in #29211 and #31851 23:40:18 I'll start with #31851 23:41:07 Yesterday I merged #32213, which turns off the major dirauth and relay config options when those modules are disabled 23:41:42 It also turns off all the relay and dirauth config validation and actions, including server pluggable transports 23:42:55 I don't know if I reported #32123 in our last meeting, that was the initial work that disables routermode when the relay module is disabled 23:43:36 Does anyone have any questions, before I move on to config.c and #29211? 23:43:58 (I'll talk about next steps at the end) 23:44:13 ok by me 23:44:24 ok 23:44:45 There are so many tickets under #29211, it's hard for me to summarise, so I'll try to do it from memory 23:45:25 Nick has done a bunch of refactoring of config.c, and we're working on #30866 right now 23:46:13 That ticket adds a per-module config object, and implements a small object for a crypto module 23:46:24 * per-module config objects 23:47:28 I think I'm done with config.c, unless Nick has anything to add? 23:47:58 I also remembered that catalyst is splitting control.c, but I haven't been involved in that much 23:48:11 In #29210 23:48:13 briefly, up till now we've all been leading up to #30866. Once that's in, we can handle config options and state variables in individual modules 23:48:47 catalyst, did you want to talk about control.c ? 23:48:48 The code is written for config and state. The new/change code is at 91% coverage, so I have a few more tests to write. 23:49:07 also I need to talk to teor about whether I should try to handle options_act_reversible in this branch, or a subsequent one. 23:49:17 I'm leaning "subsequent" since this one is getting big. 23:49:18 teor: i think #30984 is the part that's most likely to get done by end of November 23:49:20 but I want teor's thoughts there 23:50:11 teor: i'll set you to do early review on #30984 unless you don't have time for it? 23:50:20 nickm: a subsequent branch is fine 23:50:25 catalyst: that's ok 23:50:36 oh nevermind i apparently already did that 23:50:41 #30984 is the only ticket missing from #29210 23:51:35 there are other things that could go under #29210 but we can do them incrementally later 23:52:02 ok 23:52:07 teor: okay. Then let's talk for a minute after this meeting about #30866 23:52:17 catalyst: can you open a pull request? Commenting on individual lines is easier in a PR. 23:52:23 ok, anything else for modularization in november? 23:52:28 teor: ok 23:52:51 well, there's the rest of #29211 and #31851 23:53:25 So next steps on the relay modularisation are #32244, #32245, and maybe #32139 if we decide to split out the relay and dirauth config objects 23:53:39 for #29211, we can modularize more of the code. I'm going to see how much of our code I and remove the get_options() dependency from... it won't be close to 100%, but it will be progress. 23:54:05 Once #30866 is in I think we can report #29211 as "completed" from a deliverable POV 23:54:09 the rest is polishing 23:54:31 catalyst: just checking, do you expect to do more control refactoring under #29210 for sponsor 31 in November? 23:54:35 teor: I'm glad to take any of those if you assign it to me. I'm worried about stepping in your way though. 23:55:11 teor: it would be nice to do more work on #29210 but it's s31-can so the doc work should probably take priority because it's s31-must 23:55:29 Sure, that's understandable 23:55:58 nickm: #32139 would be the best for you, since you understand how to split config objects. Let's do dirauth first, because it's smaller? 23:56:01 (Maybe we should split that ticket.) 23:56:31 okay 23:57:06 under relay modularization, we do want to get to a point where there is significant amounts of code we're removing. 23:57:23 but I thik we will at the rate we're progressing. 23:57:42 teor: if you split and assign, I'll maybe be able to get to part of #32139 next week? 23:58:10 Now there's #32395 23:59:05 thanks! 23:59:52 ok, anythinge else for this? 00:00:08 But yours is #32139 00:00:54 ok 00:01:34 There are a bunch of small utility fix tickets that we can do at any time, but could be good if we have leftover time in sponsor 31: #32369, 00:01:42 let's talk for a moment after this meeting. Any more on modularization before we get to number 3? 00:02:01 err, I meant, 00:02:01 I think that's pretty much it 00:02:14 teor: let's talk for a moment after this meeting about #30866. 00:02:25 shall I talk about C style? 00:02:40 please do 00:02:55 I've run the survey and published the results at people.torproject.org/~nickm/netteam-survey-results.py 00:03:58 I tried to smmarize what I think the findings are as people.torproject.org/~nickm/netteam-survey-results-with-commentary.py 00:04:41 I've tried a few possible tools for automatically formatting our code. I don't have them set up perfectly yet, but they might give us a flavor of what it would be like to use them. Their outputs and configurations for a sample file are at http://people.torproject.org/~nickm/tor-c-style.tgz 00:04:52 I have a received a little feedback on the above 00:05:05 I'm not 100% sure of next steps 00:05:48 I could wait for more commentary 00:05:55 I could play with one/all of the formatting tools more 00:05:55 i'd still like to know what people think about my suggestion of adopting a style that's as close as possible to an existing accepted style (BSD KNF) 00:06:02 I could write a concrete style proposal. 00:07:00 I think it's a good principle to default to an existing style when we don't disagree with it strongly. 00:07:37 I think tool support for existing styles is likely to be better, too 00:08:17 i specifically asked for feedback about a concrete style suggestion along those lines and got none 00:10:11 "BSD Kernel Normal 00:10:14 Form, except with 4-column indents and a few minor changes" ? 00:10:19 nickm: yeah 00:10:45 I think the "a few minor changes" part makes it hard to respond exactly 00:11:02 I agree that our current preferred style is indeed what you describe, though 00:11:33 i envisioned "a few minor changes" meaning whatever stuff is pre-existing in our code that we have good (preferably documented) reasons for doing differently 00:11:58 Could we try a concrete proposal that lists the minor changes? 00:12:15 I'd like to try a concrete proposal including tooling. 00:12:31 Like, we should say what tooling we will use, and include a configuration file. 00:12:34 This is something that can happen later and does not have to be done this month in November, right? Is it requirement for anything else that you are all working on? 00:12:36 and describe what tooling we need to build 00:12:47 nope. Doesn't have to be done in november 00:12:57 do we have a s31 deliverable for this? 00:13:20 i don't think so 00:13:41 oh, #31177 00:13:53 we do not 00:13:54 but it's s31-can so we can continue it after November if need be 00:14:01 yes 00:14:34 it fits naturally as an overhead task within our ongoing development. I'd like to get as far as we can in november, but it's fine if we keep refining afterwards 00:14:41 ok 00:14:58 then the next step for this is to get a concrete proposal? 00:15:46 i guess, unless the team wants to talk about it more 00:16:32 ok 00:16:59 the last thing in the agenda is to bring the must-tickets that have no responsible. Right now is only #31509 00:18:16 * gaba brb - just a sec 00:18:29 teor: what do you want to do about that one? It's not truly a "must" for the funder, but from a development pov we should fix anything that's broken 00:18:33 That's a ticket for us to check manually, because "make test-stem" fails in our CI 00:19:08 We need to run "make test-stem" manually on all our changes, or fix #30901 00:19:15 test-stem doesn't work reliably for me even when run manually, so i'd rather someone else did it 00:19:17 So we can find the stem bug 00:19:24 what is for us to do in November for #31509 or #30901? 00:19:43 "Run 'make test-stem' manually after every change" 00:19:58 and fix things if they are broken 00:20:46 * gaba is back 00:20:47 I don't mind if we close the ticket, and work out another way of making sure that we run the test 00:21:15 qq: teor, does stem pass for you right now? I'm 00:21:20 catalyst: if you can reproduce some "make test-stem" failures, that would be helpful. But maybe not in November. 00:21:25 getting a big pile of errors that seem unrelated to our work. 00:21:32 * maybe not a priority in November 00:21:33 stem.SocketError: [Errno 111] Connection refused 00:21:42 +1 to closing the ticket 00:22:03 nickm: it works fine for me 00:22:20 otherwise I would have opened some more specific bugs :-) 00:23:04 teor: i've tried before, but they're often intermittent and i rarely have time to chase down all the possibilities 00:23:10 Ok, so I will close the ticket, and make sure I regularly run "make test-stem" 00:23:25 teor: thanks! I'll try to investigate more. 00:23:44 thanks 00:23:50 anything else for this meeting? 00:24:33 * catalyst is good 00:24:46 * teor is ok 00:25:03 i'm fine 00:25:14 teor: catch up with you in #tor-dev in a minute or two? or take a break first? 00:25:23 ok then. thanks! very productive on moving forward 00:25:25 Now is good 00:25:26 #endmeeting