18:58:29 #startmeeting Tor Browser meeting 2021 January 11 18:58:29 Meeting started Mon Jan 11 18:58:29 2021 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:58:45 Hello! 18:58:46 Pad: https://pad.riseup.net/p/tor-tbb-2020-keep 18:58:55 (ignore the year) 18:59:00 o/ 18:59:07 Hello! Happy New Year, everyone 18:59:24 hi! 18:59:51 hey 19:00:38 can we move to http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-tbb-keep ? 19:01:00 hi all :) 19:02:56 dunqan: hi! 19:03:08 gaba: yes 19:03:15 i'm not tied to the current pad 19:03:33 i just didn't care enough to change it for this meeting 19:05:31 ok 19:10:37 GeKo: do you have discussion topics you want to add on the pad? 19:11:13 ah, you're still adding items in your todo list 19:12:03 yeah, sorry, am late today 19:12:15 i'll add all my review work after the meeting 19:14:19 Thanks 19:14:45 Reminder: Please update your boards (as/if needed): https://gitlab.torproject.org/groups/tpo/applications/-/boards 19:16:32 okay, let's start with discussions 19:16:42 "Linux switch to Firefox 85?" 19:17:54 yeah 19:18:27 so i worked on getting the build parts done during the past couple of days and weeks 19:18:45 and am ready with that 19:18:45 * Jeremy_Rand_Talos notes that moving Linux to rapid release will make things more hectic for me in terms of the ARM/POWER ports, but that's my job to deal with and it shouldn't dissuade you in any way 19:19:06 but it does not run 19:19:16 due to https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/40004 19:19:37 i rememberr mcs and brade not being overly happy with async logic here 19:19:48 but it seems it's time we need to bite that bullet 19:19:58 the qeuestion is when 19:20:13 given that linux will be the first platform where we plan to test https-only mode 19:20:33 and we rather wanted to start testing sooner than later 19:22:10 additionally, we should remember that there are other tickets we marked with ff88-esr or something 19:22:31 however, last time i looked those were no blockers for nightly builds imo 19:22:59 maybe we could move to async as part of s30 (quickstart) 19:23:42 ah, it's ff91-esr now 19:23:48 but, hrm we are missing tickets 19:24:00 GeKo: yeah, i changed the label to ff91-esr 19:24:30 no, that's all ticket i remember 19:24:32 thanks 19:24:43 *tickets 19:25:32 acat: maybe but that means async for esr78 already 19:25:48 not sure if that's a thing we want 19:25:59 but maybe it does not matter much 19:27:23 not sure how big the effort would be, i would need to take a look 19:27:44 but we could try, and maybe it's not too hard to move to async 19:27:57 and not too risky 19:28:50 hello! (sorry!) 19:28:53 * sysrqb reads backlog 19:29:01 hi! 19:29:13 o/ 19:29:48 I lost internet here 19:32:10 Originally, I put Linux on the build plan for 85b7 19:32:35 but, that plan previously included an alpha version last week 19:32:54 so we got would have two alphs this month 19:33:04 that's not realistic at this point 19:33:33 so we shouldn't include Linux in the 85 release plans 19:34:19 yeah 19:34:29 i am more interested in nightly builds at this point anyway 19:35:21 like getting this going fast in nightlies 19:35:51 + enabling htts-only mode thee 19:36:04 *https there* 19:36:11 and then thinking about alphas 19:36:14 and what we need for them 19:36:34 hrm 19:36:52 or maybe stabilizing on alphas first might be smarter 19:37:01 because it would make alpha releasing easier 19:37:20 hrm 19:37:36 anyway, nightlies first i think is s good goal 19:37:43 and then looking at the fallout 19:37:45 that's true 19:37:53 and needed as a dependency for alpha, anyway 19:37:57 given the updater is involved, too 19:39:11 acat: can you put this on your plate for next week? 19:39:43 i prefer you concentrate on getting the android tests working this week 19:40:04 sysrqb: tor-launcher#40004? ok 19:40:19 yeah 19:40:42 or, if you have some time later this week, then you can start estimating the time needed for it 19:41:21 ok 19:41:28 but i really would like a stable android testing framework before we move on to move linux 19:41:37 *moving linux 19:43:21 GeKo: where are we with the mmdebstrap? 19:43:49 we are good 19:44:14 boklm and i debugged the issues during the last weeks 19:44:31 the rbm changes landed 19:44:51 and the tor-browser-build ones need just a final rebase and squashing 19:45:13 you and acat could try things out whether they are working on your non-tpo setups 19:45:32 because we'll burn the deboostrap bridge 19:45:59 that will happen with the nightly machine switch 19:46:20 which boklm is currently working on 19:46:36 there is no hard eta for that yet 19:46:57 but we might build our next alpha on that new system 19:47:45 i can point you to the right branches and the right incantations :) 19:48:17 nice 19:48:37 very exciting progress, thanks to boklm and you 19:48:49 i guess waht we should do is writing a mail to tbb-dev 19:48:53 once this hits nightly 19:49:01 both for our potetnail builders 19:49:09 as other projects using that 19:49:29 like pospeselr's and Jeremy_Rand_Talos 19:49:32 ' 19:49:37 yep 19:50:10 that's it from my side for that point 19:50:44 great 19:50:51 i look forward to trying this 19:51:06 thanks 19:51:23 dunqan: do you want to discuss S30? 19:51:31 * Jeremy_Rand_Talos is looking forward to this too 19:51:41 Yep, thanks! 19:51:48 I was just wondering how the S30 quickstart work is going / if you have a rough timeline of when you'll have builds ready for UI review / and if you need any further UX & design input atm 19:52:21 I'm aware I have this on my plate too, which I'm hoping to get around to *after* this week: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345 19:52:26 I'll let acat take that question :) 19:53:49 (if acat is still around :) ) 19:53:52 not sure when exactly i'll have a build ready for UI review, but i think not this week :) 19:53:53 probably end of next week 19:54:40 np, just ping me here or on git (@duncan) whenever you have something :) 19:54:48 sure! thanks 19:57:09 sorry, just digging up a ticket 19:57:18 dunqan: this reminds me about tpo/ux/research/-/issues/11 19:57:30 tpo/ux/research#11 19:57:53 Yes! I owe you a mockup for that 19:57:59 I'm actually working on it right this second 19:58:13 we don't have much time for getting it into the next release in two weeks 19:58:24 but we can probably still squeeze it in 19:58:26 okay 19:58:43 the sooner you can post that, the better :) 19:58:57 thanks 19:59:01 np, will be with you for review by tomorrow morning :) 19:59:05 thanks again 19:59:13 okay, great 19:59:36 okay, and the last (quick) discussion item 19:59:44 "Reviewer field in MRs? 19:59:46 " 20:00:13 we got htat new capability 20:00:17 (i think this is a GeKo topic) 20:00:20 *thatt 20:00:24 yeah 20:00:36 i saw the network team seems to want to work aounrd the issue 20:00:52 that the assigned reviews do not show up in the MR dashboard 20:01:05 by having a custom query 20:01:31 containing both the assigned MRs and those with the Reviewer field set to oneself 20:01:35 or something 20:01:43 and i started wondering what we want to do 20:02:02 i filed https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/88 20:02:12 but i doubt this will get resolved fast 20:02:31 likely needs an upstream fix 20:02:43 i can go either way 20:03:47 hrm 20:05:01 i guess the benefit of this new thing is that the "Merge requests" button now shows you all of your open MRs 20:05:12 that's a weird trade-off, though 20:05:27 one can see it that way, yes 20:06:34 https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#reviewers-for-merge-requests 20:06:42 apparently this is still a half-baked feature 20:06:48 and there are improvements coming 20:06:54 we got the first half :) 20:07:35 maybe we should wwait and continue using the assigned field for requesting review 20:07:41 until this feature is more useful for us 20:08:31 we don't pre-emptively open MRs without an existing patch 20:09:12 so i'm not sure we'll even have a MR where the assigned user is different from the creater 20:09:57 if we used a different work flow (or if we change our workflow in the future), then I can see this additional field becoming useful 20:10:43 s/even have/ever have/ 20:11:00 do you feel differently? 20:11:19 nope 20:11:45 * acat neither 20:11:51 but i am flexible here. i could get myself used to that half-baked Reviewer thing 20:12:14 yeah, me too 20:12:22 but i don't see much reason right now 20:13:19 let's continue with the current workflow, and we can re-evaluate in the future if that seems like a good idea 20:14:15 wfm 20:15:21 great 20:15:47 okay, and with that, thanks for staying here an extra 15 min 20:16:02 have a good week, everyone 20:16:07 #endmeeting