18:29:35 #startmeeting 18:29:35 Meeting started Wed Nov 11 18:29:35 2015 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:29:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:29:37 this time for sure! 18:29:42 hi all! 18:29:59 hello! 18:30:06 opa 18:30:10 ok I have a few minutes to update you all guys from the R land 18:30:33 hi 18:30:41 thanks for the highlight 18:30:57 woo 18:31:38 so one of the good news we had here (SponsorR meeting) is that our funder asked us to actively fix HS issueS which is ultimately 224 so we expect to move our R effort more towards 224 and accepted by our funder :) 18:31:54 great! 18:32:11 can we make sure that it's broken up into pieces, that we have them on the roadmap, and that every piece has a corresponding ticket? :) 18:32:18 I've worked with Rob here also on improving our instrumentation of tor useful for shadow and kist and crypto 18:32:23 nickm: we almost have all of this already :) 18:32:30 nickm: we did that after/during Berlin meeting 18:32:37 nickm: more is required but we have a baseline 18:33:07 we have OnionPerf that is almost ready to go in full on production that will measure on a regular basis HS performance 18:33:32 so that's a rough summary on my side that is linked to core tor. thanks! 18:33:57 (possible I have to step out during the meeting) 18:35:06 so, I've been running around like crazy trying to interview ed candidates and do press response and and and and and, so there's distractions between me and the code. 18:35:19 mostly I've been focusing on Stuff That Already Had A Patch before we forked 0.2.8 18:35:27 and I've been doing the 0.2.7 release notes in prep for a new stable 18:35:53 Here are the tickets with old patches: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~pre028-patch 18:36:28 here are the tickets for this month. I think that unless more people take tickets, some of this stuff will slip at this rate. https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorCoreTeam201511 . I can't do it all. 18:37:09 hi meeting (again)! 18:37:23 hi hi 18:38:30 who's next? 18:39:13 * isabela can go 18:39:42 I am working on this https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam finally 18:40:04 i've mostly been digging into guard algorithms recently and writing up a summary document describing the various options we've had proposed 18:40:53 I plan on having roadmaps from dev meeting there etc I am also planning on keeping monthly tasks that (tickets from our tag TorCoreTeam201511) etc.. will send out an update when I am done (hopefully eow) 18:41:00 i recently heard from sergey bratus of dartmouth about a master's student looking to do a Tor-related thesis, so i had thought of sending that along when finished and suggesting "figure something smart out about guards" 18:41:43 I'm hoping we can make enough progress on the guard stuff this month that we know what algorithm we will do in 0.2.8, and we have a simulation of it in the guardsim code. Have you had a chance to look at that and at prop#259 yet? 18:42:00 another thing is that I iwll try to schedule kind of 1:1s for me and nickm to meet with ppl in the coming weeks. 18:42:23 well, 1:2s if it's you and me. :) 18:43:02 but yeah, sounds good. We should try to make sure we check in with everybody in an organized way once or twice a year to see how everybody's doing and where everybody wants to head. 18:43:10 isabela: what is the purpose of those 1on1 ? 18:43:18 ah that explains it :) 18:44:00 hehe 18:44:28 yes, reading that 18:44:46 great. I'm hoping that we can get something in guardsim that's good enough that we're comfortable translating it to c 18:45:32 I finished folding in updates from the dev meeting discussion to Prop#247 and sent it to tor-dev. I began work on the issues that I felt blocked #16861 (listed in https://trac.torproject.org/projects/tor/ticket/16861#comment:19). 18:46:09 After I finish the #16861 blockers, I'll probably want help with my set of questions in comment 18 on the ticket 18:47:50 but more questions might come up, and answering those probably requires a full code review anyway, so no rush 18:50:39 ah 18:50:57 oh, I also tagged #8453 for me for this month 18:51:00 one more thing, please keep https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorCoreTeam201511 18:51:03 updated 18:51:04 :) 18:51:22 isabela: yeah, I mis-tagged my tickets earlier. should be fixed now 18:51:29 mikeperry: tx! 18:51:55 I want to write a proposal for #8453 this month at the very least, since we will want to account for padding in the load balancing equations, most likely 18:54:14 ln5: are you going to be able to do #17271 this month, do you think? 18:54:22 Andybody else around for this meeting today? :) 18:55:51 so, I have a discussion topic, and it's one of the perennial ones. 18:56:00 it's : how do we make sure proposals and patches get reviewed? 18:56:11 everybody (me included) would rather write code than review code. 18:57:04 and this leads to backlogs. 18:57:09 and unreviewed proposals 18:57:11 and sadness 18:57:25 anybody got an idea for how we can try to get more people reviewing? 18:57:59 I could de-prioritize review of any work by people who haven't reviewed at least one patch in the past week.... but that seems like a jerk move. 18:58:15 tomorrow asn will try the first patch workshop for HS 18:58:45 we can have a 'review day' in the week 19:00:00 would people do that? Would everybody/anybody be willing to commit to at least one day of review per week, so long as there's backlog? 19:01:06 I am not sure my code review would be as good as yours, nick. at least with respect to tor style and idiomatic consistency, etc.. not sure how to handle issues like that 19:01:39 well, for Tor code written by nick, there are these choices: 19:01:42 - nobody reviews it 19:01:53 - somebody who knows the code less well than nick reviews it :) 19:02:06 - we don't merge itl. 19:02:08 *it 19:02:16 and for non-nick code, we could go with: 19:02:23 - we merge only what nick can review 19:02:37 - other people review code too and help get it merged 19:02:44 - we merge code without review :) 19:02:55 ! 19:02:56 what other orgs tend to do is designate a few people as super-reviewers. those people are most familiar with the style, idioms, and common bugs/pitfalls in the codebase. then there is a tier of normal reviewers, who can do preliminary review 19:03:21 can we name a handful or a couple of people who can review Tor code as well as nickm can? 19:03:34 like +1s and +2s? 19:03:37 yeah 19:04:13 right now how many ppl we would have on each? 19:04:17 I think that if dgoulet, athena, asn, teor, Yawning, or isis told me "This patch is right; there is nothing wrong with it; you should merge it" I would be comfortable doing so. 19:04:21 this can be easily done for some subsystem right now I think, some of us know very well some of them so could be our responsability to ACK patches in those 19:04:22 I might have forgotten people 19:04:25 probably I did 19:04:53 dgoulet: we spoke about this at the dev meeeting indeed 19:05:04 unfortunately there are part of the code that are only known by one person so review makes it difficult apart spotting memleaks or bad indent or "C issues" 19:05:10 isabela: yup 19:05:52 dgoulet: yeah, that last part is what I feel like I can't reliably review for in many places of Tor (esp the ones I have not yet touched) 19:05:58 if we are to do it for some subsystems how could we start it? 19:07:06 we could chop tor into subsystems and have everybody rate their confidence with reviewing patches to each? 19:07:09 identify (we probably all know that already) some "sub-maintainer" of certian subsystem by that I mean nickm can merge a patch from any subsystem but he would PREFER having a ack from a sub-maintainer thus the right to poke that person 19:07:18 it's adding responsability basically on some devs 19:07:47 nickm: yup we could do this exercice totally 19:08:07 seems like a good use for a spreadsheet. storm or gdocs? 19:08:39 storm pad yeah 19:08:43 yeah 19:09:19 we'll definitely have blind spot there that is subsystem with an extra person that is not nickm, those are usually the issues with review :S 19:09:45 * isabela getting a pad 19:10:27 https://storm.torproject.org/shared/-jTLPf-PFlL28KfO3yEBKm4YvlgK9GnwxjAP4LXp2CL 19:10:45 dgoulet: that's why I favor "rate your ability to review", since sometimes a 1/5 review is better than no review 19:11:05 isabela: from backlog: regarding 1-on-1s (or 1-on-2s), would you mind sharing your experience with those with me? 19:11:14 yes sir 19:11:29 nickm: yup agree 19:11:35 that would be awesome! I have a similar item on my todo list, but I keep procrastinating there. 19:11:41 ! not related alert - hope tickets are on sale :) 19:12:23 isabela: they sold out 10 sec after they were on sale ;) 19:12:27 lol 19:12:31 of course 19:13:46 did storm fall over? I can't reach it or that pad link 19:14:10 is up and going for me 19:15:20 weird. new identity fixed it. new tor circuit for this site was not helping tho.. got it now at least 19:15:29 dgoulet: wtf they're already sold out? 19:15:50 helix: took litterally 10 sec, there will be more rounds, no worries 19:16:05 so on that pad we put our name under each place we think we can be useful? 19:16:08 or some score or ? 19:17:08 * nickm is filling in isabela's pad 19:17:56 ! 19:19:48 * nickm has noted all the areas where his is not a "3". 19:20:07 and tried to define 0, 1, 2, and 3 19:20:19 please let me know if there are questions, and fill in stuff on the pad if you can? 19:20:56 I am going to note all the places where I'm not a 0 or a 1 :) 19:21:09 maybe I should put that at the top of the pad 19:22:07 yeah we should have a default for everyone :) 19:24:10 * isabela really liking this system :) 19:26:28 I am trying to deliberately make it so that there is no choice other than "I could review it" 19:26:44 0 isn't "I can't review it"; it is "A randomly chosen C programmer of equal skill would do as well as I would" 19:27:15 nickm: will do! thanks for reminding me about that (#17271) 19:27:37 nickm: how hard it is to translate this into our review process? all the ppl who are 3 could review and merge patches for those subsystems? 19:28:44 * isabela thinks that an ok from two ppl who are 2 in a subsystem could be enough 19:30:07 we could have review progress in stages also. first you get a 1/2 person to review you; hopefully that results in a few things to fix. then you need to get two 2s, or a 3 to review before merge? 19:30:28 yeah 19:30:35 athena: I'd like to add you there as a 3 for a few things. What would yo uthink about that? 19:31:18 I'd also call people's attention to the fact that 3 is not "I have complete mastery of this code"; it is only "I understand it as well as anybody". So logically it is impossible for any area not to have at least 1 3 19:32:27 hrm I put 3 only in the part of the code I have very good knowledge, is that ok? 19:32:43 for me 2 is "I understand enough to do a resaonable good review" 19:33:05 ok, first question. right now is everyone using the same tool to review code? and what is it (sorry for not knowing this there has been so many hats since I joined :) 19:33:33 * dgoulet uses git for review 19:33:50 we've been trying phabricator or something. 19:33:53 (command line to be more precise) 19:33:54 Right now, we're all using git and manually reading diffs, I believe. 19:34:01 We tried phabricator and really didn't like it 19:34:10 or at least, some of us tried it and didn't like it. 19:34:11 what about reviewboard? 19:34:21 We talked about a bunch of possibilities at the dev meeting but couldn't find one we loved 19:34:33 * isabela thinks a common tool might be easier to see what is in the queue and organize this system 19:35:15 hm. There is a FOSS ReviewBoard instance. I'm trying to remember what the workflow was. 19:35:36 One problem is that a lot of these tools wanted to take complete ownership of your git repository, and we weren't really comfortable with that level of commitment 19:35:40 (no pun intended) 19:35:44 * isabela also thinks there will always be a little bit of pain in the adaptation process but we should definetely avoid too much pain by using a too we hate 19:36:13 nickm: I agree, we don't want that 19:36:39 *tool 19:37:11 yup and some of us (I include myself) find it quite a pain to review on a web interface (although that can be fixed with some fancy command line wrappers) 19:37:42 how many in the team cares about web interface? 19:38:08 I'd rather have a web interface, but I don't mind what others use. 19:38:13 I'd not want to have to use a web interface always 19:38:28 * isabela doesnt btw 19:39:29 can we have a homework to look for possible solutions that is not necessary web interface? 19:39:51 ideally one including "try it out" 19:42:55 god what a help 19:43:52 #action everybody fill out https://storm.torproject.org/shared/-jTLPf-PFlL28KfO3yEBKm4YvlgK9GnwxjAP4LXp2CL 19:44:04 #action everybody try to examine possible review tools 19:44:07 anything else for today? 19:44:18 i think this is great progress 19:45:53 #endmeeting