17:59:07 #startmeeting tor browser july 30 17:59:07 Meeting started Mon Jul 30 17:59:07 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:07 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:12 hi! 17:59:13 hello! 17:59:15 hi! 17:59:16 o/ 17:59:20 let's get started 17:59:31 hello! 17:59:34 the pad is over at https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N as usual 17:59:39 hi 17:59:52 please meark items bold you want to talk about (after adding ouyr own items) 17:59:54 sorry, I am having issues with sandstorm 17:59:57 hello 18:00:00 (is it just me?) 18:00:11 it's laggy af 18:00:17 wfm 18:00:55 I think we can start since I am anyways at the end of the pad 18:00:56 hello 18:01:22 done 18:02:49 okay, let's look over the items 18:02:57 it seems i am first 18:03:17 releases planning: 18:03:40 hi everyone 18:03:44 for the desktop alpha i was wondering whether we should postpone the release for aug 13/14 18:04:19 i am not really convinced we should push it out until aug 2 (assuming i should be helping with it) 18:04:57 my main reasons for that are the onboarding we might want to have i the next alpha to give it serious testing 18:05:07 and the win64 update issues makes me nervous 18:05:15 maybe landing more fixes first makes senseā€¦ which would be another benefit (plus you being more available in case things go wrong). 18:05:31 i want to ship a potential fix in the next alpha to give it some testing in a nother alpha if we need it 18:05:33 I also agree on the Win64 issue. 18:06:03 + i want to have http/2 enabled 18:06:47 okay, then let's keep working on all of those issues to have them ready/sorted out once i am back 18:06:51 yes, I think postponing to aug 13/14 is a good idea 18:06:58 and then we do a release with what we have 18:07:00 good 18:07:19 postponing it to aug 13/14 sounds good to me 18:07:25 then let's looks at the mobile angle 18:07:32 sysrqb: igt0: what do you think? 18:08:15 in terms of what remains before the alpha is ready? 18:08:22 yes 18:08:45 and whether we should postpone releasing as well 18:08:57 we planned for this week-ish 18:09:38 I think we have at least 1 week of work, but I think we could finish by the end of this week if we try very hard for it 18:09:52 looking at our blockers: the proxy bypass things and the onboarding are the remeaining ones 18:10:07 I am not sure how I feel about http2 on mobile, sysrqb do you know anything about it? 18:10:30 can anyone quickly point to the proxy bypass ticket? 18:10:31 and deciding how we create the signing key and discuss the updating mechanisms 18:10:48 https://trac.torproject.org/projects/tor/ticket/21863 18:10:57 ah the android one. thanks 18:11:03 yeah :) 18:11:13 i don't think http/2 is a blocker 18:11:22 but we will want it, of course 18:12:41 we may be able to push the updating ticket until the next alpha release 18:12:57 yes, i think so 18:13:04 and only have "re-download and install" as the update mechanism 18:14:01 #26242 18:14:26 sysrqb: igt0: should we plan for august 13/14 for doing the first tba release as well then? 18:14:26 but if igt0's patch is working, then we can include 18:14:34 i haven't tested it yet (#26242) 18:14:45 GeKo: that sounds good to me 18:14:45 i am not sure where we are with the onboarding exactly 18:15:01 but we might want to use that aadditional time to give it more testing 18:15:17 yes, plus that gives more time for creating the user manual 18:15:22 or iron out the most pressing issues 18:15:32 igt0: ^ 18:15:36 yep! 18:15:54 sysrqb: that's on our list? or is that a thing done by the community team? 18:16:15 sysrqb, are you looking in the onboarding, right? 18:16:37 GeKo, community team is taking a look, iirc ggus was the responsible for it. 18:17:00 okay, that's been my impression 18:17:07 i haven't done anythig with the manual 18:17:17 it seems we have a sync on wed, so we can see where we are with it 18:17:24 yes 18:18:05 I updated #25696 last week 18:18:44 sysrqb: igt0: great. so, are we clear on who is working on the onboarding stuff on mobile? 18:19:36 i was letting igt0 take the lead on that 18:19:49 okey, I can take a look this week. 18:20:11 sounds good, given that you are working on the proxy bypass bugs (the other remaining blocker) 18:20:20 :) (thanks!) 18:21:01 alright, we do bloth releases once i am back in the week from aug 13 18:21:12 let's work towards that with that "deadline" in mind 18:21:59 pospeselr: i think this reimbursement request does not sound unreasonable especially as we need good contacts to rust people etc. 18:22:27 i'd suggest asking travel@tpo about the reimbursement (feel free to cc me) 18:22:29 excellent thanks! 18:22:54 pospeselr: did you get a sponsored ticket? 18:23:09 yeah! 18:23:15 okay, cool 18:23:31 sukhe: you are up 18:24:16 hi. I have marked things I could use help with 18:24:30 let me summarize 18:25:31 https://trac.torproject.org/projects/tor/ticket/25485#comment:23 is what I am looking for, a small C++ program that _uses the latest CXXABI_ so that we compare and check to see if need to use our version of libstdc++ or not 18:26:21 which means we have to write a program that does that, except I can't figure out how to use "the latest CXXABI". I need someone who is good with C++ to tell me what the program should look like, because a simple program even compiled with -Wabi doesn't work 18:26:49 -W is a warning option 18:26:55 it doesn't affect the output 18:27:10 sorry, I miswrote 18:28:56 (I meant -fabi-version) 18:29:48 I can look this week if I see a way to do this 18:30:20 thanks, also I left a comment for you re: #12968. 18:30:43 (fwiw, I tried building with https://github.com/gcc-mirror/gcc/commit/f47fc7ef7f52cd095e636d4f93cca052427f3f0a.patch) 18:31:19 ok, I can look at this too this week 18:31:40 I don't need to put more things on your plate so if you can just address that question, I am happy to take care of the builds and testing part :) 18:32:25 ok 18:32:43 thanks, that's all from my side 18:32:45 okay, thanks boklm. that's at least a start (i'd need to dig into both things, too, in order to be helpful) 18:33:22 I have updated the progress related to #26476 where tjr and I are comparing the builds from TC 18:33:28 I never expected this would take so much time... 18:33:39 arthuredelstein: didn't you do the vacation thing last week? :p 18:33:58 both of us have put many hours into this, trying to compare if the toolchains differ and what not, but not much success 18:33:59 otherwise i think we are good with the status updates. 18:34:02 anything to add? 18:35:13 sukhe: where is that update? 18:35:40 GeKo: I will put it in the ticket. it is currently in our IRC discussions 18:35:48 ah, okay 18:36:53 sisbell: fwiw: nice work. i did not expect that this went so fast. now i hope there is no deep rabbit hole regarding the reproducibility of the binary 18:37:21 (the latter is the main reason for doing the whole dance with tor-browser-build/rbm in the first place) 18:37:39 okay, let's move on to the discussion part 18:38:11 so, i heard complaints from different sides about storm and it's unresponsiveness 18:38:12 I still need to find out how to verify the reproducibility 18:38:41 sisbell: well, building the .apk twice and comparing the sha256 sums is a good start 18:39:09 ok will do 18:39:15 ideally, building it on different machines 18:39:22 but we can do that later during review 18:39:40 as that's probably easier for more than one person 18:39:59 s/it's/its/ 18:40:15 i think we should make a decision on how to move on in that regard 18:40:39 sisbell: also checkout diffoscope if you haven't already - it has nice support for identifying which file is causing reproducibility issues 18:40:44 I am not a "Sandstorm" expert but I run it on my server and I have noticed it is a RAM hog. perhaps an easy fix would be to increase the memory on the machine 18:40:53 oh yes, definitely a +1 for diffoscope 18:40:58 are we sufficiently annoyed that we should explore other ways of collecting status updates for the meeting? 18:41:27 i see. 18:41:44 i'm not sufficiently annoyed, but i may have a high tolerance :) 18:42:07 it's working actually pretty well in my alpha tor browser 18:42:13 I have no problems; but wouldn't object to a change. w/e works for people 18:42:15 i had way more issues with an esr52based 18:43:31 * tjr has to go to an appointment 18:43:38 o/ 18:44:05 okay, i try to ask around first to get a potential memory upgrade going 18:44:07 not sure why it doesn't work well for me, but I can paste in my status and manage that way. Just makes editing difficult 18:44:32 at least i'll ask around figuring out where exactly the problem could be 18:44:35 which browser are you using? 18:44:43 arthuredelstein: ^ 18:45:05 TBB alpha or Firefox 61 18:45:15 I have the same issue as arthuredelstein with 61.0.1 (64-bit) (not TB) 18:45:17 hrm, okay. weird 18:45:39 arthuredelstein: and you see the isse with both? 18:45:41 in most cases, it doesn't even load the pad, let alone let me edit 18:45:42 *issue 18:45:51 huh 18:46:09 it's very slow and often disconnects in both 18:46:25 i use FF 61 and it's not nearly that bad for me 18:46:40 maybe it's my computer :) 18:46:44 but we can move if this is normal for some of you 18:47:15 do we have an alternative :) 18:47:22 riseup pad's are better for both of you? 18:47:32 I also like it because self-host it 18:47:34 *we 18:47:37 *pads 18:47:43 sukhe: +1 18:48:19 would removing status updates from previous weeks (decreasing the size of the pad) make it faster to load? 18:48:37 oh, good idea. we could try that 18:48:41 I agree there is value to self-hosting so maybe the answer is I just paste :) 18:48:44 that's possible, i know the network team deletes previous weeks 18:48:51 I don't want to cause more problems than this solves 18:49:10 seems worth trying, as long as its arhived on the mailing list 18:49:25 arthuredelstein: yeah 18:49:31 okay, let's try to delete previous updates and figure out whether some memory upgrade could help 18:49:39 and if not let's find something else 18:49:40 deleting the pad should improve the loading of the grain, at least anecdotally 18:49:55 If it's working for other people but not me, it suggests it's not a server issue 18:50:00 at least I would guess 18:50:30 you're not the only one 18:50:37 sukhe: said he has similar issues 18:50:43 yes, but maybe we could improve things on different ends 18:50:45 err s/:// 18:51:25 re the github thing: i wrote an email to isabela's mail to tbb-dev to get the discussion going 18:51:31 yeah, but I can live with it. it's not completely broken so why fix it ;) 18:51:48 please chime in if there is anything to add 18:52:05 sorry if it seemed like I said it was causing a problem 18:52:14 or if i am wrong with the things i wrote 18:52:53 i think we could indeed benefit from some form or github "integration" and i think we could have someone taking this onto their plate 18:52:53 +1 for keeping git in-house 18:53:02 don't need msft potentially screwing us in the future 18:53:02 yes 18:53:17 yep 18:53:47 I guess I'm not sure what problem we want to solve by further github integration 18:54:00 code review I think 18:54:09 that's one 18:54:51 also, GitHub gives more control some ways. (I am not saying we should use --force :) but there are other things, like deleting a remote branch which is not possible on git.tp unless the permissions are set 18:54:59 and then there could be an argument made for getting patches faster as it might expose our code to more devs 18:55:34 It's true that code review is nicer on github but I'm a little hesitant to shard our reviews from trac 18:56:20 Mozilla has a separate review tool but the comments get mirrored back to bugzilla so it's still searchable 18:56:25 bc we could lose them on github? 18:56:39 aha! 18:56:42 Just that they're not searchable or readable in one place 18:57:00 I wonder if there is a trac plugin that could do the same kind of mirroring. 18:57:13 arthuredelstein: at least the way I do it -- and doesn't make it right -- is that I reference a github branch on to trac so that way the comments stay on trac and the code is on github 18:57:57 sukhe: Yeah, I think that's fine. I do the same :) 18:58:06 yes, that's what we currently have 18:58:17 More wondering about the benefits/drawbacks of using github's built-in code review 18:59:49 arthuredelstein: could you voice your concerns in a reply to that tbb-dev thread? 19:00:08 sure, will do 19:00:26 Network Team people might have useful input about code review tools since they use them (at least sometimes). 19:00:53 i am happy if we could satisfy the wishes tjr had while taking he concerns with github into account as well 19:01:25 okay, final point: next meeting 19:01:38 i need to be afk next monday (and the whole week) 19:01:51 i'm happy with github's review tools. i think they're not perfect, but the network/community effects and usability outweigh the drawbacks 19:01:52 so, i guess 8/13 would be the next one? 19:02:28 catalyst: thanks 19:02:34 catalyst: which network/community effects wrt review tools to you have in mind? 19:02:41 *do 19:03:08 catalyst: Are you using github tickets as well? Or just trac tickets? 19:03:22 low barrier to entry for new contributors. automatic CI building of pull requests so you know if someone's patches broke the build before you spend time to read them 19:04:02 we use trac tickets for issue tracking together with github pull requests 19:04:05 ah, you were not speaking of review tools in particular, okay 19:05:02 any objection to next meeting on 8/13? 19:05:14 i was lumping CI running on pull requests in with review tools 19:05:21 k 19:05:27 8/13 sounds good to me 19:05:32 me too 19:05:34 no objection of 8/13 19:05:36 8/13 sounds fine. 19:05:50 good as well 19:06:04 it sounds good to me 19:06:13 no objections! 19:06:18 okay, great! 19:06:29 anything else for discussion? 19:07:15 then we are done with the meeting for today, thanks all *baf* 19:07:19 #endmeeting