14:59:51 <sysrqb> #startmeeting Tor Browser weekly meeting 13 Decmember 2021
14:59:51 <MeetBot> Meeting started Mon Dec 13 14:59:51 2021 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:51 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:54 <sysrqb> Hello!
15:00:02 <boklm> hi!
15:00:02 <PieroV> Hi!
15:00:03 <Jeremy_Rand_Talos> Hi!
15:00:34 <sysrqb> Pad: https://pad.riseup.net/p/tor-tbb-keep
15:01:29 <GeKo> o/
15:02:01 <donuts> o/
15:06:43 <sysrqb> okay
15:06:50 <sysrqb> Happy Monday, everyone
15:07:38 <sysrqb> GeKo: I'm going to ping you after this meeting about the new PGP subkey
15:07:58 <GeKo> sure
15:08:19 <sysrqb> regarding 11.5a1, it should be ready for publication in around 4-5 hours
15:08:33 <sysrqb> GeKo: do you want to create the blog post, or boklm, or me?
15:08:52 <GeKo> ah, you are doing the upload etc. yourself, okay
15:09:09 <GeKo> i thought picking this up after the signing, but that works, too
15:09:48 <GeKo> i can create the blog post but i heard there is some special magic involved these days :)
15:09:48 <sysrqb> it all flows together, but I can hand it off to you, too
15:10:03 <sysrqb> i only synced the packages onto staticiforme, they still need to be synced to the servers
15:10:21 <sysrqb> yeah, the blog post process is more interesting now
15:10:36 <richard> o/
15:10:49 <sysrqb> hello richard !
15:11:03 <richard> yellow
15:11:45 <sysrqb> i went through the new process for the blog on Tuesday, so I can probably do it faster today
15:11:54 <sysrqb> but if anyone wants to learn the new process, then I can help them, too
15:12:21 <GeKo> i think it makes sense if anyone else in the team would learn while we do teh alpha release
15:12:24 <boklm> is there a doc somewhere for the new process?
15:12:38 <sysrqb> boklm: yes
15:12:42 <donuts> yeah it's in the wiki
15:12:43 <GeKo> assuming this will be one of the last times i am helping doing releases
15:13:16 <sysrqb> https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/blog
15:13:22 <GeKo> boklm: do you want to pick that up?
15:13:23 <sysrqb> is the new documentation and process
15:13:27 <donuts> we should probably start tagging release posts as both "applications" and "releases"
15:13:36 <boklm> GeKo: yes, I can pick that up
15:13:40 <GeKo> it's okay if the release gets out tomorrow (morning)
15:13:54 <GeKo> so if that fits better your hours than that's cool
15:14:13 <GeKo> we should make sure, though, that all the permissions for you are in place today
15:14:18 <GeKo> if possible
15:14:30 <GeKo> (i don't know what's needed here)
15:14:45 <sysrqb> yes. the only new permission needed is being added as a maintainer of the blog repo on gitlab
15:15:04 <boklm> ok, I will check permissions today after the meeting, and do the post tomorow morning
15:15:11 <sysrqb> that allows for letting gitlab CI build the project and previewing the blog post
15:15:24 <sysrqb> thanks boklm
15:15:39 <donuts> https://gitlab.torproject.org/tpo/web/blog/-/project_members
15:15:45 <GeKo> sysrqb: so, to get back to your other question. if it's just some knobs for you to push the bundles to mirrors and sync the signed .mar files + update responses, then just go ahead
15:15:47 <donuts> will need to ask tpa to add you
15:16:12 <GeKo> otherwise i can take the signed bundles and go from there
15:16:20 <boklm> ah yes, it seems I don't have permission yet
15:17:30 <sysrqb> GeKo: at this point it's simple, so I can start that
15:17:45 <GeKo> okay
15:17:58 <sysrqb> oh, but this reminds me of the second question I have for you
15:18:15 <sysrqb> you and boklm were the builders of 11.5a1?
15:18:24 <GeKo> aha, my sigs
15:18:26 <GeKo> yes
15:18:29 <sysrqb> yes, please :)
15:18:31 <GeKo> let me upload them
15:18:34 <sysrqb> thanks
15:20:14 <sysrqb> boklm: richard: on another topic, I put some MRs on your plates on Friday. I haven't checked if you already reviewed them
15:20:25 <sysrqb> but, in case you haven't, please look at them early this week
15:20:30 <richard> will do
15:20:41 <boklm> ok
15:21:04 <sysrqb> those should move Android TB onto Fenix94
15:21:33 <sysrqb> (mostly, the tor-browser-build branch still contains some testing commits that we'll drop)
15:23:01 <boklm> sysrqb: hmm, I don't see the MR with reviewer set to me
15:23:27 <sysrqb> okay, i'll look, maybe I messed that up
15:23:33 <sysrqb> thanks
15:23:59 <GeKo> speaking of which, what is the current mr workflow for the team?
15:24:07 <GeKo> PieroV and i wondered this morning
15:24:22 <GeKo> i thought assignee is the one who wrote the patch
15:24:27 <GeKo> and reviewer the one to review
15:24:47 <GeKo> and then one could track state of the mr via labels if needed
15:24:53 <GeKo> does that make sense?
15:25:01 <boklm> yes
15:25:05 <GeKo> i know other teams are doing that this way but am not sure about tor browser
15:25:16 <GeKo> aha, great
15:25:31 <PieroV> I thought assignee would be the one to make the merge, instead... Which I can't do because I do not have permission
15:25:49 <boklm> although we don't always set the labels with the state
15:26:02 <sysrqb> PieroV: Yes, I believe that is the "Gitlab Way"
15:26:31 <sysrqb> and we sorta started following that over the last couple months
15:26:44 <PieroV> I haven't understood, sorry
15:26:51 <sysrqb> but I'm okay with returning to the previous process, as GeKo described it
15:27:27 <PieroV> You mean the assignee being the one making the merge, or me not having the permissions, to have an additional review, since I wrote the patch?
15:27:34 <GeKo> well, i am fine following whatever process exists :)
15:27:40 <richard> turns out i've been doing it wrong this entire time
15:27:44 <GeKo> just let me know which one
15:28:04 <sysrqb> PieroV: Ah, I'm sorry, I mean using "assignee" for the "person who will merge this MR"
15:28:27 <PieroV> Okay, it makes sense
15:29:18 <sysrqb> GeKo: I think we should use the process you described
15:29:38 <sysrqb> when the team was only boklm, richard, and me, we could be a little more flexible
15:29:57 <GeKo> k
15:30:45 <sysrqb> boklm: GeKo: regarding releases and Android, do you remember how the archive webserver sync handles deleted files?
15:31:09 <sysrqb> obviously we can delete entire directories, and they remain on the archive site
15:31:13 <boklm> sysrqb: https://archive.torproject.org/ ?
15:31:16 <sysrqb> yes
15:31:36 <sysrqb> but do you know if we can delete individual files and they remain on the archive?
15:31:46 <boklm> yes, they remain
15:32:10 <sysrqb> okay, great, thanks
15:32:28 <boklm> the sync is done with an rsync whithout the --delete option
15:32:59 <sysrqb> ah ha, good.
15:33:55 <sysrqb> I'm asking because for 11.0.3 we will likely need to delete all of the 10.5.10 files except *.apk*
15:34:05 <sysrqb> until we releaes the next stable android version
15:35:40 <sysrqb> PieroV: I didn't look at the font ticket today, but do you have a patch for the issue?
15:35:47 <GeKo> yes
15:35:50 <PieroV> Yes, I have created a MR
15:35:50 <GeKo> all is good
15:35:56 <sysrqb> excellent
15:36:01 <PieroV> However we had a comment from Mozilla
15:36:03 <boklm> ah, remove 10.5.10 from dist to save space, but keep the *.apk from 10.5.10 as we don't have a new android release?
15:36:13 <sysrqb> boklm: yes
15:36:19 <PieroV> Maybe their way is better (swapping load of bundled fonts with load of system fonts)
15:36:21 <boklm> ok
15:37:01 <PieroV> Also, about fonts, I think we should restore the Noto Sans fonts that have been removed, if the change works
15:37:09 <sysrqb> yes, that sounds good to me
15:37:12 <GeKo> yep
15:37:12 <sysrqb> I agree
15:37:22 <boklm> yes
15:37:55 <sysrqb> Okay, I don't have a strong opinion on how we solve the problem right now
15:38:03 <sysrqb> so I'll let GeKo help guide you on that
15:38:11 <GeKo> PieroV: could you file a ticket for that and check whether things still work after the fonts are back?
15:38:28 <GeKo> whatever mozilla prefers
15:38:28 <PieroV> GeKo: sure
15:39:37 <PieroV> Jonathan Kew already sent a try build, accordingly to his comment
15:40:03 <GeKo> yep
15:40:53 <sysrqb> great
15:41:32 <sysrqb> GeKo: are you planning on putting the patch directly into 11.0.3, after some nightlies?
15:42:40 <GeKo> hrm
15:43:00 <GeKo> maybe. i am not sure yet
15:43:03 <sysrqb> okay
15:43:53 <sysrqb> We could let it bake for some time before backporting
15:43:53 <GeKo> there is the christmas break looming and such and thus not much time to test and not many folks available to fix fallout...
15:44:08 <sysrqb> but I want to make sure donuts and others can set expectatoins, if they're asked
15:44:19 <GeKo> yeah
15:44:20 <sysrqb> yeah, i agree
15:44:30 <GeKo> right now i am inclined to skip that fix for 11.0.3
15:45:03 <sysrqb> limiting risky changes in a stable release sounds good to me right now
15:45:08 <GeKo> but if we really should put it directly into stable we could reconsider
15:45:16 <GeKo> yeah
15:45:21 <donuts> I haven't had any more reports about font issues since the temp fix in 11.0.2
15:45:41 <donuts> if I'm following the convo correctly, we're talking about a perm fix and whether that should wait until after the break?
15:45:53 <GeKo> yes
15:45:56 <donuts> gotcha
15:46:02 <sysrqb> luckily it's isolated to Ubuntu and Fedora
15:46:15 <GeKo> i think we should put the full fix including getting the fonts back into some alpha
15:46:25 <GeKo> and then backport if nothing explodes
15:46:41 <sysrqb> sounds good to me
15:46:44 <donuts> +1
15:46:49 <PieroV> +1
15:47:12 <donuts> is it still possible to release 11.0.3 with windows + snowflake fixes before the break?
15:47:21 <GeKo> yes
15:47:29 <donuts> perfect, ty
15:47:31 <PieroV> I noticed that we have a screenshot with monospace fonts in documentation :)
15:47:35 <GeKo> i thought about building on friday
15:47:42 <GeKo> and we could release on monday
15:48:03 <GeKo> and the windows crashers and snowflake fixes are the only musts i have on my radar right now
15:48:10 <GeKo> if there is more, please tell me
15:48:20 * boklm opened tpo/tpa/team#40552 for blog permissions
15:48:24 <donuts> you're correct :)
15:48:35 <donuts> ty, that sounds like a good plan
15:48:57 <sysrqb> richard: and you're getting close to having a fix for the torconnect button issue?
15:49:08 <GeKo> donuts: it would be cool if you could get windows users in the forum to try out our alpha release
15:49:15 <richard> yeah, figured out the issue Friday
15:49:20 <GeKo> so we can get some real world data about the crash fixes
15:49:28 <sysrqb> richard: i saw a comment about it being related to torbutton/tor-launcher's async-ification?
15:49:28 <richard> but the fix is a bit more wokr than i had hoped
15:49:31 <donuts> GeKo: yes I was thinking the exact same, will try!
15:49:34 <GeKo> and potential fallout before we ship the backout in 11.0.3
15:49:37 <GeKo> great
15:49:41 <richard> yep
15:50:04 <richard> the merging of the input stream's native async and the js level async/await doesn't quite align
15:50:16 <richard> and so we drop errors rather than rejecting (and unblocking awaits)
15:50:56 <sysrqb> that is very confusing, but I believe you
15:51:21 <richard> i anticipate having a poc patch tomorrow
15:51:30 <sysrqb> great
15:51:54 <richard> but yeah, a bit confusing :p
15:52:10 <donuts> to be clear, does the temp windows fix address both the addon and tab crashes? or just the latter?
15:52:19 <GeKo> yes, both
15:52:22 <donuts> ack
15:52:39 <GeKo> but it would be good to get users to test both scenarios :)
15:53:03 <donuts> for sure
15:53:36 <sysrqb> richard: i look forward to seeing what this patch looks like :)
15:53:48 <richard> oh in the short term/in a crunch we can delay when we try to connect the control port to give tor more time to launch/init
15:53:58 <richard> to minimize the liklihood of this happening
15:54:04 <richard> but you know, that is a hack
15:55:14 <donuts> we don't receive a huge volume of reports about this issue, but one consideration is that users who run into it may not be receiving instant support over the break
15:55:15 <sysrqb> if there's a simple patch, then maybe GeKo will take it :)
15:55:29 <sysrqb> and you can test it in nightlies
15:55:32 <donuts> and it completely breaks TB if they do
15:55:44 <sysrqb> but fixing the underlying issue is definitely preferable
15:56:02 <GeKo> +1
15:56:04 <richard> yeah of course
15:57:18 <PieroV> GeKo: I've created tor-browser-build#40399
15:57:19 <sysrqb> Jeremy_Rand_Talos: Your mail is probably waiting for a response from me
15:57:26 <richard> GeKo: if we increase kInitialControlConnDelayMS in tl-process.js (in tor-launcher) from 25 ms to something longer this will delay the "timer-callback" observe topic and thus the initial tor-control port connection
15:57:32 <GeKo> PieroV: ack
15:57:41 <sysrqb> Jeremy_Rand_Talos: I don't think there's a better place for it, right now
15:57:59 <richard> so as it is currently, any user who requires more than 25ms for the control port server/socket to init is hitting this
15:58:03 <Jeremy_Rand_Talos> sysrqb, ok, no worries.  Wasn't really sure what kind of review process that kind of suggestion is suposed to go through.
15:58:07 <sysrqb> Jeremy_Rand_Talos: But my response might be a simple: "Sounds great, please open an issue for it"
15:58:22 <sysrqb> Jeremy_Rand_Talos: I believe we don't have a review process
15:59:01 <GeKo> richard: okay. let's discuss this on the ticket and then we decide how to move forward?
15:59:05 <richard> (though it is possible torbutton which also connects independently elsewhere may also be hitting this and causing other problems)
15:59:09 <richard> mk
15:59:19 <GeKo> i guess it's not too risky to raise the timeout as a hotfix
15:59:43 <Jeremy_Rand_Talos> sysrqb, ok.  Should I just open a GitLab issue for such things in the future, or is the mailing list preferred?
16:00:00 <richard> yeah, i'd say we only do so if a real fix isn't ready soon
16:00:01 <richard> anyway
16:00:45 <sysrqb> Jeremy_Rand_Talos: They're both good. the mailing list is a bit dead these days, but it is a good place overlal
16:00:53 <sysrqb> hrm, I see we're over time
16:00:59 <sysrqb> let's continue in tor-dev
16:01:01 <Jeremy_Rand_Talos> ok.  I'll do the ML.
16:01:07 <sysrqb> thanks everyone! have a good week
16:01:14 <sysrqb> #endmeeting