20:00:15 #startmeeting anti-censorship checkin 2019/03/21 20:00:15 Meeting started Thu Mar 21 20:00:15 2019 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:19 hi o/ 20:00:22 hello hello o/ 20:00:33 our pad is at: https://pad.riseup.net/p/tor-censorship-2019-keep 20:00:51 o/ 20:01:47 hi 20:02:07 o/ 20:03:09 hmm, we are missing the country stats bug in the roadmap i think 20:03:18 * ahf tries to add it 20:03:37 or am i just missing it? it's bug #29734 20:03:47 https://storm.torproject.org/grain/2mAgzq8bAK5RnQQGPMk6vr/b/sandstorm/libreboard is the roadmap link, sorry 20:04:13 ahhh! it's in done, perfect 20:04:16 i'm just blind 20:04:33 perfect 20:04:43 other than that, i think the snowflake parts looks right? 20:04:53 yup 20:04:58 i moved some stuff around earlier today 20:05:05 awesome, thanks 20:05:18 gettor roadmap i don't think there is any updates to as hiro is out this week 20:05:27 do we have changes to the bridgedb roadmap? 20:06:06 I closed a ticket and it should be removed from the rodmap. 20:06:15 #25430 20:06:21 maybe i need to check in with sysrqb about bridgedb release stuff 20:06:24 ah, cool 20:06:29 thanks kat5 20:06:37 We concluded that moat fixes that issue. 20:06:48 I don't think I can edit the roadmap. 20:07:01 let me see if i can 20:08:09 woh, it's moved to done now on the roadmap i think 20:08:11 thanks kat5 20:08:35 catalyst: when is the current planned next-release? 20:09:05 sysrqb: i'm not sure i understand what all the timing constraints are 20:09:09 and catalyst is hacking on #28925 on the PT roadmap 20:09:12 very nice 20:09:25 otherwise i think they are in sync 20:09:34 catalyst: okay, we can discuss later 20:09:41 sysrqb: thanks 20:09:58 catalyst: sysrqb: i don't think there are any time constraints or planned release dates fwiw 20:10:11 just that it would be something good to have 20:10:28 and it's in with the s19 stuff 20:10:42 okay, that was my understanding, but i can help with this if there is a deadline/timeline for it 20:11:32 should we go to the announcement list or do we have more roadmappy things? 20:11:59 uhm, wait, i might be doing this in the wrong order. we should probably look at the "Help with" first 20:12:03 oh i had a q about the roadmap 20:12:11 yep? 20:12:27 we have #25593 on there 20:12:44 yeah, the very open one 20:12:44 but i think this is tied to stuff dcf is working on with looking at alternatives for domain fronting 20:13:01 yeah, but also related to maybe having more than one instance of the broker, i think? 20:13:10 ah okay 20:13:11 like, just to avoid that the entire system is down if one service is down, no? 20:13:22 i was trying to remember what we were discussing about it in brussels 20:13:27 yeah i think you are right 20:13:32 i read it more as "high availability" than something DoS-related actually 20:13:56 the ticket itself doesn't mention that so perhaps i will update it 20:14:02 yes I put different broker access methods in a different category than DoS resistance 20:14:13 okay thanks! 20:14:18 yeah, we should maybe also give it a better summary line (i think the DoS line confuses us) 20:14:27 i've more than once been confused about that bug too 20:14:36 the link to the github issue mentions the wrong thing then 20:14:54 By DoS I'm thinking things like SYN flood, packet flood, memory exhaustion, etc. 20:15:14 I documented it as DoS, so if you're going to change it, more of a description would be good. 20:15:17 ahh interesting. that is probably more important than multiple brokers for now 20:15:23 Not things like just blocking the IP address, for which we have domain fronting and other potential workarounds. 20:15:29 if we are going for MVP 20:15:31 That's what I figured it was. 20:15:38 maybe we should create another ticket for the "high availability" part of it? 20:16:05 ahf: I mean, I would put redundancy in yet a third category. 20:16:08 what dcf1 is describing I think fits with the term DoS 20:16:33 dcf1: agreed 20:16:40 yeah 20:16:54 so it wouldn't make sense to rename/modify anything with this ticket 20:16:59 yes, these are all really different aspects of "availability" though, if you think about it. 20:17:08 yeah 20:17:11 lol true 20:17:52 all our tickets are availability of Tor in a general sense XD 20:18:04 haha, true 20:18:10 it all boils down to that 20:18:18 okay it's on my roadmap so i'll expand on the description and take a look at it this week, but it is very open-ended 20:19:01 dcf1: is there any concrete concerns you have right now around ticket #25593 ? 20:22:42 no 20:22:46 oki 20:22:53 should we move to "help with" sections on the pad? 20:23:12 I think it was a very general, roadmappy ticket from early development. Nothing specific. 20:23:37 oki, makes sense 20:23:58 We could close it and replace it with something less vague, I'm not attached to that ticket at all. 20:24:01 i see cohosh has a question around gitlab and what we do with merging, i think that is related to what i was gonna hear about on announcements too, so i'm gonna remove it from the announcements list 20:24:12 ok 20:24:34 so linus helped me getting everything setup on the machine that is going to run gitlab now 20:24:51 so now the next step is that i try to get it running using debian's "salsa" ansible cookbooks 20:25:14 i suspect there will be some issues on the way (especially with the LDAP integration since i have no idea how that works) 20:25:28 * dcf1 expresses appreciation towards ahf for this work on setting up a server 20:25:47 i think we should continue to do work with trac+git.torproject.org as long as the gitlab instance isn't there 20:25:50 dcf1: thanks! 20:26:06 yes thank you ahf! 20:26:15 but, maybe we should make sure that we are more people that can merge? 20:26:54 sounds good to me 20:26:57 in the network-team we recently have talked a lot about how to "merge" code in a "sane way", and i (think) what we do right now is that: the person who reviews the code cannot merge it, which means the merger will do a sort-of second review of the code too 20:27:36 which i think seems smart, but the network team have had some concerns around it because the volume of code going in there is also bigger than what we do and also it's written in C so every single line might make something blow up 20:28:03 i don't know if we should do the same here? so when for example i've reviewed cohosh's changes to the geoip code, then i pass it onto dcf1 who merges it? 20:28:17 two things from my end: 1. I can open a ticket to ask for ahf and cohosh to be able to merge to tpo snowflake.git; 2. I can handle merges until then or until gitlab is set up. 20:28:17 and if dcf have a patch then either cohosh or i review it and the other person merges it? 20:28:38 ahf: this is difficult with not many people 20:28:49 cohosh: i agree! 20:29:00 maybe just the reviewer says OK and merges? 20:29:09 then we could go with dcf1's (1) suggestion? 20:29:25 that requires a signed ticket to the git sysadmins i think on trac 20:30:22 yeah I've done that before, I'm looking for a past instance to use as a template lol 20:30:31 :-D 20:30:38 i've never done it before, i think i have just seen them happen 20:30:49 maybe irl can help if you cannot find the template 20:30:57 i think arma1 just recently created one for me about the s19 stuff 20:31:00 * cohosh looks for it 20:31:07 cool! 20:31:32 #29679 20:32:05 all right, I'll file one of those tickets. Do we need access to others besides ahf and cohosh? 20:32:28 i think that set seems right for now 20:32:45 yup 20:33:42 cool, so we go with "whoever reviews it, merges it" for now? 20:33:47 if the code looks reasonable that is 20:33:56 yolo! 20:34:00 ;-) 20:34:03 lol 20:34:14 sounds good to me 20:34:15 kat5: totally, haha 20:34:16 That rule works for me. 20:34:25 ... and nobody has said anything about whether you can review your own code! 20:34:28 * ahf giggles 20:35:01 cool, that was good to get that solved 20:35:11 then we have two reviews: #29297 and #21304 20:35:18 I'm fine too if the author merges after merge_ready, but also I don't mind asking someone else to do merges of my code. 20:35:36 I'm looking at #21304. 20:35:39 i haven't had a chance to look at #29297 yet, but was hoping to be able to get around it tomorrow morning 20:35:46 dcf1: thanks! 20:35:50 great, that sounds like we have one person at least on each 20:36:59 cool, i don't see any other help items on the pad - the one about marionette is from last week 20:37:42 announcements: we only have one. pili sent an email about "Google Season of Docs" which is like Summer of Code, but for technical writing/documentation 20:38:07 do we have something related to the anti-censorship team there that would be interesting to get done here from a student who is into technical writing? 20:38:36 FYI, I am done at end of May. 20:38:41 they get paid in the same way as GSoC student does i believe so it should probably also be seen as a way to maybe find cool new people who could get excited about something related to anti-censorship 20:38:48 kat5: ah, so soon :-( 20:39:17 Which should include wrapping up the sponsor 19 final report and then maybe one or two other small things if we have any. 20:39:36 kat5: cool, so end-of-may i assume here? 20:39:57 Huh? Yes, I'm done at end of May. 20:40:01 * Samdney is watching .... 20:40:15 oh, sorry, you wrote that, i read it as it just said "May" 20:40:38 does this include localization of things? 20:40:53 cohosh: i don't think so, but i'm actually not sure 20:41:21 i think tor already have some group we work together with on localization that we can get help from if we need to 20:41:34 I don't think tech writing usually includes translation. 20:41:35 i think the browser team and the website/ux team knows more about that 20:41:48 okay cool, thanks. i wasn't sure how general it was 20:42:12 i'm not 100% sure about all of this, i have it on my todo to figure out what the scope of it is 20:42:26 what about that bridge guide for NGOs thing that i think was on kat5's list? that seems potentially very useful 20:42:57 good call 20:43:35 What I didn't get from pili's email was whether this would be combined with other Tor work. Or whether, say, the community team would ask for one person and she wants us to ask for another. 20:43:46 yep, i think that could be in the scope for it. i think maybe it could make sense for us to look at what user-targetting/org-targetting documentation we have in TPO for tor-related stuff and see if there is something missing for PT's/bridges/snowflake/etc. too 20:43:49 What I'm thinking is that we'd have to have enough work for whatever the term is. 20:43:55 hi :) 20:44:02 pili: o/ 20:44:11 I would want to ask for as many ideas as we can get 20:44:22 and then how many people we get depends on how many we are prepared to mentor 20:44:27 Also, I may still get to at least starting that ngo bridge doc with any luck. 20:44:40 pili: is it like gsoc with one/two mentors per student and one project per student? 20:44:54 yup, I believe so 20:45:10 I actually think they may not be students though, but actual technical writers 20:45:18 not sure how that works though 20:45:37 oh, i think i added the student-part, yeah 20:45:38 as in, why a technical writer would go for this necessarily :) 20:45:59 but anyway, looking for plenty of ideas, that way they have more to choose from 20:46:00 yeah, it doesn't mention students at all on the site, cool 20:46:03 we don't have to mentor all ideas 20:46:10 I think it would be because they are looking for experience and want to get it in oss. 20:46:27 kat5: yeah, that's probably it :) 20:46:54 IME, it's fairy common for tech writing to be a career change. 20:48:25 tech writing can be tricky :) 20:49:27 pili: so if we spend the next week trying to get some ideas that would be OK? or what is your deadline'ish? 20:49:34 yup, that would be great 20:49:50 the program actually opens on 2nd April 20:49:53 for applications 20:50:09 ah, and then we need to start submit project proposals? 20:50:34 yup 20:51:33 cool! 20:52:32 awesome, i don't think we have anything else here today. i wrote an email today to tor's HR to figure out what we do with the "tor project, inc" peer-to-peer feedback process that is coming up and what we should do with the very new anti-censorship team people, so hopefully we know more about that next week or something 20:52:44 anybody else who have anything? 20:53:51 nope 20:53:58 coolio 20:54:01 thanks all o/ 20:54:04 #endmeeting