16:59:26 #startmeeting 16:59:26 Meeting started Mon May 15 16:59:26 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:37 it's the weekly network team meeting! 17:00:03 hello 17:00:07 ahf: hi hi! 17:00:13 hello! 17:00:15 status pad is here: https://pad.riseup.net/p/a03Y7qPvpfXz 17:00:41 a lot of people have already put in status info there 17:00:41 nickm: i see your revision to my discussion topic - that was what i meant actually, i just assumed that the last times would be identical to this time for stabilization period :-) 17:00:51 hey hey 17:01:12 ahf: :) 17:01:18 asn, komlo: hi! 17:01:28 catalyst, armadev: and hi to you too! 17:01:40 hi! 17:01:50 let's all look over the status reports that are there now, and ask questions? 17:02:28 asn: how bad would it be if I deferred #22006 until 0.3.2 ? Does it get us much today, or is it okay to take it later? 17:02:34 (I haven't reviewed it.) 17:02:37 (But I could.) 17:02:51 (If you'd rather have it in 0.3.1, I'll have a look) 17:03:23 i think it's fine to defer it. 17:03:31 it's code that will be used by client-side anyhow 17:03:35 ok 17:03:52 we just decoupled it to reduce merge load for 0.3.2 17:04:26 makes sense; we can take it 0.3.2 17:04:29 mikeperry: hi! 17:04:41 if you're here for the meeting, the pad is https://pad.riseup.net/p/a03Y7qPvpfXz 17:04:50 hey. my irc client got deregistered. yeah, thanks 17:06:37 Sebastian: you around? 17:07:15 draft that nickm and i wrote about bootstrap progress reporting: https://pad.riseup.net/p/OroadsO1qBgA 17:07:39 mikeperry, GeKo, linda, isabela: have a look at that maybe? 17:07:49 linda: it's the same one you already saw :) 17:07:57 oh, linda isn't here 17:08:55 so, I don't have any current questions about anybody's status reports; shall we move on to discussion? 17:09:42 very interesting doc guys L) 17:10:38 nickm: tx will do 17:10:46 catalyst: i'm on this same interview with isabela currently. i'll look at the bootstrap pad after it. 17:11:44 my main caveat with the document as it stands is that you shouldn't mistake it for a UI design. It just tries to expose info to controllers. 17:11:47 ok, on to discussion! 17:12:47 Feature freeze and stabilization. 17:13:11 We're going to stop taking 'features' in 0.3.1 later today, once we have the tests happy for prop#278 and prop#140 and I do the final merges there 17:13:27 my screen froze. missed backlog since i last spoke... 17:13:46 (i think there is a screen(1) key combo that pauses everything, and i do it accidentally) 17:13:50 historically, the stabilization periods have involved putting out alphas, fixing bugs, iterating. 17:14:12 we need to try to get everybody to spend time on bugfixing--especially people who wrote code in this release. 17:14:13 asn: (xon and xoff) 17:14:28 cool 17:14:33 ahf: thx! 17:14:36 it's fine to work on features for 0.3.2, but we deliberately hold off on merging them for long enough to put out a few alphas, to try to focus on bugfixing 17:15:09 as for what we fix: we should fix bad bugs; we should fix regressions; we _can_ fix small bugs... 17:15:32 ...we should generally weigh the importance of the bug against the risk of the fix 17:15:40 and that's the theory :) 17:15:51 anything else I missed? 17:15:57 Anything we should do differently this time? 17:17:34 it sounds good 17:17:50 I think we sometimes wind up with low-priority issues that we work on for too long, and sometimes we wind up with issues that don't get enough love. 17:17:53 so, there's that 17:18:14 we should maybe make sure that we triage aggressively during the alpha/rc process too, and make sure bugs have owners who are working on them 17:18:35 hm, one more administrative thing: where do we put our time in our reportings to TPI for this? prop140+prop278 fixes is sponsor4, but the rest? 17:19:04 so, 1: If it's fixing something that was done for a sponsor, it goes under that sponsor. 17:19:15 mm 17:19:26 if the fix itself logically fits into some sponsor's purview, it goes to them 17:19:37 otherwise it's overhead stuff 17:19:48 ack 17:19:53 armadev is pretty good at fitting work to sponsors; asking him is often fruitful 17:20:21 any more on the stabilizing topic? 17:20:30 i don't have any other questions 17:21:20 ok. next discussion topic is quick: I'm planning to put out 0.3.0.7 today, and 0.3.1.1-alpha today or tomorrow. any problems with that? 17:21:34 armadev: note that I won't be able to make a blog post till the blog's up again 17:22:23 if there are problems with this plan, please let me know. otherwise, moving on... 17:22:36 ...we need a plan for #21969, to get it fixed in 0.3.0 and 0.3.1 17:22:55 it's not likely to be ready for 0.3.1.1-alpha or 0.3.0.7 AFAICT, but getting it in after that would be good 17:23:03 should i try to come up with a plan? 17:23:09 asn: do you have a fix to try, or a set of diagnostics we should add, or what? 17:23:10 or do you want to give it a go nickm? 17:23:15 i have a fix to try 17:23:19 and a set of diagnostics that we should add 17:23:28 i dont know if my fix is The Ultimate Fix 17:23:49 asn: would they be hard or timeconsuming for you to hack? If not, let's try it 17:24:01 please base your branch on maint-0.3.0, though we'll merge it to master first 17:24:10 (the problem is that primary guards are not necessarily on the consensus or active. so sometimes we can't even get their descriptor) 17:24:39 nickm: i think if i spend a day on it, i can come up with a fix and a branch with diagnostics. 17:24:45 i can give it a go this week 17:24:46 that's promising 17:25:04 asn: sure, I'd appreciate that. I'll assign you the ticket, but please assign it back if you get stuck 17:25:13 (the alternative would be that catalyst takes it, since he seems interested in that topic) 17:25:24 catalyst: would you rather? 17:25:25 (but perhaps i can take this one since it's urgent, and catalyst can take future similar bugs) 17:25:40 or you two could work together 17:25:46 right 17:25:51 ok sounds good 17:25:56 plz assign ticket to me 17:26:05 and i will discuss with catalyst when needed 17:26:09 asn: i can do investigation but i'm proably not familiar with the implementation to make fixes quickly 17:26:09 sounds good! 17:26:39 catalyst: yep. makes sense. entrynode.c is not the most straightforward thing. 17:27:09 next topic: june hackfast. We might miss ohmygodel and isis if we take the dates we like most. I _think_ isa is asking whether we should go with the dates we already talked about, or go for the last week in june instead? 17:27:21 also mike has concerns we should talk about 17:27:37 last week of june is harder for me. i might make it work if it's necessary tho. 17:27:51 also i feel that if we do another poll with dates, we will delay more, and the first week of june won't be an option anymore 17:28:05 I think unless isis or aaron says "NOOOO" we should go with the june 12-16 plan 17:28:21 because yeah, planning is hard, and getting everybody is hard 17:28:35 but I don't think they're online right now, so let's follow-up via email 17:28:49 ack 17:28:53 too late in June starts encroaching on my moving preparations as well 17:29:30 it's also closer to the general july conf circuit. pets, sha, defcon, etc. 17:29:55 right 17:30:00 I sent a followup email 17:30:05 i think i also share mike's concerns, but i'm optimistic about the meeting 17:30:08 mikeperry: want to talk more about meeting focus risks? 17:30:31 IIUC mikeperry's concerns are that too many cooks, too little broth, too easy to distract nickm and armadev, etc? 17:30:41 well, it's also that the guard discovery issue used to be central before 17:30:42 i am probably summarizing badly 17:30:49 wheraes now we made it a network team hackfest 17:30:57 yeah 17:31:14 IIUC it is a network team hackfest, focusing on guard discovery. 17:31:29 in the same way that the last one was focusing on prop#224 HS redesign 17:31:34 though we did do some other stuff too 17:31:53 yep, but i think the people we invited dont even know that there is a gurd discovery focus 17:32:12 then we should say so on that invite list, because it is indeed guard-focused. 17:32:21 I am particularly worried about how we make the set of hard decisions on design tradeoffs that we need to. that is where we're stalled, and I'm worried we may end up still stalled there by the end 17:32:22 yes, if that is the case i'll skip out i think. i had the impression that that was the initial focus, but then the focus changed to become a focused hackfest-week 17:32:31 some of the tradeoffs are pretty fundamental to how Tor behaves 17:32:57 ahf: ah, in that case I don't know. _My opinion_ is that we should be guard-focused. 17:33:04 But we should confirm, so I'm not just dictating stuff 17:33:07 i was thinking that perhaps we could have one day that is pure guard, and the rest that is general 17:33:08 is this about #21969 or a more general guard issue? 17:33:17 catalyst: not about #21969 17:33:18 catalyst: it's about the issue behind prop#247 17:33:25 and sorry for not making this clear btw. 17:33:42 some days guard, some days TBD is also ok w me 17:33:47 FWIW, I think a network team hackfest will have great benefits in general. Perhaps as much as a guard hackfest. 17:33:51 mikeperry: do you have any ideas about how to make sure we don't leave stalled? 17:34:06 ahf: would "some days guard, some not" be useful to you? 17:34:16 yes 17:34:33 would have a lot to read up on, but i also have good time 17:34:43 if the first day is guards, i think we can do most under-discussion stuff during that day, and then split in group for the rest of the days 17:34:46 I think we need to know what the blockers are, and know that solving them takes priority over other network team stuff.. especially if new snags come up and new blockers appear 17:35:25 mikeperry: so, let me rephrase: we should make sure that well in advance of the meeting, we have our must-accomplish guard stuff enumerated, and give those tasks priority at the meeting. 17:35:50 Do you think we have approx consensus on what the blocking tasks are? 17:36:16 (and is my rephrasing ok?) 17:37:00 i think with some preparation we can identify a dozen points / design decisions that we should resolve, to proceed with proposal/implementation. 17:37:05 I am not sure. I have the list of things that have come up in the past. but there may be more. I think everyone attending needs to re-read the proposal and jot down questions, unknowns, and their own blockers, perhaps 17:37:32 but there is also the chance that say paul syverson can break the entire thing in a day and then we will need to think more. 17:37:46 ok. anybody want to draft (or help draft) an email to the list listing the stuff that people should think about and the stuff we think we should resolve? 17:37:49 that might also help with the problem of people coming in with partial information. if we only have a day, we may spend a lot of that just covering background 17:38:21 mikeperry: right. maybe that day could only be the original guard group. 17:38:22 hmmm 17:38:23 who knows, maybe drafting the thing will make the answer obvious :) 17:38:28 how about me and mikeperry think about this and come up with a plan 17:38:31 mikeperry maybe you can send those out? asking people who are coming to read over that and the proposal sounds useful 17:38:33 and send mailing list 17:39:03 asn: ok with me if it's okay with mikeperry. can we aim for early this week on that? 17:39:08 like a plan about the schedule of the hackfest, etc. 17:39:16 and yes it should be early this week... 17:39:20 please loop in isabela 17:39:24 ok 17:39:26 if it's going to be whole-hackfest scheduling 17:39:30 mikeperry: what you think? because i dont think we will solve it here 17:39:41 komlo: +1 17:40:06 enough on this topic for now? 17:40:29 if so we have one listed topic left, "bootstrapping doc". the color on the pad makes me think that's from mikeperry ? 17:40:42 yeah 17:40:52 is that about the thing catalyst and I have been working on at https://pad.riseup.net/p/OroadsO1qBgA ? 17:41:31 after a quick read of the bootstrap pad, I am concerned it might not be solving the right problem. or at least, it doesn't focus on the connectivity problem we need. 17:42:02 ok. but most nobody else has read it yet. maybe let's talk about it after the meeting? 17:42:09 the usability issues don't revolve around accurate progress reporting. they revolve around taking too long to determine if a bridge/PT is useful, and the need to test several quickly 17:42:13 ok 17:43:04 are we out of things for the group this week? If so, let's end the meeting, and talk about the bootstrapping thing on #tor-project so that the TBB team has space for their meeting here 17:43:18 sound ok? I'll send the mail with the pad contents to the list 17:43:43 cool 17:44:05 nickm: unless it turns out TBB team wants to talk about bootstrapping during their meeting too? :) 17:44:07 hearing no objections, meeting adjourned. Thanks, everybody! 17:44:16 thanjs 17:44:20 catalyst: then we can move back if we hear our names mentioned :) 17:44:23 #endmeeting