17:01:04 #startmeeting OONI weekly dev gathering 2016-05-30 17:01:04 Meeting started Mon May 30 17:01:04 2016 UTC. The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:01:10 here we go 17:01:11 heya 17:01:27 hi 17:01:30 hi 17:02:48 excellent. 17:03:03 what do we have to talk about this week? 17:03:19 so we didn't circulate an agenda prior to this, so does anybody have something they would like to talk about? 17:03:27 here 17:03:33 web connectivity is merged, and lepidopter image is out. those are both cool 17:03:44 it might be good to talk about the ooni website? 17:03:54 indeed 17:03:56 it sounds like it's in two places right now 17:04:10 is it that ooni.io is hosted as a github static page 17:04:18 #topic ooni website 17:04:19 and ooni.torproject.org is on torproject servers? 17:05:12 yeah, so let me explain a second what is the current way the ooni website works. It uses a static website generator called hugo to build the content pages and blog pages. 17:05:58 there is then a script that you run once you have tested locally with hugo that everything looks alright that will generate the site, the documentation and push it to a github pages repository here: https://github.com/ooni/ooni.github.io 17:06:19 hugo is like jekyll? 17:06:34 once that is done you need to login to thetorproject server and run another script to sync what is on ooni.github.io with ooni.torproject.org 17:06:40 at that point it's updated 17:06:46 willscott: yes, something like that 17:06:57 and the reason there are two steps is because those two urls are served by two different servers? 17:07:09 could we change DNS records so that they're both pointing to the same server? 17:08:36 i think github static page cnames are limited to a single domain 17:08:45 willscott: the reason why there are two steps is that on torproject infrastructure we can't install any software that is not packaged in debian. So the site needs to be built elsewhere and pushed somewhere to be pulled in. In theory I guess the publish script could push directly to thetorproject server as well as pushing to github. 17:09:06 is the torproject infrastructure the 'canonical version'? 17:09:12 willscott: yes. 17:09:19 hellais: hugo is packaged on debian 17:09:50 anadahz: I don't think it's in debian stable though 17:10:44 the value of having hugo on tpo infrastructure is that we could automate that server updating its contents? 17:11:10 hellais: it's in testing though 17:12:18 willscott: yeah, though I think this encourages not testing the site locally before pushing content to the live site. 17:13:34 tbh I think that we are starting to outgrow the statically generated site we currently have and we should consider moving at some point to something like a CMS to make it easier to update and post content. 17:14:10 such a thing would likely be harder to host on tpo infrastructure, no? 17:14:48 willscott: yes, I don't think we should host it there, but put it up on something we run ourselves 17:15:10 #action figure out where to host a CMS version of the website 17:16:39 git syncing to CMS is really hard 17:16:50 cool. it seems like the next steps are asynchronous: propose what system to use, and think about where the server should live 17:17:12 anadahz: i think that's another question. if we transition to a CMS, git would probably no longer be the canonical version 17:17:23 but instead we'd have to do backups of however the cms saved its contents 17:18:30 proposed next topic: should we do some publicity around web_connectivity to try to get existing probe operators to upgrade? 17:18:34 and apparently we 'll need to completely re-design the whole OONI website 17:19:31 if we're moving away from tpo infrastructure, would it make sense to have content on gitlab and to push it onto the server from there? 17:19:48 I think automating the task of publishing content is a more viable option and requires less development effort 17:20:08 we don't have a gitlab instance set up 17:20:16 afaik 17:20:48 personally i don't like the idea of moving away OONI website from tpo infrastructure 17:21:07 can't a similar approach be applied from github, if we move away from tpo infrastructure? 17:21:16 one thing we can do is treat the github static page server as a staging server 17:21:23 (anadahz: I'm not suggesting that moving away from tpo is a great idea either) 17:21:36 and sanity check that before kicking-off a sync step to the tpo server 17:21:48 that maybe alleviates hellais's concern with a fully-automated system 17:21:50 willscott: yes, that's what I meant :) 17:22:35 willscott: yeah, that is basically the system that we currently have. github is used to stage the content and then tpo pulls in the content from it. 17:22:50 the problem I see with hosting on tpo is that not all the people that are member of ooni could truly change ooni website and this could be a problem sometimes 17:23:23 so, it seems like this is another case where it would be nice to have gitlab or some sort of CI tool 17:23:43 where we get our own ACL system for people we trust to be able to 'kick off' a synchronization to tpo 17:24:11 well, if the canonical version is on github, we already can do that 17:26:00 what are the advantages of hosting the website on tpo infrastructure? 17:26:24 someone else takes care of being the admin / keeping the site up :) 17:26:52 plus communicates clearly affiliation with Tor 17:27:15 right 17:27:46 I was just thinking that if the websites was, say, hosted at openobservatory.org, wouldn't that enable us to just push content directly from github with a simple update script? 17:27:52 *website 17:27:57 true 17:28:14 it could also be possible to host on github using cname 17:28:21 right 17:28:26 this way no sysadmin work needed on our part 17:28:29 the same can be true of a tpo site - it's just a question permissions for who can run that script 17:28:51 right: my understanding (correct me if wrong) is that one needs a tpo account to do that 17:28:52 anyway, that's what I'm doing with one of my projects, and it's pretty easy to run, maintain and push content to 17:29:25 and, I think only hellais and anadahz have it, right? 17:29:34 right 17:30:28 an intermediate step if we want to keep using TPO infrastructure but change the ACL would be to set up a CI machine with cached credentials 17:30:34 sbs: correct. You need to have a torproject ldap account for that. 17:31:34 so it sounds like it comes down the following options (and pls correct me if I am wrong): (1) we keep it as it, and more of us get tpo accounts to that we can push content directly, (2) we host it elsewhere, and just push directly from github, (3_ we consider a different CMS altogether 17:31:49 would tor allow ooni.tpo point as cname to ooni.github.io? 17:31:54 (apologies for the typos) 17:32:28 agrabeli_: yeah, I think those are the options, plus (4) tor allows ooni.tpo to be cname for ooni.github.io? 17:33:35 sbs: yes I don't think it would be a problem to get a cname setup for ooni.tpo. The only problem I guess is having HTTPS 17:34:10 hellais: ah, damn, you're right! 17:34:20 I'm not sure if they would issue us a ooni.torproject.org certificate since the *.torproject.org wildcard cert exists 17:34:48 we could use cloudflare for https (joking) 17:34:59 willscott: LOL 17:35:04 willscott: ahahahahaha 17:36:53 so given the options, how about we explore whether more of us can get tpo accounts for the web purposes, while also looking into viable CMS options? And perhaps we can get back on this and decide from there? 17:37:16 Github pages doesn't support HTTPS atm - https://github.com/isaacs/github/issues/156 17:37:41 if we can't get tpo accounts, we can set up a CI to hack around that problem 17:38:08 i think we should do research about how we want it to work, and have stronger preferences, and then regroup 17:38:28 willscott: agreed 17:38:37 i think we're somewhat dis-satisfied, but none of us have a strong vision of what we want to change it to right now 17:38:46 cool 17:39:08 sounds good 17:39:18 i mentioned publicity around web_connectivity earlier 17:39:33 should we start tweeting / otherwise publicizing that it's time to upgrade your ooni-probe? 17:39:51 OK agreed until we find a better option 17:40:07 willscott: yeah, I think we should def try to bring some publicity about the test, it's really cool! 17:40:08 just FYI the only person that can update OONI website atm is hellais 17:40:34 willscott: yeah I think we should do that! 17:40:51 hellais: won't the probe operators' images update automatically to the latest version, and thus run web_connectivity by default? 17:40:52 anadahz: you should also have the correct permissions now, no? 17:41:16 agrabeli_: depends how they installed it, no? 17:41:17 agrabeli_: yes the ones running the raspberry pi distributions will, but not people that have installed ooniprobe with pip 17:41:18 hellais: haven't tested yet if i have push access to gh-pages 17:42:36 anadahz: ah, so github permissions then. if you can push to other org. repos, you're probably good to go there 17:42:45 since we have some time left shall we talk about some previous agenda topics that we haven't made a consent yet? 17:43:16 willscott: gh-pages use different permission set 17:43:34 to finish the web_connectivity thread: it sounds like some publicity or reaching out to known operators might be in order 17:43:40 anadahz: you have them correctly set now. 17:43:43 anadahz: i wasn't aware of branch-level permissions 17:44:15 hellais: thanks 17:44:17 but regardless. sounds resolved 17:45:01 willscott: yes, usually a message is posted to mailing list and tweets are sent from @openobservatory. Given the importance of this new test I think it may be in order to try to do something more this time 17:45:08 willscott: perhaps it would make sense to release a short blog on the Tor Project blog about web_connectivity? 17:45:09 perhaps write a blog post about it? 17:45:19 I think that would help with the publicity of the test 17:45:40 can we look at recent uploads and get point of contact from them? 17:45:54 (is that something we want) 17:46:21 i guess we started an ooni-operators list as well 17:46:24 "unfortunately" we don't store any type of personally identifiable information so we don't really know who is submitting the reports 17:46:33 so the other campaign is to get people to subscribe to that list for this sort of updates 17:47:25 yes, the idea behind the probe operators list is that it's meant to be a very low traffic mailing list that people interested in running ooniprobe will get essential updates from it 17:47:55 so I guess we can add the new mailing list on the website, tweet about it 17:48:17 there are 52 people subscribed to it currently 17:48:21 and separately, tweet about web_connectivity and release a short blog about it 17:48:46 I'd be happy to write up a short blog on web_connectivity 17:49:05 I recently wrote a description for it, so writing a blog should not take time (I could do that tonight) 17:49:24 cool. 17:49:29 (thanks sbs for the feedback, I'll update the description tonight :)) 17:49:40 is there a released pip version with web_connectivity? 17:49:54 if not, we should wait on publicity until the merge has filtered to the various channels 17:49:59 e.g. debian package? 17:50:38 agrabeli_: you're welcome! 17:50:57 speaking of debs, what is exactly the procedure for a new debian package? 17:51:44 yes the pip package is not released yet, I am waiting on the update of the backend 17:52:35 so i guess, lets wait to see the release from hellais, and then we can start publicity 17:52:52 but we can probably start writing blog posts / etc. in tandem with the release tasks 17:52:52 sure 17:53:55 do we want to aim to publish the blog on our website or on tor's? 17:54:09 i'd say start with ooni's 17:54:23 one thing that would be of interest is we can track how many submissions start updating to the new version 17:54:24 it would be faster and easier to publish on ours, but if we publish on tor the test will probably get more publicity 17:54:53 i feel like this is a pretty technical change, and harder to convey what's interesting to the 'tor user' audience 17:56:08 if we were going to put something on the tor blog in the next week or two, i think 'help us by alpha testing lepidopter' is probably a better candidate 17:56:45 willscott: or maybe it could be about both (web_connectivity and lepidopter)? 17:58:19 anyway, let's coordinate on the details of publication over the next few days, and move on to anadahz's suggestion for a topic? :) 17:58:29 maybe, i just feel like it's such a small fraction of the tor blog audience that can either take action or get value of knowledge of web_connectivity change 17:59:39 we're also at-time 18:00:17 anadahz: lets hear the topics, but since the point was that we don't have consensus, maybe worth waiting until next week to have the associated debates? 18:00:47 yes let's do this next week we are out of time today 18:01:47 cool cool. thanks all :) 18:01:50 great. It's perhaps ideal if next week we make sure to post some of the agenda items before the meeting so that we can have a chance to think about them/discuss time ahead of time 18:03:43 * landers g2g, c'y'all 18:04:00 #endmeeting