15:03:04 <richard> #startmeeting Tor Browser Weekly Meeting 2023-01-09
15:03:04 <MeetBot> Meeting started Mon Jan  9 15:03:04 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:03:20 <richard> hello everyone, the pad per usual: https://pad.riseup.net/p/tor-tbb-keep
15:05:17 <richard> Hope you all had a good winter break
15:06:03 <richard> Happy to report no emergency Tor Browser releases were required over the break (though I did see your no-script one the oher day ma1 :) )
15:06:03 <boklm> (or summer for those on the other side of earth)
15:06:33 <richard> indeed inded
15:07:14 <richard> So only one announcement from me as we get back into things
15:07:59 <richard> we should be focusing our efforts on the initial s131 release later this month which will come after our usual rebasing for stable and alpha
15:08:43 <msim> exciting :D
15:09:23 <richard> so if you haven't already, please pick up any issues from this query: https://gitlab.torproject.org/groups/tpo/applications/-/boards?label_name[]=Sponsor%20131&label_name[]=Next
15:09:48 <richard> or ping me if there's something missing or need further clarification
15:10:00 <richard> um apart from you msim, keep on with webrtc please :)
15:10:06 <dan_b> I think you mentioned a 12.0.2 release coming soonish?
15:10:30 <richard> yep so the esr release is scheduled for the 17th iirc, so we should be releasing 12.0.2 around that time
15:10:44 <richard> and alpha shortly after that, and s131 initial 'alpha' shortly after that
15:10:49 <dan_b> aaah i see
15:10:52 <dan_b> cool
15:11:00 <richard> um, i'll update the release calendar today
15:11:06 <msim> richard: sounds good :)
15:11:35 <PieroV> richard: should we try to do the stable + alpha rebases in parallel like we discussed a while ago?
15:12:12 <richard> yeah that should be a good plan
15:12:25 <PieroV> I think the plan was to include people in the calendar
15:12:38 <richard> we should also try parallelizing/distributing the release prep this go around
15:12:41 <msim> richard: when's the s131 release planned for?
15:12:45 <richard> yeah exactly
15:13:03 <richard> msim: after tor browser alpha once we've cleared the must-hvae blockers
15:13:09 <msim> oki cool
15:13:13 <richard> primarily branding swaps at this juncture
15:13:24 <PieroV> I'm sorta working on that, too
15:13:39 <PieroV> Of course not on the right assets, but on creating new branding directories for tor browser
15:13:52 <PieroV> Then we should be able to use that to create S131 branding directories
15:14:14 <PieroV> (sorta because I was doing that before the break, but my branch doesn't build now :| )
15:14:14 <richard> yeah we're still waiting UX for the final set of assets
15:15:06 <richard> PieroV: once you've done the branding directory work, can you make a final asset list that we'll need from UX?
15:15:23 <PieroV> richard: sure thing.
15:15:39 <PieroV> I think I'll manage to work on that either tomorrow afternoon (CET) or on Wednesday, though
15:16:23 <henry-x> ma1: are you still working on tor-browser#32308 ?
15:17:02 <richard> oh I also mentioned this in IRC the other day, but I'm back on NA hours until after the OTF summit at he end of this month, so if I'm on at weird hours that's why :p
15:17:06 <ma1> henry-x, I consider it fixerd actually
15:18:00 <ma1> Notwithstanding Thorin comment, the main problem was that the size actually jittered. Now there's just one jump which might be annoying, but is not a fingerprinting issue anymore.
15:18:50 <richard> msim: if you @tom in that MR that should ping tjr
15:19:15 <msim> richard: ok cool :D
15:19:32 <henry-x> I think we could solve the jumping content during a horizontal resize by start-aligning the content whilst we are still resizing. There would be an initial snap at the start and the end, but the in between steps would be smoother
15:20:36 <ma1> henry-x, I thoght so much as well (leaving the animation suggestion aside, because it would be a risky readdition of complexity). Maybe using a timeout to restore the centering when idle?
15:22:13 <henry-x> Animation would be harder, unless firefox supports transitioning between place-content, but I doubt it. The start align should be easy, assuming we reliably get a notification at the start and end of a window resize
15:24:55 <richard> ok I don't have anything else for this meeting, so I'm happy to close unless there's anything else the group needs to discuss
15:25:33 <henry-x> nope
15:25:33 <msim> nothing from me
15:25:41 <PieroV> I had a point
15:25:48 <PieroV> (but didn't remember of it lol)
15:26:03 <PieroV> It's just a request actually :)
15:26:41 <PieroV> I'd like if we could take as a policy to always remember to add the issue number also to fixup commits
15:26:51 <PieroV> (I'm actually part of those who forget :P)
15:27:05 <richard> yes 100%
15:27:12 <PieroV> It helps making sure that we're not missing any issues in the release preparation
15:27:23 <PieroV> And since we're talking policies
15:27:23 <henry-x> What do you mean? In the merge request, or in the commit description?
15:27:29 <PieroV> henry-x: in the commit description
15:27:40 <PieroV> So that you can see it in the git log/GitLab commits page
15:27:49 <richard> fixup commits should be commited like a so: git commit --fixup hashhashhash -m "Bug 12345: fixes the thing"
15:28:14 <richard> def help to have easy to access context also when resolving merge conflicts during the rebase
15:28:34 <PieroV> (or git commit --fixup and then git commit --amend)
15:28:52 <henry-x> ok
15:29:37 <richard> alright
15:29:39 <PieroV> And also another request
15:30:13 <PieroV> Please rebase branches and change the patches in two separate force pushes
15:30:44 <PieroV> It helps reviews :)
15:30:54 <PieroV> (no more requests from me for today :))
15:31:16 <msim> PieroV:  i usually rebase with gitlabs inbuilt rebase button thing
15:31:20 <msim> is that okay?
15:31:24 <PieroV> yes
15:31:51 <richard> true, that should be less of a problem now that we have the magical rebase button
15:32:03 <richard> though i guess we've always had that for MRs
15:32:07 <dan_b> what does doing it in two force pushes do in gitlab ui?
15:32:25 <PieroV> dan_b: GitLab can show the differences between two force pushes
15:32:33 <dan_b> aaaah huh
15:32:37 <PieroV> (in changes you can set the versions you want to compare)
15:32:38 <henry-x> I think pierov means if you rebase locally and make some other changes in one push
15:32:46 <PieroV> yes, exactly
15:32:47 <dan_b> gotcha
15:33:35 <henry-x> phabricator was good at handling that. It would only show the changes to the file that the (final) commit actually touched
15:34:52 <henry-x> but that is because it handled each commit separately, rather than allowing several commits per request
15:35:19 <PieroV> it also targets HEAD automatically, or something like that I think?
15:35:48 <PieroV> But we need to force-push if we want to change the target branch :/ phabricator is great also at showing code movements
15:36:46 <richard> well i hope everyone has a great week
15:37:03 <richard> i'm def super excited for the next few months
15:37:16 <richard> later everyone o/
15:37:18 <msim> o/
15:37:18 <richard> #endmeeting