18:00:49 <donuts> #startmeeting Tor Browser Release Meeting 2022-05-16
18:00:49 <MeetBot> Meeting started Mon May 16 18:00:49 2022 UTC.  The chair is donuts. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:49 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:00 <donuts> pad is here: https://pad.riseup.net/p/tor-browser-release-meeting-keep
18:01:01 <boklm> hi
18:02:21 <donuts> looks like someone's already prepped the pad :D
18:02:31 <PieroV> ;)
18:02:48 <donuts> let's give it a couple of minutes for everyone to finish typing before we get started
18:03:36 <donuts> okay all good?
18:03:41 <PieroV> yes
18:04:41 <donuts> do anybody want to talk about the releases in general or shall we skip straight to the discussion items?
18:04:58 <PieroV> I've added my points as discussion
18:05:14 <donuts> yeah, okay let's skip straight to the first discussion item
18:05:20 <donuts> "11.5a11 risks to be released before 11.5a10"
18:05:26 <PieroV> yep
18:05:37 <PieroV> oh, I forgot to add a problem with it
18:05:42 <donuts> I still think we should consider a new versioning system for android
18:05:55 <PieroV> I think we **must** change
18:06:06 <donuts> yeah, it's really messy
18:06:16 <donuts> what do you think richard/boklm?
18:06:22 <PieroV> and I'd love to make people understand that TBA and TBB are not the same
18:06:45 <PieroV> the versioning scheme is not helping in that. But at least many users understand it
18:06:48 <richard> I have no complaints
18:07:00 <richard> or rather, i think changing is a good idea
18:07:02 <boklm> we almost never have common releases for android and desktop, so it could make sense to have separate version numbers
18:07:16 <donuts> would it make sense to base it on fenix versions? or is that confusing?
18:07:17 <richard> but i don't have any strong preference on what the *new* numbering scheme shoul dbe
18:09:04 <donuts> well I guess at least something similar to fenix – i.e. a simple number that ticks up one with each stable release
18:09:33 <donuts> oops
18:09:41 <PieroV> they're disappointed
18:09:46 <PieroV> by your porposal :p
18:09:47 <donuts> welcome back
18:09:57 <donuts> haha pierov
18:09:57 <richard> hi
18:10:15 <richard> so what are the practical technical limitations of version numbers in google play et al?
18:10:34 <PieroV> I have no idea
18:11:23 <donuts> are there any?
18:11:27 <richard> vOv
18:12:13 <donuts> I think we need sysrqb to answer that
18:12:13 <richard> we could just leave android on the 11.0 series while desktop migrates to 11.5
18:12:20 <donuts> I've always just assumed it's a text field
18:12:26 <donuts> and that changing it wouldn't really matter
18:12:45 <richard> one would hope, but sometimes platforms are weird
18:13:14 <donuts> iirc when firefox switched to rapid release they just started counting up from the previous version
18:13:28 <donuts> so I guess the next stable TBA release would be 12, and continue on from there
18:13:30 <PieroV> yep, I think so
18:13:43 <PieroV> "The greatest value Google Play allows for version code is 2100000000." from a quick search
18:14:14 <PieroV> but this is an integer, always ticking up, then there's version name, which doesn't have limits
18:14:25 <donuts> ahhh interesting
18:14:38 <PieroV> Here's the full docs: https://developer.android.com/studio/publish/versioning#appversioning
18:15:08 <boklm> I'm wondering which version code we're using currently
18:15:20 <donuts> I guess it doesn't really matter because we'd only be changing the version name?
18:15:22 <richard> yes me too
18:15:33 <donuts> the code would otherwise continue to tick up
18:15:51 <richard> yeah
18:15:53 <donuts> I suppose we could align them if we really wanted to using whatever code we're currently on
18:15:55 <boklm> maybe we're just re-using fenix version code
18:16:05 <donuts> *really wanted to use
18:17:04 <richard> well I'm down with switching to a fenix version based version for Android
18:17:08 <richard> for the string
18:17:12 <richard> seems like it might solve some confusion
18:17:18 <donuts> yeah that was my first thought
18:17:19 <donuts> but
18:17:31 <richard> how to differentiate stable from alpha?
18:17:34 <donuts> what do we do if we release a new version for whatever reason without updating fenix?
18:17:53 <richard> we can always tack on a point release to the end
18:18:06 <richard> 99.1, 99.2, etc
18:18:45 <PieroV> Fenix actually already uses point releases
18:18:49 <richard> I think mozilla already does this (so we'd need to be sure to not collide with their points)
18:19:01 <donuts> yeah that's the part I was worried about
18:19:02 <richard> so more like 99.0.0, 99.0.1, etc
18:19:13 <boklm> 99.3.0 is what fenix is using
18:19:24 <boklm> so we would need 99.3.0.1
18:19:50 <richard> wfm
18:19:54 <PieroV> This is one of their tag: v99.0.0-beta.3
18:20:01 <PieroV> The .3 is for the third beta
18:20:03 <richard> should we do the same for desktop, but following the ESR verion?
18:21:07 <boklm> or maybe something like 99.3.0-tb1, 99.3.0-tb2, etc ... to differenciate the tor browser part of the version
18:21:29 <richard> +1
18:21:34 <donuts> yeah that makes sense
18:22:18 <donuts> okay so proposal 1: combined version number – e.g. 99.3.0-tb1
18:22:21 <donuts> proposal 2: distinct version numbers – e.g. 12 (99.3.0)
18:22:29 <PieroV> okay, but in Android alphas we use beta versions sometimes
18:22:52 <PieroV> so, should we do something like 99.0.0-beta.3-tb1?
18:23:07 <donuts> hrm it's starting to get messy
18:23:19 <PieroV> yep
18:23:20 <donuts> maybe keeping them distinct is better then
18:23:31 <donuts> at the end of the day, the user should be able to tell what version of TB they're running at a glance
18:23:57 <donuts> 12 (99.3.0) is short and neat, even if it's still separate
18:24:14 <donuts> or 12 (99.4.0-beta1) or whatever
18:24:27 <richard> that's more or less tor daemon's scheme
18:24:33 <richard> version-tag (more info)
18:24:50 <richard> so latest alpha would be like
18:25:04 <richard> 11.5-alpha (esr102-based)
18:25:18 <richard> well 11.5.11-alpha (esr102-based)
18:26:08 <richard> or for android 11.5.10-alpha (fenix99-based)
18:26:09 <richard> etc
18:26:12 <boklm> where is the "(more info)" part included?
18:26:28 <richard> it is at the end of the version string returned by GETINFO
18:26:57 <boklm> I think having a directory with a space like "11.5.11-alpha (esr102-based)" on dist.tpo will not work well
18:27:08 <richard> ahh that is a great point
18:27:12 <richard> that would really suck actually
18:27:58 <donuts> does anyone know where the fenix release calendar lies?
18:28:15 <richard> https://wiki.mozilla.org/Release_Management/Calendar
18:28:28 <donuts> ty
18:28:44 <PieroV> I think they try to be coordinated with Firefox, but I'm not sure
18:28:58 <richard> yeah i think so too
18:29:10 <donuts> oic
18:29:45 <richard> well to get back on track
18:30:04 <boklm> I think the current versioning we have works fine, but the issue is that we share it between two projects that are now released separately most of the time
18:30:10 <richard> the problem we want to solve, is to decouble tor-browser desktop and android versions right?
18:30:16 <richard> decouple*
18:30:23 <PieroV> yes, but first the next release
18:30:32 <donuts> yes
18:30:59 <PieroV> I can't give an exact eta for 11.5a10
18:31:10 <donuts> but I think the decoupled version number should better reflect the release schedules too (i.e. major/esr-based for desktop, and rapid for android)
18:31:21 <richard> in the short-term: does it actually matter that 11.5a10 will release after 11.5a11?
18:31:25 * eta tries to be more exaxt
18:31:31 <eta> (c*)
18:31:31 <donuts> hi eta :D
18:31:42 <PieroV> (sorry)
18:31:44 <richard> lol
18:32:15 <eta> (it's fine; I did this to me :p)
18:33:07 <PieroV> 11.5a11 before 11.5a10 might be confusing for users, but apart from a few comments it shouldn't be a big deal
18:33:07 <boklm> I think 11.5a10 being released after 11.5a11 is not a big issue (other than being confusing)
18:33:32 <donuts> what's wrong with 11.5a10 for android pierov?
18:33:51 <donuts> i saw a stable release managed to land while i was afk
18:34:00 <PieroV> currently, it's without HTTPS-E and noscript, but it's an issue with a known problem
18:34:01 <donuts> oh nvm I see in the pad
18:34:05 <donuts> right
18:34:10 <richard> alright, how about for 11.5 desktop (and same time period for android) we update our major version to be the firefox/fenix version, and we add our own suffix for point releases
18:34:41 <donuts> richard: I think it makes sense but it looks bad, and the important information ends up being at the very end
18:35:09 <donuts> plus it's very busy and I don't think novice users will really understand what they're looking at
18:35:28 <PieroV> And we haven't thought to the branches and tags yet
18:36:22 <richard> weirdly enough, this is already a solved problem in our tor-browser/geckoview branches...
18:36:30 <richard> tor-browser-91.9.0esr-11.5-1
18:36:37 <richard> :D
18:36:40 <richard> v user friendly
18:36:41 <donuts> i think my preference would be to use the current separate numbering scheme, but just shift android onto something that more closely resembles a rapid release numbering system where each month is a new integer
18:36:51 <donuts> so 12, 13, 14, 15 etc.
18:36:51 <boklm> we also lose the possibility to change major version without changing firefox major version (like 11.0 -> 11.5)
18:37:08 <donuts> and leave desktop as is, since it's not rapid release
18:37:23 <richard> boklm: that is a good point
18:37:47 <richard> donuts: wfm
18:38:21 <donuts> I can create a ticket with the two options though, and I'm also thinking we should get comms and community's opinion
18:38:53 <PieroV> +1
18:38:55 <PieroV> good idea
18:39:52 <donuts> okay great! thanks everyone
18:40:16 <PieroV> so, to conclude
18:40:37 <PieroV> Do we release 11.5a11 before 11.5a10 without worries?
18:40:52 <boklm> I think yes
18:40:55 <richard> yeah
18:41:17 <donuts> yolo
18:41:17 <boklm> or we can also rename 11.5a10 to 11.5a12 when it's ready (and skip 11.5a10)
18:41:33 <PieroV> I think it's even more confusing :p
18:41:50 <donuts> we should just use four emoji instead
18:42:07 <PieroV> that would be brilliant
18:42:19 <richard> <pineapple> <pineapple> <cherry> <surferdude>
18:43:41 <donuts> okay so let's continue the new-scheme convo elsewhere, and in the meantime we'll just multiverse of madness the next alpha release
18:43:58 <donuts> i think that's us for today? unless there's anything else?
18:44:14 <donuts> in fact, I'll just bring it straight to comms and community this week for input
18:44:14 <PieroV> I don't know if you want to know anything else about the Android situation
18:44:36 <PieroV> and/or if you have suggestions about it
18:44:41 <donuts> i feel like at this point i've just accepted that it's constantly borked
18:44:45 <donuts> what are your thoughts pierov?
18:45:08 <PieroV> apart from 11.5a10 being the most cursed version ever
18:45:14 <donuts> yes lol
18:45:35 <PieroV> I'm a bit sorry we've released another crashing version, but the only thing we can do is release a fixed version once we have a fix
18:45:47 <PieroV> and also hope that more people can qa it
18:46:00 <donuts> I understand it crashes _less_ though, is that right?
18:46:10 <PieroV> oh, and lesson learned: don't trust the emulator for our qa testing
18:46:13 <donuts> oh yes it says as much in the pad
18:46:17 <donuts> :(
18:46:22 <PieroV> donuts: yes, that's what I've understood as well
18:46:42 <richard> PieroV: do you have testing hardware?
18:46:47 <donuts> what's the ticket for the extension situation?
18:47:03 <richard> if not (or if you need more) we should get you some
18:47:12 <donuts> I have a real-life android device here, so I can do any specific testing you need in the interim
18:47:13 <PieroV> richard: I can use my current phone and my old one, but I don't want to try roms with strange things
18:47:23 <donuts> ah okay
18:47:24 <richard> yeah
18:47:41 <PieroV> especially the old one, because I don't want to use by mistake versions yet to release on my daily driver :p
18:48:06 <PieroV> (they have different keys for the signature, so you have to uninstall the play store version to install the qa version)
18:48:50 <PieroV> donuts: as for tickets, I'm using release prep in part, and the one about 11.0.8 for the crashes
18:49:01 <donuts> pierov: got it
18:49:10 <PieroV> https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40462
18:49:18 * donuts is looking
18:49:24 <PieroV> https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40212
18:50:30 <donuts> so it looks like 11.5a10 will just need to get released with some crashes still
18:50:43 <donuts> after its been rebuilt
18:50:46 <donuts> or am I missing anything?
18:50:52 <PieroV> yeah, which will take 1-2 days + the time for sysrqb to sign it
18:51:07 <PieroV> (I don't know if also boklm can sign it)
18:51:12 <donuts> yep, got it
18:51:34 <donuts> you're doing a great job just getting these releases out at all tbh
18:51:43 <boklm> I can't do the android signing
18:51:44 <donuts> the situation with the crashes is annoying, but at least it's getting better!
18:52:00 <PieroV> oh, well, I forgot to ask sysrqb whether he prefers a MR for the mozconfig change, or I can just push it
18:52:05 <PieroV> thanks, appreciated :)
18:52:14 <donuts> so eta for release is probably next week?
18:52:18 <donuts> or maybe end of this week?
18:52:20 <donuts> (sorry eta)
18:52:32 <PieroV> I'd say more this week
18:52:41 <donuts> gotcha
18:52:41 <donuts> that's great
18:53:00 <PieroV> I have a second even more brutal patch for the crashes though
18:53:09 <donuts> 😬
18:53:19 <PieroV> it's still building, but maybe it'll work
18:53:36 <donuts> okay, fingers crossed!
18:53:56 <richard> what's the tldr; for these latest crashes?
18:54:21 <donuts> is the brutal version the current nightly pierov?
18:54:24 <PieroV> still glean, I suppose. Fact is that getting a stack trace is quite complicated, or I'm missing something
18:54:41 <PieroV> The less brutal yes, it's in nightl
18:54:45 <PieroV> nightly
18:54:47 <donuts> ah got it!
18:54:56 <richard> gah fun
18:55:55 <donuts> okay I was going to say we're just about out of time, but this is supposed to be a 30 min meeting anyway lol
18:56:03 <donuts> anythings else before I put the bot to sleep?
18:56:15 <PieroV> not from me
18:56:21 <richard> i'm good
18:56:23 <boklm> not from me
18:56:41 <donuts> great, ty everyone!
18:56:41 <donuts> #endmeeting