16:59:57 #startmeeting weekly network team meeting. 16:59:57 Meeting started Mon Oct 31 16:59:57 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:04 welcome, everybody, to the network team meeting. 17:00:10 Also, happy halloween (if that's a thing for you!) 17:00:14 douglas_: but, do they use it in the transparent proxy way, which probably shows poor judgment? 17:00:37 dgoulet: armadev: asn: athena: yawning: isis: chelseakomlo: isabela: welcome! 17:00:45 hi! 17:00:54 as usualy, we'll start with status updates, then discussion. 17:00:59 hi, dgoulet! 17:01:02 who else is here? 17:01:10 i! 17:01:17 Hi there. I have to leave abruptly soon I'd like to share a couple of things 17:01:56 hi armadev, hi Sebastian ! 17:02:01 Sebastian: you should probably go first then 17:02:08 (isabela said she might have to leave early too) 17:02:15 I kinda restarted the work on removing naming from Tor last week, discussed lots about version recommendations and how that fits into making releases for stuff. And I guess my plan for next week is to actually make some mergable stuff for the naming removal 17:02:24 I'm already done :) 17:02:36 Wonder what I forgot ;) 17:02:39 done with your status update or done with the naming? 17:02:40 nickm: hi! :) 17:02:48 hi chelsea! 17:02:48 status update! 17:02:55 and my status update is easy: i have been messing with #19969 and noticing #20499 and i filed a few new tickets like #20501 and #20502 and #20469 17:02:59 Sebastian: okay! Sounds good! 17:03:03 naming i didn't really get a chance to dig in 17:03:11 armadev: if you help us decide what to (not) backport to 028 or earlier, that would rock. 17:03:17 armadev: we're still noodling at tor-lts issues. 17:03:31 i have a short update: I'm going to finsih #18873 with the feedback from dgoulet, and then I have a proof of concept for running tor integration tests in a docker container 17:03:59 neat! 17:04:09 what will the benefit from that be? 17:04:17 (right. one of my conclusions from the last lts discussion was that we need a plan for how an old update will get into the hands of users (e.g. via a debian package), or it's less clear that doing the update will matter.) 17:04:36 armadev: I believe debian packages was the plan. 17:04:45 armadev: not finding anything else maintained on the same schedule that we care about. 17:05:05 data point: opensuse is on 0.2.7 apparently 17:05:18 (and applied the patch we released recently) 17:06:01 Sebastian: what would be useful to know is how often opensuse releases come out, and how long they would require Tor to be stable for. Having it on https://pad.riseup.net/p/tor-lts would rock. 17:06:16 running in a docker container is partly a proof of concept for #20458 but also hopefully to get tor integration tests in the CI 17:06:29 k, I'll see if I can find out and put it there 17:06:29 sounds neat 17:06:34 it should definitely be useful for CI 17:06:43 more testing good 17:07:24 dgoulet: would you like to go, or shall I? 17:07:29 I can go! 17:07:37 woohoo 17:07:39 Update: so I have this thing where I'm having trouble remembering what I did last week as I failed to note it down as I usually do... I recall some ticket review from the review-group-11 I believe. Some emails, test network business and unrelated little-t tor stuff. 17:07:56 but I need to refocus on continuing the prop224 for code where asn is awaiting multiple reviews 17:07:58 Sebastian: (my rationale is that we want to know how long we need to support releases for, and how long we need to support current releases for) 17:08:07 so my plan this week is that priority no1 17:08:36 nickm: discussion item also, I would like to know if you plan to re-review #17238 soon-ish and if not, I'll move to focus on some other part of prop224 17:08:48 makes sense to me -- if we let up on prop224 stuff, we're going to wake up one day and realize it's next summer and we're not done 17:08:52 I hope to re-review that this week 17:09:08 neat 17:09:53 right prop224 stuff has a lot of code but we need to work on merging it upstream so we can move forward to more bigger tasks that depends on a lot of that code and so forth, we have two big pieces right now "almost ready" 17:09:58 thanks 17:10:02 me now? or anybody else here? 17:11:07 ok, me! 17:11:08 ugh sorry about that. nickserv kicked me off 17:11:14 hi asn! 17:11:58 last week I finished the module documentation deliverables for sponsor U. Now every module that we're not planning to totally revise has documentation about its behavior in a nice doxygen comment at the head of it 17:12:18 I worked more on profiling, LTS policy, bugfixes, and reviewed and merged a pile of code 17:12:22 I also hacked more on 15056. 17:12:34 This week: finish 15056 or bust, since I really need to shift over to guards. 17:12:38 (#15056) 17:12:39 #15056 17:12:41 :) 17:13:00 I also hope to review and merge some of the bug tickets that are pending this week. 17:13:15 and figure out bugfixes for 029 etc when I'm blocked. 17:13:28 I'm hoping for help on a few of these; I'll save that for discussion time, though. 17:13:49 that's it for me. 17:14:17 asn next? then, anybody else? 17:14:44 (isis, athena, isabela ...?) 17:14:45 Hello. This week I did a few reviews, then I revamped my ESTABLISH_INTRO branch 17:14:45 (#19043) and the prop224 trunnel branch (#20004). This upcoming week I'm 17:14:45 planning to do more reviews, and write up a torspec branch for the client auth. 17:16:59 EOF 17:17:03 asn: (is #20004 for merging into master or into some prop224 branch?) 17:17:08 merging into master 17:17:12 sounds good. 17:17:25 it's like a preparation step for prop224. 17:17:25 once the torspec branch is done, then should I look at client auth stuff? 17:17:33 correct 17:17:40 i still have not gotten to it. too many things happening. 17:17:45 dont worry i will ping you 17:17:50 thanks, asn! 17:17:54 (currently reviewing #20262) 17:18:22 okay! On to discussion! But if there's anybody else with an update, please feel free to jump in. 17:18:39 asn: if there are bite-sized things i can help with for hs stuff, let me know. i seem to be bad at following through on large things but want to still be helpful. 17:18:48 The topics I have are: getting 029 out; 028 backport policy; LTS planning. 17:18:55 do we have others in mind? 17:19:26 small thing: 17:19:43 about the "0.2.???" that is not really accurate anymore, should we change it or not 17:20:05 milestone handling. got it! 17:20:34 armadev: perhaps reviewing the prop224 client auth torspec branch when it's out 17:20:35 so, for 029, one thing that would be helpful is to make sure that the 029 milestone contains everything that we should fix before 029 is stable. 17:20:47 armadev: there is also a mailing list thread but this might be way too much noise for you 17:20:55 armadev: i can ping you and nickm when the torspec patch is ready 17:20:56 another topic we might cover: are the weekly bug triage rotation ideas working? i notice asn and dgoulet and asn did it, and this week nobody is. 17:21:01 Also fixing and testing 029 bugs, but just making sure we have the list of bugs to fix would be a great help. 17:21:07 armadev: added to topics. 17:22:26 nickm: re 029 tickets saying 029.. which ones are you worried aren't saying 029 now? the ones that haven't been filed yet? or ones that were misfiled? 17:22:50 armadev: both! 17:23:51 I guess I can look at everything in 028, 029, 030, " ", etc... 17:24:04 focusing on anything with 029-backport marked, or an 029 version. 17:24:06 asking people to look through the deferred tickets is a recipe for finding ones to move to 029 that don't reeeally need to move 17:24:19 armadev: got a better recipe? 17:24:30 armadev: missing stuff that does need to go into 029 is pretty bad too 17:25:09 makes sense. i thought we did a triage not too long ago where we dumped 029 stuff out of 029. 17:25:14 i guess we didn't do the reverse 17:25:44 #19969 is the only 0.3.0 ticket in 029-backport 17:25:59 We have multiple candidate fixes; I'm moving it. 17:26:31 ok 17:26:49 hrm... when in doubt actually, I should have put the "029-backport" and then we could triage them instead of trying to find the 030 that we thought it could be a good idea... 17:26:50 we have 21 tickets in core tor without a milestone. 17:27:00 dgoulet: that would be great; would you like to do that/ 17:27:00 ? 17:27:09 nickm: I'm going over the one I triaged lately 17:27:18 there is at least one I can think of we thought of backporting 17:27:27 (the cmux ewma issue) 17:28:02 oh, the scheduler one? I'm going to suggest "no" on that one; the consequences are only hypothesized to be good. 17:28:25 nickm: ack 17:28:25 at worst, it just means "the scheduler did nothing" 17:28:30 basically 17:28:48 i have to sign off, but feel free to send small issues my way, particularly refactoring issues for the moment. 20458 will be something i'll do steadily & will likely take more conversations with teor 17:28:49 pastly wanted to run some larger shadow network with and without it to see 17:28:49 better to test it in some alphas than to find out we've accidentally pessimized when we meant to optimize 17:28:56 chelseakomlo: o/ 17:28:59 chelseakomlo: ok cool. thanks very much! 17:29:14 nickm: more this week :) thanks 17:29:15 dgoulet: I'll go over stuff without a milestone and stuff in 0.2.9 again. 17:29:20 ok 17:29:30 (I'll do that after the meeting) 17:29:35 dgoulet: they're still going. Other changes to the code are making Tor crash. Think I might have finally squashed them. 17:29:53 ahha ok thanks! :) 17:30:06 i am fine leaving the cmux ewma issue unbackported. as i understand it, i agree with nickm 17:30:10 So, for 028 and earlier, I suggest that we try to figure out a slightly more formal process for 028 backports, and a much more formal process for 024..027 backports. 17:30:42 And I think maybe some kind of milestone refactoring would be appropriate here. 17:30:51 for 028 and earlier backports, i remember writing out a proposed backport policy. and then asking isa to mail it to me from her backlog. and i think she did, but now i can't find it. 17:31:05 I think maybe I did? 17:31:07 anyways. 17:31:25 I think we want one policy for 028 ("latest stable") and one for everything earlier 17:31:39 and I think we want to have some thing where multiple people sign off on backports. 17:31:51 so far so good 17:32:00 (ah ha! you did email to me. found it. thanks) 17:32:13 and we might want to re-create new branches for backports to 0.2.7 and earlier, since I think we have backported stuff to git that should not have been backported. 17:32:30 I think armadev and weasel would be logical backport gatekeepers for <= 027. 17:32:56 yes, sebastian and i spoke about release-0.2.7 and how to handle that 17:33:00 we didn't come to a conclusion though 17:33:03 Though I can't make anybody do it, and I'd love other volunteers. 17:33:13 (either back out a bunch of commits to release-0.2.7, or throw it out and try again) 17:33:32 let's figure out the approval process, and save the git wrangling for later? 17:33:46 ok 17:33:47 (I think "make new branches, call the old ones defunct, delete NOTHING" is the best option) 17:34:03 release-0.2.7-this-time-for-sure 17:34:43 one useful step in 027 land would be to have a list of stuff we already backported. right now i can try to piece that together from git, but i might get it wrong. 17:34:52 but, approval process. your proposal sounds plausible to me. 17:35:11 especially because it doesn't stop anybody from doing a proposed list of things to backport 17:35:56 ok. So if I'm driving this, nothing will happen this week. Should we look for somebody else to drive, or assume that doing nothing on <=027 this week is fine? 17:36:04 either is ok w me 17:36:54 i don't think the world will end if it waits 17:37:01 ok 17:37:36 speaking of which, what was the reasoning for not doing an 0.2.7.7 with the trove bug fix? 17:37:40 For 028, I was planning to continue to use my judgment on what to backport. Any objections? 17:37:54 was it because release-0.2.7 already had a bunch of stuff in it and solving that at the time didn't seem worthwhile? 17:38:01 armadev: adding that to the list of discussion topics. 17:38:07 ok :) 17:38:42 assuming no objections then. :) 17:38:43 i guess one difference between 028 and 027-and-earlier is that tor browser still uses 028 17:38:52 next topic: milestone refactoring. 17:39:02 nickm: fine by me for 028 17:39:03 so if we stick stuff in an 028 update, then in theory actual tor users -- ours -- can get it on the next tor browser release 17:39:17 as for 027, finding gatekeepers is correct first step I believe and then they can drive it 17:39:20 dgoulet raised this as 0.2.???, but I'd like to propose this scheme. 17:39:29 ergo, let me put in a weak vote for paying attention to the tor browser release schedule 17:39:44 dgoulet: got any gatekeeper nominations? 17:39:46 :) 17:39:57 dgoulet: well, wait, why do gatekeepers necessarily need to drive it 17:40:28 an equally valid role for them would be to be oracles that say 'yes' or 'no' when asked about a given patch 17:40:37 which then leaves a hole for who is driving 17:40:45 armadev: well at some point we need some people to actually do something and if the gatekeepers job is to gatekeep <= 027 bugs, it's kind of implicit that they might want to drive the discussion on the process they want? 17:41:14 and then once that process is established, they can indeed at that point just sign off 17:42:03 nickm: to answer your question, kind of uncomfortable putting people on the spot :P 17:42:17 we can do an open call on network team mailing list I guess? 17:42:27 sure, and maybe ask packagers. 17:42:29 too 17:42:31 yup 17:42:33 dgoulet: in theory yes. in practice if weasel and i are the gatekeepers, we will not also be the backport managers 17:42:57 armadev: right, deciding the process and rules is more what I had in mind 17:43:07 not the "next 2 years of gatekeeping" :) 17:44:37 ok. on to milestones? :) 17:44:46 sounds good 17:44:57 hm. 15 min left. 17:45:29 so, I'm going to suggest that once a release is stable, we no longer use an "Tor: x.y.z" milestone for it. 17:45:53 gosh! 17:45:53 Instead, we have a "Tor: stable" milestone for bugs in the supported stable release... 17:46:14 and a "Tor: lts" milestone for bugs to be backported to the LTS releases (or not) 17:46:41 would we still do the keywords things we do now? 17:46:50 and that we rename "Tor: 0.2.???" to "Tor: later release" 17:47:00 armadev: question too vague; try again 17:47:13 would we still use keywords like 028-backport and 027-backport 17:47:52 ugh, sorry, i forgot about the time difference 17:48:08 * isis reads backlog 17:48:31 fwiw, i've been working on implementing and writing down the crypto for the rbridge thing 17:48:46 armadev: I don't know! 17:48:48 armadev: maybe! 17:48:52 probably even. 17:49:00 isis: cool! 17:49:14 isis: are you targetting deployment or prototype ? 17:49:22 so not really in network-team-land, since i need to finish up this otf stuff 17:49:27 ack 17:49:32 nickm: so hrm, we have all 030 ticket to "Tor: Stable" milestone, then if we want to backport one, once merged to upstream we set it to "Tor: LTS" with version number in the keywords? 17:49:39 nickm: i think i can actually make something production ready 17:49:40 something like that would be the process? 17:50:04 nickm: there's no pairings, it's reasonably fast, it's in rust 17:50:16 dgoulet: so right now, if there's a bug that's only in 0.3.0, it belongs in tor: 0.3.0.x-final 17:50:24 yes 17:50:26 dgoulet: so right now, if there's a bug that's only in 0.2.9, it belongs in tor: 0.2.9.x-final 17:50:35 and that wouldn't change until 0.2.9 becomes stable. 17:50:53 once 0.2.9 is stable, we close tor: 0.2.9.x-final 17:51:05 and bugs that are about 0.2.9.x go into "Tor: stable". 17:51:26 isis: cool! please tell me how you're liking rust some time 17:51:46 no need to decide on the milestone stuff today; just wanted to float the idea for comment. 17:51:52 are we going to be sad later that some tickets with milestone Tor: stable went into one stable, and others went into a different stable? 17:52:00 (or will we be happy later) 17:52:47 at least in theory, right now we can ask trac for a list of tickets that went into a given stable tree (e.g. 0.2.8.x-final) 17:53:05 hm. that is a good point. 17:53:14 counterpoint: please look at tor: 0.2.[4567]. 17:53:27 FWICT they are deeply unknown stuff. 17:53:35 so maybe we should think more about this. 17:53:41 i think right now the milestone is the highest-numbered branch it went into, 17:53:51 7 minutes left. Talk more on this one, or move to bug rotation / 027 topics? 17:53:56 and then not-entirely-consistently-used keywords indicate how far back it might or might not have been backported 17:54:04 let's cover remaining topics 17:54:37 then we can move to #tor-project and keep going on whichever ones we want to keep going on :) 17:55:11 what are remaining topics? "how is the weekly bug triage position idea going" and "why no 0.2.7.7 a few weeks ago"? were there more? 17:55:39 asn, dgoulet: how did the weekly bug triage position idea go? 17:55:48 I like it personally 17:55:56 and I do it here and there even if not my week :P 17:56:12 teor does it also when we are asleep 17:56:13 i think one of the goals might have been to get people more used to doing it in general 17:56:36 i also notice that only two people signed up 17:56:45 including into the future 17:57:11 i will let isa and nickm ponder that one :) 17:57:14 right 17:57:30 I am indeed pondering :/ 17:57:40 I'm pretty sure teor didn't because he knows he could have issues guaranting some time with his contract 17:57:46 didn't sign up* 17:58:45 I'll talk to isabela and see what we come up with. 17:59:11 on "why no 0.2.7.7" -- mainly because every time I do anything to 027, armadev asks my why. 17:59:14 *me why 17:59:14 ;) 17:59:20 and everytime I don't armadev asks me why. 17:59:21 ha 17:59:36 ...we should figure out how to fix that 17:59:37 that's kind of why I want an LTS policy here, so 027 and earlier can be Not My Problem. 17:59:49 makes sense 18:00:02 I did release patches for 024 and forward; OpenSUSE at least applied them. 18:00:10 okay, we're out of time. 18:00:14 (so the answer is "actually, it was even worse than 'we had all this already backported stuff clogging up the git branch') 18:00:33 The answer is "You told me that all the backported stuff was clogging up the git branch" 18:00:38 so I stopped doing 027 backports 18:01:16 ok. is the tor browser team meeting here now? meaning we should move? 18:01:23 I guess we should at least #endmeeting 18:01:25 #endmeeting