18:02:06 #startmeeting Tor Browser Release Meeting 2022-10-31 18:02:06 Meeting started Mon Oct 31 18:02:06 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:11 bam 18:02:13 welcome everybody 18:02:20 pad: https://pad.riseup.net/p/tor-browser-release-meeting-keep 18:02:21 wb 18:04:58 ok ok 18:05:00 discussions 18:05:39 11.5.7 should just be a targeted release to enable seamless locale to multi-locale transition w/o having to go through english first 18:05:52 so once that patch is in i'll start release preps 18:06:20 I've tested the sticky prefs locally to see how they work 18:06:46 They should do what we want, but we need to force a pref write 18:07:04 So, we need to modify projects/tor-browser/build in maint-11.5 to make the lang pref sticky 18:07:28 so what's the high level idea here, we backup the user's locale in 11.5.7 so it can be restored in 12.0 18:07:29 Then we need to modify tor-browser to write the intl.locale.requested at least once 18:07:53 richard: yes. Sticky prefs are written to prefs.js also when they match the default value 18:08:08 Normal prefs don't, and are just removed from that file when they match the default value 18:08:50 ok 18:09:22 sounds like we have a plan there 18:09:34 Yes, but we need a tor-browser-build issue + MR before the rel prep 18:09:55 yes all the usual 18:10:17 No, I mean for the tor-browser/build changes 18:10:45 (as the projects/tor-browser/build script) 18:11:31 ah right 18:11:42 the locales are injected in tor-browser-build right? 18:11:48 richard: yes 18:11:53 in stable 18:11:56 It appends to 000-tor-browser.js 18:12:01 Also in main 18:12:13 (if multi-lingual is disabled) 18:12:38 We still have the possibility to enable/disable multi-lingual builds 18:12:39 sounds like we have code to purge in main then :D 18:12:56 unless there's a good reason to keep them around 18:12:57 12.5 to be on the safe side? 18:13:05 oh yes for sure 18:13:10 after 12.0 18:13:16 wfm 18:15:14 is there going to be any manual migration logic needed in the 12.0 series to migrate the pref, or does this 'just work' already using mozilla stikc pref machinery? 18:15:47 richard: I expect sticky prefs will work 18:16:01 They are made to keep prefs when switching from a channel to another one, that is our case 18:16:17 ok great 18:16:17 https://udn.realityripple.com/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences#Sticky_Preferences 18:16:24 onto 12.0a5 then 18:16:38 wait 18:16:45 The second point was different from this 18:16:55 oh ok 18:17:22 It was: during today's meeting, we discussed about people updating from 11.5.6 (or earlier) directly to 12.0 18:17:44 I.e., skipping a pair of months of updates or mroe 18:18:37 We might be able to do something for them, but it would involve creating incrementals for localized channels even though we use multi-lingual packages 18:19:12 ah so bringing back the hack i whipped up over the weekend 18:19:20 Not really 18:19:32 We should customize the 000-tor-browser.js for each locale, I fear 18:19:55 So we should build the localized packages only to create the mar 18:20:38 + complications to switch from 12.0 to 12.0.1, if we stop doing that at 12.0.1 18:21:18 hmm 18:21:27 personally, I'm not sure it's worth the effort 18:21:40 and there's the question of how long do we maintain that 18:21:57 yes 18:22:08 iirc from one of the gitlab threads 18:22:23 boklm mentioned that it upgrade to English, becaues his system language is english 18:22:46 richard: yes 18:22:52 so am i right in understanding that currently people upgrade from older versoins will upgrade into their system language? 18:22:52 In tor-browser#17400 18:23:12 richard: you are right 18:23:50 honestly that seems fine to me 18:24:41 ok 18:24:44 okay 18:24:52 can we detect if a user has upgrade from a stable version from *before* the lang pref was saved? 18:25:06 like can we tell we're in the fallback case 18:25:09 richard: maybe we can 18:25:18 But we wanted to show a message in 12.0 in any case 18:25:20 Also to new users 18:25:36 See tor-browser#41378 18:25:43 (and if so, do we want to provide some UX syaing hey change your preferred lagnauge in about:preferences#whatever 18:25:55 If I understood correctly, we want to show that bar at the first start 18:26:04 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41378#note_2845190 18:26:28 oh perfect 18:26:58 yeah i vote we just have that UX if he pref isn't set (either by old -> new migration, or first ever launch) 18:27:06 and just avoid all of that complicated build stuff 18:27:18 yes, we can check if a pref isn't default 18:27:38 There's a method of Services.prefs 18:27:57 Or even easier: we can check if intl.locales.requested is empty 18:28:02 (which means use OS language) 18:30:51 ok sounds lik ethere is a path forward there 18:31:10 +1, we can proceed with the 3rd point for me :) 18:31:32 let's just make sure henry-x is at least looped in on the UX for an accessibility review 18:32:03 if they don't just end up implementing the feature entirely 18:32:10 ok so for 12.0a5 18:32:20 my take is that we should release as soon as we have macOS universal bundles 18:32:47 okay, I think its main purpose is to test the updater 18:32:53 that is the last remaining major feature for 12.0 18:33:10 yes 18:33:10 richard: could you please do a last pass through the board? 18:33:24 yeah i can do that 18:33:29 So that we have only possible blockers for 12.0a5 in ~Next? 18:33:33 i did a pass friday or thursday 18:33:45 ok good plan 18:33:52 yes, but we have 29 issues in ~Next 18:34:00 Like "Use locked prefs" 18:34:05 anything that's not a real blocker can be downgraded to ~Backlog 18:34:09 I think that could be even future 18:34:19 hm true 18:34:46 tor-browser#40899 18:35:32 the short story of that issue is that we disable already a lot of stuff 18:35:42 But I think we should remove them from about:preferences, too 18:35:54 yes 18:36:18 we should probably have a single about:preferences purge commit 18:36:22 seems easy enough to bunch all together 18:36:46 stick it after the base browser preferences commit? 18:37:09 or maybe we en dup needing two purges, one for base and one for tor-browser 18:37:18 yeah, works for me 18:37:26 There are a couple of interesting things to disable 18:37:33 1. notifications 18:37:34 regardless, not a blocker for 12.0 but a nice to have 18:37:49 2. credit cards and addresses 18:38:15 The two latest items 18:38:30 of the first section 18:39:58 let me review this entire ticket offline and respond there 18:40:07 wfm 18:40:07 overall this looks like a lot of good stuff 18:40:31 I will say I am actually excited for mullvad-browser to be my daily driver 18:40:52 :) 18:41:54 ok and finally multi-lingual buils 18:41:57 are in fact 18:41:58 excellent 18:42:07 \o/ 18:42:23 Let's hope users are excited too 18:42:32 well yeah hopefully 18:42:44 From a build point of view I hoped for more 18:43:05 It still took a while to build the various browser projects 18:43:11 we can probably expect like, an hour turnaround from unsigned -> published in 12.0 18:43:20 But I am very happy about signing timings 18:43:28 that is true 18:43:42 Also, browser has become a parallelizable project 18:43:51 Since it uses single threaded compression 18:44:05 build performance in general may be something we can work on in the future 18:44:30 richard: what was previous time? 18:45:14 end to end signing -> publishing was around 12 hours depending 18:46:16 a bit less if one has a persistent internet connection and are paying attention 18:46:47 So, very nice improvement 18:47:02 yeah 18:47:02 stellar 18:47:39 I don't have anything else for this meeting 18:47:45 alright sam 18:47:47 same* 18:47:49 (but can we make it 1 hour in the calendar? :)) 18:47:59 It's still 30 mins 18:48:03 oh 18:48:06 yeah can do 18:48:39 3endmeeting 18:48:42 #endmeeting