16:04:25 <morganava> #startmeeting ApplicationS Team Meeting 2025-01-21
16:04:25 <MeetBot> Meeting started Tue Jan 21 16:04:25 2025 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:25 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:04:26 <morganava> there we go
16:04:27 <morganava> ok
16:04:42 <morganava> Hi everyone, the pad per usual -> https://pad.riseup.net/p/tor-tbb-keep
16:05:01 <morganava> please update your todos and add discussion topics as usual
16:05:17 <morganava> iirc PieroV wants to chat about the RR rebase schedule :)
16:05:24 <PieroV> Yes
16:05:31 <PieroV> But first I had another point in the pad
16:05:36 <PieroV> Hopefully a quick one
16:05:42 <PieroV> Not very important though
16:06:27 <PieroV> That is: shall we update the MR template to remove "emergency" from a backport reason?
16:06:39 <PieroV> Usually we want to backport all (or almost all) security issues
16:08:29 <morganava> you mean replace "emergency securtiy update' with just 'security update' ?
16:08:43 <PieroV> Yes, or add one for non-emergency
16:08:57 <PieroV> So that it's more clear that it's something that can wait for testing in alpha
16:09:50 <morganava> yeah ok, i'd say either remove emergency from that line or add a separate non-emergency (i.e. ordinary lol) security backport
16:10:24 <morganava> i'm not sure there's much point in having two separate entries, esp since the timeline is handled in the previous checkboxes
16:10:45 <PieroV> Okay, will open a MR for that
16:11:39 <PieroV> About the RR schedule
16:12:21 <PieroV> If we start this week (well, I've already started, but not finished 129) and manage to keep a pace of 1RR rebase per week, we arrive with Firefox 137 around March 24
16:12:40 <PieroV> Then, March 31 Firefox 138 ends nightly, and we can start with that
16:13:30 <PieroV> And then Firefox 139 goes beta on April 28, which is one week after the expected 14.5 release
16:14:10 <morganava> I just pushed a (hopefully) final revision of the RR rebase process issue template (tor-browser!1307)
16:14:36 <PieroV> From last year, we've seen waiting for the target RR to go beta might be too late, and instead it's better to start the deep review a bit earlier, so it makes sense to do it with 139, after all it'll include be 11 versions out of 12
16:14:54 <morganava> the only unaddressed thing atm is a specification/details for the version-to-version documentation/fcommentary
16:15:22 <PieroV> Also, we'd be able to focus only on 14.5 in the last period before the release, or to give us some time for releases that are particularly difficult
16:16:18 <morganava> PieroV: in your experience, is a weekly rebase  cadence likely to be achievable?
16:17:36 <PieroV> It depends on the reviews
16:18:27 <PieroV> And also on who rebases, it still isn't too clear to me who the task is going to spread with
16:18:57 <PieroV> If you're fast to rebase, it takes less than 1 working day with a self-review
16:22:28 <ma1> PieroV, so by "review" you mean actual review of the MR rebase, not of the RR changes?
16:23:02 <ma1> I mean, diff-of-diffs, range-diff and maybe build and check nothing breaks, right?
16:23:15 <PieroV> ma1: yes. A review that shouldn't be too deep imho, it should catch the big errors
16:23:16 <morganava> yeah the RR changes are a seperate lagging issue
16:23:21 <dan_b> another way to look at it is, if a week cadance isn't acheivable, if it takes longer per one, isn't that more reason to start early not less?
16:23:33 <morganava> dan_b: yeah exactly
16:23:50 <PieroV> dan_b: yep. Also, it's actually 1.5 week on average
16:24:03 <dan_b> and if its faster, and we get caught up early, "oh no, how horri-.. wait no thats read"
16:24:05 <dan_b> rad*
16:24:07 <morganava> i think we should get started asap even if the outlined proces isn't perfect, we can fix it as we go
16:24:22 <PieroV> 1 week to account for surprises
16:25:05 <morganava> is anyone interested in being added to the pool of people doing the rebases?
16:25:41 <morganava> could also be a good opportunity to get newer people up-to-speed on the process if paired with folks who do rebases all the time
16:26:27 <brizental[m]> you can add me
16:27:00 * ma1 assumes being already in the pool :)
16:27:12 <morganava> ;)
16:27:17 <morganava> and PieroV lol
16:27:41 <PieroV> Yeah, I thought usual suspects for the ESR rebases were automatically in the pool :)
16:27:51 <morganava> hehe
16:27:58 <clairehurst> I'd be happy to help where I can
16:28:07 <morganava> :)
16:28:23 <morganava> dan_b: are you basically full up on VPN stuffs for the rest of this release cycle?
16:28:53 <dan_b> i'm actually trying to find that out
16:33:44 <morganava> also look for security review issues coming down the pipe as well (less urgent than rebases of course)
16:34:03 <morganava> alright, henry-x: what's the deal with tor-browser#41921
16:34:18 <henry-x> tor-browser#41921 introduced a few changes to TorConnect and especially TorSettings. So other developers should keep an eye out for any new bugs or console messages, especially on android which was not tested by me.
16:34:45 <henry-x> basically a big-ish refactor
16:37:17 <henry-x> I just realised that the title of the issue is a bit misleading for what the solution was, so I just edited it
16:37:19 <morganava> ok exciting, i saw those emails come in, is it already reviewed/merged?
16:38:22 <henry-x> only one part left
16:39:44 <morganava> clairehurst: would you mind building/reviewing for Android and make sure evertyhing's working ok there?
16:40:15 <morganava> dan_b: looks like some VPN build stuff may be incoming for you ;)
16:40:15 <henry-x> The most obvious visual change is that if you set quickstart you should no longer get a flash in `about:torconnect` before the bootstrap UI shows. Instead it should just immediately load into the bootstrapping state.
16:40:24 <dan_b> ha yep
16:42:22 <clairehurst> Since its merged is it just testing the latest tag (128.6.0)?
16:42:41 <morganava> clairehurst: HEAD of the current dev branch
16:42:48 <morganava> 128.6.0esr whatever
16:42:52 <clairehurst> cool thanks
16:42:58 <clairehurst> Yeah I can do that
16:44:24 <morganava> ok great
16:44:30 <morganava> if there's nothing else, then let us call it
16:45:36 <PieroV> How many people should review RR rebases?
16:45:50 <PieroV> I mean, one rebases, but there can be as many reviewers as needed
16:46:43 <morganava> yeah, i think it makes sense to probably cc myself and potentially the rest of the main RR crew for signoff, and maybe opportunistically requesting review from folks if there are complications in one of their areas
16:46:43 <ma1> I suppose the aforementioned pool is both for rebasers and rebase reviewers, no?
16:47:17 <morganava> (e.g. cc'ing henry-x if there's localisation or accessibility weirdness, clairehurst for android, etcetc)
16:47:42 <morganava> rest of the main RR crew in a rotating fashion, not everyone all the time^
16:48:53 <PieroV> Sounds good
16:48:56 <morganava> oh henry-x, clairehurst: you can probably skip the YEC retro meeting today if you like, i suspect it's mostly going to be more about organisational/process stuffs
16:49:43 <clairehurst> wfm lol
16:49:45 <henry-x> yeah I figured. I don't really have any feedback either, other than it went quite well from my perspective
16:49:54 <morganava> \o/
16:50:47 <morganava> yeah i'm v happy with our handling of things, it looked great and (mostly) came on when it was supposed to and turned off when it was supposed to
16:50:49 <morganava> so no complaints :p
16:51:24 <morganava> alright, been great as always, have a good rest of your week o/
16:51:27 <morganava> #endmeeting