16:59:32 #startmeeting network teem meeting, weekly 16:59:32 Meeting started Mon Feb 6 16:59:32 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:42 hi all! I'm making tea, but I'll be back in <90 sec 17:00:46 back now! 17:00:55 Let's start with status reports 17:01:31 hello 17:01:32 i can go first 17:01:33 last week I merged the (I hope) final round of 030 stuff, fixed some 030 bugs, started working on proposals for more guard improvements, talked about hiring, 17:01:44 put out the 0303-alpha rlease 17:01:53 and prrobably other stuff too 17:01:58 asn: sorry; go ahead! 17:02:03 no problem 17:02:05 here i go 17:02:08 Hello. Last week I mainly did code review. I worked on various guard-related tickets; i debugged, reviewed, tested and wrote a few fixups (#21027, #21052, #21129, #21128, #16852 #21242). 17:02:13 I also merged to torspec.git all the open prop224 braches from [tor-dev]. Also wrote an HS entry for GSoC 2017 projects (fingers crossed). This week I will be working on #21334 and code reviewing various things. gNext? EOF 17:03:16 oh, I didn't talk about this week! 17:03:35 this week I want to work on hiring, sponsor4 preliminaries, more guard proposals, 030 wrap-up, and stable release backporting. 17:03:45 I have a discussion topic for the last two items. 17:03:49 EOF :) 17:04:06 I can go next: 17:04:12 o/ 17:04:35 I've got started with the sponsor4 tasks, got a single patch in for now that was unrelated to sponsor4, read the architecture notes from torguts, read up on the directory spec, and spend the weekend at FOSDEM in brussels where Ximin got me introduced to some more tor/tails people. this week will be sponsor4 and getting up to speed with getting around in the code and start getting some measurement results 17:04:41 before the "big" parts of the sponsor4 work. 17:05:01 i think that is it 17:05:06 cool 17:05:53 dgoulet / isabela: you around ? 17:05:56 hi yes! 17:06:37 so for me, kind of the usual where I worked on 030 ticket and yay alpha! Then lots of work on #20657 which will still go on this week. 17:06:56 keen 17:07:28 to manage expectations : although the 031 window is technically open, I don't see how I'm going to have much time for it for at least a few days. Is that a problem for anybody? 17:07:30 yeah that was mostly it actually :) 17:07:45 nickm: no worries here 17:08:01 (in other news I heard that isabela finally got sponsorU to accept our report and agree to send us teh money. So, woo, good job everybody) 17:09:02 hi. I am working on prop#254 implementation for sponsor2. though i think that instead of having clients send a custom state machine, they should pick from a menu that are hardcoded and/or provided in the consensus. 17:09:15 agreed, +1 17:09:37 I'm also trying to set up a collaboration with some researchers to study using it to defend against hidden service circuit fingerprinting 17:10:00 since that seems like a good way to test the waters, get a lot of benefit, and not have to pad all the time 17:10:34 mikeperry: great news 17:11:09 let me know if i can help with the research side 17:11:56 (and I'm planning on using the adaptive padding state machines for that, since they are stochastic and can also adapt to a variable traffic pattern, and that won't require waiting for prop#224) 17:12:33 mikeperry: also I think if we don't hear from armadev in a bit, then we should just fix the outstanding nick-issues and mike-issues in your previous padding branch and merge 'em in 0.3.1. 17:12:41 and we should poke armadev 17:12:48 armadev: (poke poke poke) 17:13:36 anybody else with an update? 17:13:56 Oh. One more from me: I'm visiting my inlaws from feb 20 through feb 24, so probably I won't be reliably online that week 17:15:11 so, my discussion topics were: 1) how to wrap up 030. 2) We need to put out some more backport-releases. Ick. 3. We made a list of 031 priorities. Do we believe them? Where to do on 031 triage from there? 17:15:26 4) do we need an 030 postmortem analysis thing? 17:15:34 any other topics? 17:16:27 so, for 1: what do we need to do? FWICT there are only a few tickets left, some of which we can defer 17:16:57 For the "all xxxxprop271 tickets" thing, I'm going to downgrade that to "open tickets for them as appropriate and fix up any that are absolutely critical" 17:17:14 I think we'll find out other stability things as we go 17:17:25 like, as people try it out 17:17:41 (btw, somebody should tell the authority ops that we're not afraid of people running 030 on authorities any longer) 17:17:46 any other thoughts on 030? 17:18:12 One failure-mode from the past that I want to avoid is one where we all get focused on 031, and get really slow in putting 030 out 17:18:45 ack 17:18:53 I think we are in a good state with 030 and it's a stabilize game now 17:18:55 on 2) backports -- that's a pretty huge pile of tickets in that I put on that spreadsheet 17:19:23 dgoulet: yeah 17:20:21 I'd love comments on that spreadsheet of the form "I don't think we need to backport'... " or "we actually _should_ backport...." 17:20:36 though having armadev and weasel argue about those might be the best way to get the decision-making off our shoulders 17:21:14 I kinda wish we could just drop everything before 028 17:21:24 but, old-debian 17:21:54 is it me or there seems to be only few ticket with uncertainty? 17:22:24 ah I guess all of them with "**" 17:22:31 actually not 17:22:46 the ** means "I think we backport this, but we haven't done so yet" 17:22:57 right yeah 17:23:04 But actually, there's uncertainty all over: 17:23:26 I tried to take my best guess for each item, but every backport/don't decision is tricky 17:23:52 and I dunno; maybe there's stuff we could think twice about. That's a _lot_ of backports. 17:24:06 decisions look reasonable, but yeah there are lots! and lots of releases... 17:24:25 so we have to backport #17781 (a warning) all the way to 0.2.4? 17:24:34 ah its an error not warning 17:24:38 IMO we shouldn't, actually. 17:24:45 the problem, however, is that we already backported it. 17:24:55 asn: yeah the "yes" means it's already there :P 17:24:58 It's in maint-0.2.4 .. just not released 17:25:10 I don't think we backported anything completely stupid, except in 027 17:25:29 Who actually needs to update the progress here ? 17:25:30 wahat about #18089? 17:25:46 will people run hardened tor with 0.2.4? 17:26:03 asn: well, we could declare some stuff "not supported". 17:26:14 didn't even remember that --enable-expensive-hardening worked back in 0.2.4 17:26:40 Like, we could say "--enable-expensive-hardening crashes won't get fixed in pre-0.2.9 tors." 17:26:58 or "If you want to use DNSPort, stick with 0.2.9 or later" 17:27:14 nickm: if that saves us some work i think it's not that unreasonable 17:27:19 we're already declaring some general areas "won't backport", like fixes to the seccomp2 sandbox rules. 17:28:17 (and 7unit test fixes, and compilation fixes in places that didn't compile previously, and directory authority fixes) 17:29:44 dunno. Let's try to think about what we can dump. 17:30:17 should we consider "yes" it can be dumped? (revert) ? 17:30:27 the "yes" 17:30:29 dgoulet: IMO, for 0.2.7 yes. 17:30:37 I'm hoping to revert the red "yes"ses 17:31:42 #18570 seems like a good candidate to revert 17:31:50 we don,t even backport it to 025 LTS 17:31:54 Maybe also we should think about the purpose of doing this backport stuff. Like, what do people who are "stuck on 0.2.5" actually want? And how much of that can we reasonably provide. 17:33:14 I don't think we're going to figure all that out at this meeting, but let's keep an eye on it. 17:33:39 Maybe if we can identity some stuff that's definitely-backport, that'll be something to do 17:34:02 ok, last thing: 031 planning 17:34:03 i guess the TROVE security stuff are definitely-backport 17:34:17 yeah TROVE is a no brainer imo 17:34:22 are a * 17:34:34 well maybe; some of them are only "crash on --expensive-hardening" 17:34:43 ah well 17:34:52 (err, 031 is not the last thing.) 17:36:31 idea: I think maybe 030 postmortem is more critical than 031 prep this week, since we're not currently working on any 031 stuff that is marginal. Does that seem plausbile? 17:36:34 *plausible 17:36:59 what would a 030 postmortem entail? 17:37:20 Figuring out what went well in the cycle so far, what didn't , and what we can learn that will help with 031 17:37:50 maybe today we figure out what we should investigate in that area, and try to present findings together next week? 17:38:01 I don't want to try to figure it all out in the next 20 min, but maybe we can figure out what the questions are 17:39:03 I'm not sure what they are beyond "what worked", and "what didn't" 17:39:09 maybe "what did we try? How did that go?" 17:39:17 maybe "what was unpleasant?" 17:39:24 maybe "where did the bugs come from?" 17:39:46 those sounds like good questions 17:40:16 I think we ended up with a combination of things that went well, from the top of my head: regular triage, early merge of big features 17:40:19 those were key imo 17:40:20 i see actual_points being used less 17:40:30 i see review points being used less 17:40:51 asn: yeah. That suggests a question of "what process did we use? what process did we not use? What was helpful/unhelpful there?" 17:41:12 what is actual_points and review_points? scoring system for reviews? 17:41:17 I thought that having "points" was useful at the start for triage and planning... but I'm less convinced about that 17:41:28 same 17:41:35 ahf: a point is a day of work 17:41:41 ahf: "points" is a unit of work, with 1 point approximately 1 day 17:41:42 I kind of never use that but maybe isabela has a different opinion on that for her planification 17:41:43 ahf: with the "Points" field you estimate how many days of work it's gonna take 17:41:50 ah, i see. thanks 17:41:56 yeah, maybe they're really useful for her. 17:41:57 ahf: with the "Actual points" field you actually say how much time it took you 17:42:17 yes. good idea to have both. 17:42:43 ahf: 6 is the max meaning 6 days but we put that for things that can take us weeks also 17:42:44 * the bug triage rotation thing kinda works out 17:43:12 the reason that worked out for me ^ is because I ended up actually knowing the state of "tor" in much greater depth 17:43:16 dgoulet: okay, good to know - i assume you don't write 6 for actual_points then once the task is over? 17:43:20 ok. so heree's my quick postmortem plan. everybody send me questions. I'll circulate questions to the team. Responses not required, but mainly intended as a way for everybody else to raise considerations. 17:43:23 and thus prioritising was much much easier to work out 17:43:34 we talk more next week. Does that sound like a good plan? 17:43:36 k 17:43:39 ack 17:44:22 woo 17:44:49 any other topics for this week? Else I'll refill my tea, extract my to-do items from the above, and hang out for a bit longer! 17:45:00 031 17:45:18 ah. for 031 I was suggesting: 17:45:25 17:36 < nickm> idea: I think maybe 030 postmortem is more critical than 031 prep this week, since we're not currently working on any 031 stuff that is marginal. Does that seem plausbile? 17:45:35 ah yes ok sure 17:46:21 any objections to #endmeeting? 17:46:26 nickm: quick question 17:46:29 yo! 17:46:33 asn,dgoulet: I don't suppose either of you has a tool that might be easy to adapt to gathering information on per-hop latencies for hidden service circuit construction of various types? 17:46:57 nickm: bah nvm 17:47:02 mikeperry: not me 17:47:04 ok :) 17:47:13 i'd like to help out with some of the backporting tasks. i think that would be good for me to get a slight better understanding of our release process and how we deal with all of that 17:47:29 ahf: cool! Let's talk about that in a few minutes? I'll be around for a while 17:47:29 (what about just looking at info logs with logtimegranularity 1?) 17:47:31 so assign things to me, or i can pick something from the sheet when the decisions on what to backport have been made 17:47:34 yes! 17:47:39 #endmeeting