15:02:42 <PieroV> #startmeeting Tor Browser Weekly Meeting 2024-02-12
15:02:42 <MeetBot> Meeting started Mon Feb 12 15:02:42 2024 UTC.  The chair is PieroV. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:42 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:02:53 <dan_b> pad: https://pad.riseup.net/p/tor-tbb-keep
15:05:36 <richard> o/
15:05:43 <PieroV> o/
15:05:45 <jagtalon> o/
15:05:49 <dan_b> this was one of the weeks we are supposed to break down our work by % for time tracking was it? by meeting or "on scheduled work or... "reviews"?
15:05:51 <richard> sorry had  an unexpected amount of obligations this morning
15:06:00 <boklm> o/
15:06:04 <PieroV> richard: do you want to take it from here? I've started the bot, but I'm still updating my pad section
15:06:06 <Jeremy_Rand_36C3[m]> oh hey richard !
15:06:41 <richard> dan_b: yeah, please track your %'s spent on ${tasks}, depending on what your tasks are
15:07:14 <richard> may be useful to spit by development/feature work, reviews, meetings+communications, bugs/unexpected maintenance, and release prep
15:07:18 <richard> split by*
15:09:03 <richard> (and again the purpose here is accurately estimate how much 'free' time we have as a team for development and feature work)
15:10:20 <thorin> back
15:11:13 <PieroV> Speaking of release preparation, this week is release week
15:11:20 <PieroV> Well, not really release, but release preparation week
15:11:22 <richard> so this week we have a scheduled rebase to 115.10 iirc
15:11:25 <richard> yes!
15:11:27 <PieroV> .8
15:11:36 <PieroV> I've been trying continuous rebase on alpha
15:11:46 <PieroV> (as a concept, with some manual effort, not automatic yet)
15:11:56 <PieroV> So, the alpha rebases should arrive pretty soon
15:12:08 <PieroV> And the stable rebases usually are trivial
15:13:23 <richard> i'll plan on release prep'ing Mullvad Browser 13.0.10 tomorrow once it's rebased to build overnigh
15:13:46 <PieroV> wfm
15:14:47 <richard> PieroV: could you give a overview of what we (you me boklm) chatted about w/ regard to a potential long-term strategy re major ESR rebases
15:15:15 <PieroV> Yes, I also added to today's discussion points :)
15:15:25 <richard> well excellent
15:15:47 <richard> i'll hand it over to discussion points then as i have no other announcements or discussion points
15:16:14 <PieroV> So, I would like to have a "continuous rebase" pipeline (possibly linked to tests) for the current ESR
15:16:41 <PieroV> But I wondered if it's possible to actually make something to rebase on top of mozilla/release more often
15:17:51 <PieroV> And to get started with that, I wondered if we can reach 128 by rebasing version by version, instead of rebasing all at once when 128 reaches nightly
15:18:18 <PieroV> And especially, if there's a smart way to detect the exact commits that conflict while doing so
15:19:14 <PieroV> Long story short, I didn't succeed so far to find a good strategy to achieve this
15:20:46 <PieroV> However, I did have some free hours in a train and in a bus, and I've started rebasing version by version
15:20:56 <PieroV> Onto the FIREFOX_MAJOR_0_RELEASE tag
15:21:30 <PieroV> In around 5-6 hours I went back to 115's fork point and rebased up to 120
15:21:48 <PieroV> Some majors were very easy, whereas some other versions are harder
15:22:20 <PieroV> But so far it seems to me that the range-diff and diff-of-diffs were much easier to understand when you go version by version
15:22:30 <PieroV> Compared to a 13-version big skip
15:22:40 <Jeremy_Rand_36C3[m]> PieroV: yes this makes sense
15:23:01 <PieroV> And those 5-6 hours included some failed experiments (maybe 7 hours, at most)
15:23:18 <PieroV> It makes less than 1 hour and a half on average, which could be split during the year
15:23:29 <PieroV> Well, with two caveats
15:23:33 <richard> how much time do you reckon it took per-version? did you experience a lot of variability between versions in terms of difficulty to resolve conflicts?
15:23:39 <PieroV> The first one is that I didn't build
15:23:48 <PieroV> I've just rebased and self-reviewed the rebases
15:24:17 <PieroV> But once we have some CI mechanisms they could take care of building (+ linting)
15:24:24 <Jeremy_Rand_36C3[m]> PieroV: seems like better test coverage for Tor Browser's patches might tie into this?
15:24:32 <PieroV> Jeremy_Rand_36C3[m]: definitely
15:24:38 <PieroV> I have so many ideas about this
15:25:03 <PieroV> But one of the ideas it that we could run incremental builds whenever we change something on the rebase branches
15:25:12 <PieroV> And then run tests
15:25:40 <PieroV> The second caveat is that I dropped two patches (well, one and a half)
15:25:54 <PieroV> One is the change to make HTTP onion forms look like HTTPS
15:26:08 <PieroV> It's a small one, but it would've required me to at least build
15:26:17 <Jeremy_Rand_36C3[m]> PieroV: yeah this sounds like an area that would be a nontrivial initial workload, but would yield a massive payoff medium to long term
15:26:19 <richard> that patch tends to need frequent updating iirc
15:26:41 <PieroV> Actually it's in the onion service security expectations
15:26:49 <PieroV> So, I didn't drop the whole patch, only that part
15:26:56 <PieroV> Which is kinda small
15:27:12 <PieroV> I'm sure in a few hours we can re-implement it
15:27:35 <PieroV> (and longer-term see what stuff Moz already accepted behind the pref to make onion treated as HTTPS)
15:27:58 <PieroV> The second patch I had to (half) drop is the custom switch
15:28:22 <PieroV> Moz did a big refactor there, and I'm not sure on how the button looks like after that change
15:28:52 <PieroV> But it's quite self-contained, and probably easy to fix
15:29:15 <PieroV> Apart from that, I noted to myself that we'll need a few changes in prefs, for example (but not that many)
15:29:24 <PieroV> In general, I've kept a log of all the conflicts
15:29:34 <PieroV> Which can help to reverse-engineer the time I took to deal with each version
15:29:59 <PieroV> Because I divided it by version (this should partially answer one of richard's questions)
15:30:18 <richard> well
15:30:25 <PieroV> The log itself is a 420-line markdown file
15:30:40 <PieroV> With the 80-columns margin respected and many empty lines
15:31:03 <richard> given how little relative time it took to get that much progress, maybe this is something we should start doing as part of the monthly rebase process
15:31:24 <richard> after esr128-based brwosers are released
15:31:40 <PieroV> So, tomorrow we'll get the tags for Firefox 123
15:31:55 <PieroV> I've done this during some dead times I had on my own
15:32:18 <PieroV> But if I can start working on that after the installer, I could try what following beta tags is like
15:32:47 <PieroV> Because it might be that some "continuous rebases" might succeed automatically
15:33:04 <PieroV> I was thinking of beta tags because they're an easy enough way to split the codebase
15:34:21 <PieroV> As for the continuous
15:34:29 <PieroV> rebase experiment I've done last wek
15:34:46 <PieroV> I think the easiest implementation would let the bot do all the cherry-picks
15:35:12 <PieroV> Because I've tried also the git-cherry command, but didn't work very well for in our codebase
15:35:48 <richard> how do you mean?
15:35:59 <richard> let the bot do all the cherry-picks
15:36:13 <PieroV> Yes, I was thinking to the next steps already :)
15:36:37 <PieroV> Rebasing tor-browser on top of the updated base-browser branch, and shuffle patches around
15:37:34 <PieroV> I will have to look if someone invented some strategy to resolve conflicts when you know the final result already
15:38:17 <PieroV> (one of my attempts was cherry-picking and stopping at the first conflict, and then start rebasing, since cherry-pick is much cheaper than rebasing 180 commits every time)
15:38:40 <PieroV> But generally speaking, I got conflicts earlier (which is expected, but I somehow hoped that git would do some magic for me)
15:40:49 <PieroV> Also, I was thinking that the bot should somehow checked if you force-pushed to its working branch before doing anything
15:41:00 <PieroV> (e.g., if you solved conflicts manually)
15:41:19 <PieroV> And this is the scenario in which I expect it to break if you start also cherry-picking commits it didn't cherry pick yet
15:44:01 <richard> so long term, i would love to spread out the major esr release work more thinly, across more people over more time
15:44:41 <PieroV> That would make sense, especially if we can somehow automate the majority of it
15:44:43 <richard> in the past that hasn't really been an option due to all the other things we had to squish into the same time-frame
15:44:49 <richard> indeed^
15:45:12 <richard> we also need a similar examination of what would need to happen for firefox-android
15:45:32 <PieroV> As Jeremy said, once we're on par (more or less) with Moz, it might become much easier
15:45:40 <Jeremy_Rand_36C3[m]> yeah it sounds like improving the automation here would open up some good possibilities
15:45:47 <PieroV> Right, I haven't worked on Firefox Android yet
15:45:49 <richard> especially testing
15:45:52 <richard> >:[
15:45:56 <PieroV> But we'll need a better patchset first
15:46:02 <richard> yeah agreed^
15:46:14 <PieroV> Not sure I've said that by voice to richard and boklm at FOSDEM or to everybody
15:46:44 <PieroV> But I think this year we might avoid the traditional strategy on Android
15:46:56 <PieroV> And instead try to analyze and split what the patches do first
15:47:19 <PieroV> And just re-implement htem
15:47:26 <PieroV> The risk is to lose some of them
15:47:42 <PieroV> But this is a concern also for the desktop rebase spread in major versions
15:47:59 <PieroV> It's easier to review, but maybe errors could accumulate over a much higher number of rebases
15:49:09 <Jeremy_Rand_36C3[m]> PieroV: yes. And it sounds like better test coverage would decrease that risk too
15:49:49 <PieroV> Yep. On the other hand, RR is hard
15:49:59 <PieroV> And we don't want too much stress on the team
15:50:16 <PieroV> But not actually releasing might be enough not to create too much stress
15:50:44 <PieroV> Even though eventually we could also spread audits all over the year
15:51:05 <Jeremy_Rand_36C3[m]> Right, as I said, this sounds like a nontrivial effort up-front but a big payoff in terms of effort long-term
15:51:34 <PieroV> Anyway, I've seen dan also has a point for today?
15:51:46 <PieroV> (sorry this took so much time, I've noticed only now)
15:51:53 <richard> :)
15:51:53 <dan_b> lol no worries
15:51:58 <richard> alright dan you got 6 mins
15:52:14 <dan_b> just wondering if ppl wanted to discuss the tor-expert-bundle .aar ification in real time quickly?
15:52:34 <PieroV> I've added a few comments to the MR
15:52:40 <richard> yes me too^
15:52:47 <dan_b> proposals so far from comments include: tor-expert-bundle for android dropping the .tar.gz and only doing a .aar and making a new project that consumes it and then produces the .aaar
15:52:49 <PieroV> Long story short, my biggest concern is that maybe we don't want to do it in the expert bundle
15:53:17 <PieroV> Yep, I don't know if we actually have consumers on Android
15:53:23 <PieroV> I think the majority of consumers are on Windows
15:53:30 <dan_b> i'm pretty sure projects like tor-android-service spit out two files so i can prolly make tor-expert-bundle do a .tar.gz AND a seperate .aar?
15:53:31 <PieroV> And I know someone on macOS
15:53:42 <richard> (alternatively the 'tor expert bundle' project could output a .aar for android rather then the current .tar.gz)
15:53:48 <PieroV> dan_b: you can create a directory instead of a file
15:53:52 <PieroV> Like the firefox project
15:53:54 <dan_b> gotcha
15:53:56 <PieroV> And maybe also the browser project
15:53:58 <richard> all the desktops skus are consumed by ricochet-refresh :)
15:54:06 <PieroV> At that point you can output both the tarball and the aar
15:54:30 <PieroV> But for aars a Gradle/Maven repo would be best
15:54:44 <dan_b> ok that seems the least commital approach. do both, seperatly, in tor-expert-bundle for now, and we can cut down on one later if need be
15:54:47 <PieroV> But I think we should include micah in the conversation for that when he has some time
15:55:08 <PieroV> wfm
15:55:11 <dan_b> 👍
15:55:15 <dan_b> thanks for your time! 😄
15:55:39 <PieroV> We are close to the hour, can I call the bot? :)
15:55:49 <dan_b> do it!
15:55:49 <Jeremy_Rand_36C3[m]> yeah nothing on my end today
15:56:13 <Jeremy_Rand_36C3[m]> Thanks for handling the bot today PieroV !
15:56:18 <richard> :)
15:56:19 <PieroV> Okay, thanks everyone!
15:56:22 <PieroV> #endmeeting