16:01:17 <morganava> #startmeeting Tor browser Applications Meeting 2025-01-27
16:01:17 <MeetBot> Meeting started Mon Jan 27 16:01:17 2025 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:27 <dan_b> o/
16:01:34 <morganava> today's pad as per usual: https://pad.riseup.net/p/tor-tbb-keep
16:01:50 <morganava> please update with your to-dos and to-dones :)
16:04:33 <morganava> oke
16:04:44 <morganava> PieroV looks like you grabbed the first announcement slot
16:04:46 <morganava> :D
16:04:52 <PieroV> Yep!
16:04:56 <PieroV> So, this is rebase week
16:05:09 <PieroV> We're going to get tags this evening (UTC)
16:05:23 <PieroV> But it also means we're having the release meeting this Wednesday after 10 weeks
16:05:55 <PieroV> The regular release (and associated meeting) would have been Dec 23, but Moz delayed to beginning of Jan and we skipped the meeting
16:06:11 <PieroV> It'd be a great opportunity to check in and see how our objectives for 14.5 are going
16:06:34 <PieroV> (and see if we have to shift priorities and or adjust the roadmap)
16:06:48 <brizental[m]> o/
16:07:06 <PieroV> So, prepare for any updates you want to give there :)
16:07:21 <morganava> yes please^
16:08:23 <morganava> and a couple little things from me
16:09:00 <morganava> last week we finally converged on a rapdi-release process and documented it in the rapid-release rebase issue template
16:09:21 <morganava> i've created issues out to firefox 140 and assigned from the pool semi-randomly
16:10:36 <morganava> each rebase should have (at least) one reviewer responsible for making sure the rebaser dotted all the i's and crossed all the t's, but if you're in the pool please try to keep an eye on the rebase progression throughout the next few months
16:11:00 <PieroV> morganava: I think as a rule we could have the rebaser of V+1 review version V
16:11:00 <morganava> and we can load-balance as makes sense into the future if the assignetns end up not making sense :)
16:11:16 <morganava> that.. actually seems pretty smart
16:11:17 <PieroV> To make sure they know about what happened in the previous version
16:11:55 <PieroV> (even though it's a good idea that everyone keep an eye, as I had to temporarily "embed" upstream changes in a few cases in which our patches built upon backported commits)
16:12:54 <morganava> also clairehurst has volunteered to jump into the mix which is great, can the other senior devs potentially flag a 'friendly' release for her to review (and then take charge of the subsequent rebase)?
16:14:08 <morganava> and finally, i've also created mozilla triage issues and divided them out to the entire time (like we did over the summer)
16:14:38 <PieroV> morganava: I don't know how easy it is to tell what's the most friendly release
16:15:03 <morganava> PieroV: i think by friendly i mean more not unfriendly
16:15:08 <PieroV> We can get a rough number of conflicting files for each release, but it's hard to tell without rebasing at least the previous version
16:15:38 <morganava> e.g. if the entire updater patch is broken maybe we give that to giorgio vOv
16:15:50 <ma1> :)
16:16:02 <morganava> or maybe there will never be a friendly one in which case maybe it's best to pair programming it
16:16:41 <morganava> anyway re mozilla triageing; like last summer, we don't *need* the triages complete until most of the way through the 15.0 release cycle (ignoring time requried to review/fix triaged issues)
16:17:23 <morganava> but in general if you have downtime maybe use it to go through your batch of tickets
16:17:49 <morganava> and like last year it should be as easy as clicking the 'open issue' button in the spreadsheet for suspicious bugzillas
16:18:24 <morganava> (and to be cllear most of the way through the 15.0 release cycle is like late summer)
16:19:47 <dan_b> can you remind me of hte review process or link to the template talking about it?
16:20:01 <dan_b> i saw the spreadsheet 🙂
16:21:05 <morganava> you know, i suppose taht would have been a good thing to document in the issue template
16:21:42 <morganava> ok, so the goal is to have eyes on all of the bugzillas resolved/merged in each of the rapid-release versions
16:22:18 <morganava> we want to flags ones which in some way impact Tor or Mullvad Browser due to interference or interaction with our threat model, feature set, build system etc
16:22:58 <morganava> basically identifying and flagging things like "Bugzilla 123: Disable proxy f it's a wednesday"
16:23:48 <morganava> we don't need to flag every single telemetry feature for instance though
16:24:15 <morganava> wehreas we *would* want to flag 'Bugilla 456: integrate new firebase telemetry system into Fenix'
16:24:30 <morganava> if that makes sense
16:25:21 <morganava> here's the tor browser design doc/threat model as a reminder : https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc
16:26:00 <dan_b> so start with the first unchecked line, skim the linked to title and associated code review, and either create an issue for deeper review or dont? and then either way check off in the spread sheet?
16:27:07 <clairehurst> iirc only check off things that were investigated further
16:27:09 <morganava> right basically, if the title looks obviously interesting create an issue via the burtton in our GitLab, and check the row so others know an issue has already been created
16:27:30 <ma1> kudos to whoever updated that design doc/threat model :)
16:27:53 <dan_b> oh the new "issue button" is handy in the spreadsheet
16:27:55 <morganava> sometimes issues are on the edge and so maybe you spend some time looking into it to determine if it's actually a problem
16:28:05 <dan_b> how will we know when the review is done?
16:28:06 <morganava> in general you shouldn't be spending ore than a handful of minutes on these edge-cases
16:28:18 <morganava> if you still don't know if it's a problem then just create an issue adn mvoe on
16:28:47 <morganava> dan_b: this is just the triage, we will go through all of the created further review issues during the 15.0 release cycle
16:29:33 <morganava> ideally the deeper review issues which we are creating in the triage will be handed off to a domain expert (presuming there is one :p )
16:30:05 <morganava> and your triage will be done when you get to the bottom of the spreadsheet :p
16:30:36 <dan_b> oh there's only one of us assigned per page in the spreadsheet
16:30:37 <dan_b> gotcha
16:31:04 <dan_b> i'll track my progress myself 👍
16:31:11 <morganava> well there's 3 people per version :)
16:31:15 <morganava> but yeah
16:32:02 <morganava> oh also the spreadsheet is publically editable so you follks don't need google accounts , so please don't share it around so we can avoid vandalism
16:32:03 <dan_b> ah k
16:32:34 <morganava> but if you check your mail/gitlab notifiations you should be cc'd on the Audit issues you are assigned to
16:32:50 <morganava> or you can do a quick manual search via the ~"Bugzilla Review" label in gitlab
16:33:52 <boklm> where is the spreadsheet link?
16:34:12 <morganava> it's linked as an internal note in each of the audit issues
16:34:17 <morganava> but i'll share privately one moment
16:34:19 <boklm> oh ok
16:34:28 <boklm> I see it now
16:35:22 <morganava> also shoutotu to brizental for the usability improvements over last summer (e.g. sorting bugzillas by Firefox component so we can minimise context switching)
16:35:45 <dan_b> oh nice, i saw that. thanks!
16:36:22 <morganava> we only have through iirc Firefox 135 (since that's all that's been released so far) so the rest will fill up through April
16:37:30 <dan_b> oh great that makes my 136 and 140 review easy 🥳 I'll mark those done now...
16:37:39 <morganava> >:[
16:37:42 <morganava> hehe
16:38:12 <dan_b> or phrased differently, i can get caught up after only 1 review
16:38:13 <morganava> alright if there's nothing else I'm happy to let you all go :)
16:39:27 <morganava> alright, see you all on the internets o/
16:39:33 <morganava> #endmeeting