18:02:26 <donuts> #startmeeting Tor Browser Release Meeting 2022-03-7
18:02:26 <MeetBot> Meeting started Mon Mar  7 18:02:26 2022 UTC.  The chair is donuts. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:34 <donuts> I think I did that right
18:02:56 <PieroV> you should copy the command like Richard :D
18:02:58 <donuts> gaba is afk today so we should start without her
18:03:00 <richard> you did it :3
18:03:08 <donuts> haha yeah I have to look it up every time
18:04:01 <donuts> looks like someone (aguestuser?) is adding things to the pad
18:05:23 <aguestuser> indeed!
18:05:48 <donuts> okay let's get started
18:06:30 <donuts> 11.0.7 stable is getting released tomorrow, but desktop only?
18:06:42 <PieroV> bolkm is already signing
18:06:46 <donuts> perfect
18:06:50 <PieroV> so I don't think we have time to add also Android
18:06:54 <richard> yeah 11.0.7 can ship once boklm gives the thumbs up
18:06:59 <donuts> and 11.5a6 is planned for next week
18:07:05 <richard> or more likely, he will just make it happen
18:07:07 <donuts> yeah I was going to ask what the status is with android releases
18:07:11 <richard> i'm working on blog post for 11.0.7 now
18:07:22 <PieroV> donuts: but we may release 11.5a6 earlier, because of the security patches
18:07:31 <aguestuser> donuts: did you see that 11.5a5 went out with the download bugfix?
18:07:39 <richard> yeah 11.5a6 should go out asap after 11.0.7
18:07:51 <PieroV> we've already built it (at least me, I think that boklm is going to build it soon, if he's not already doing it)
18:08:09 <donuts> aguestuser: ah no, I missed that! on Thursday?
18:08:21 <donuts> that's great, I'll bring it up at tomorrow's UX team meeting to test
18:08:33 <aguestuser> https://blog.torproject.org/new-release-tor-browser-115a5/
18:08:38 <richard> oh one thing I wanted to call out, I've added a 'Release Prep' tag
18:08:48 <donuts> what are the security patches for 11.5a6 btw?
18:09:00 <donuts> ty aguestuser
18:09:07 <richard> to Tor Browser issues on gitlab, and you can see all of our planned/closed release tracking tickets
18:09:22 <richard> (and there's a new column at the end on the defualt Tor Browser board in gitlab)
18:09:44 <PieroV> donuts: the same that we added to 11.0.7 (exactly the same, because both are based on 91.7)
18:10:16 <PieroV> commits are tor-browser@fe4d6e1d236831635d76f062e013c6bf25d58408 and tor-browser@1794b76288c6fa7fed6f4caae88335ed57145e65
18:10:54 <aguestuser> richard, PieroV: the linked mozilla bug is private so it's a bit hard to understand what attack they are preventing
18:10:59 <aguestuser> (particularly if i'm donuts trying to explain this to users)
18:11:08 <aguestuser> do we have anything public from moz explaining the bug?
18:11:19 <donuts> richard: it looks like release prep is in applications/tor-browser only, was that intentional?
18:11:23 <PieroV> we have a CVE
18:11:25 <donuts> or should it be on all of applications?
18:11:31 <PieroV> two CVEs, actually
18:11:55 <aguestuser> PieroV: do we have links? (i looked at all our tickets associated with the bugfix and couldn't find any public links)
18:11:55 <PieroV> CVE-2022-26485 and CVE-2022-26486, let me find if I can find a statement from Mozilla
18:11:58 <richard> donuts: yeah i think that's a fine place for it?
18:11:59 <donuts> yeah anything public you could point me to would be great, although it hasn't came up yet as far as I'm aware
18:12:05 <aguestuser> and was too lazy to scrollback in #tor-internal ;)
18:12:32 <PieroV> https://www.mozilla.org/en-US/security/advisories/mfsa2022-09/
18:12:33 <sysrqb> https://www.mozilla.org/en-US/security/advisories/mfsa2022-09/
18:12:38 <sysrqb> heh. too slow.
18:12:44 <donuts> ah fantastic, ty both :)
18:13:03 <donuts> love these release prep tickets btw richard
18:13:29 <richard> yeah I'm going to add an issue template to help track all the work that goes into it as well
18:13:32 <aguestuser> richard: speaking of which... i am supposed to make contributions to the release prep issue template... but i can't find the template
18:13:37 <aguestuser> doh
18:13:38 <richard> for tracking+documentation purposes
18:13:42 <aguestuser> messages stepped on each other
18:13:44 <richard> aguestuer: yeah it doesn't exist yet ;)
18:13:58 <donuts> also nice touch adding it to the kanban
18:14:13 <aguestuser> richard: but i'm guessing i can look at your last one and get the gist? (for my next release prep ticket?)
18:14:24 <richard> hopefully i'll have an MR ready for it this week but you know
18:14:34 <aguestuser> nw
18:14:34 <aguestuser> :)
18:14:38 <richard> aguestuser: so currently that ticket just links the relevant issues for a given release
18:14:59 <richard> but I'm *going to* add a checklist for rebase, version checks, signing tagging, etc
18:15:21 <aguestuser> coool! :)
18:15:21 <richard> anyway i'll ping you when i have something
18:15:24 <aguestuser> ack
18:15:45 <aguestuser> okay so: what discussion point are we on now?
18:15:46 <aguestuser> ;)
18:16:07 <donuts> Android releases then the discussion items?
18:17:19 <aguestuser> i had added android releases as a discussion item
18:17:31 <aguestuser> but am happy to jump to that if folks think it's prio
18:17:54 <aguestuser> i mainly want to figure out what numbers to give things
18:18:01 <aguestuser> and when to target them for release
18:18:08 <aguestuser> so i can update calendar and issues accordingly
18:18:23 <aguestuser> decided today: will begin rebasing onto v99 *now*
18:18:31 <richard> dope
18:19:14 <aguestuser> we need another stable release this month to get the fenix v96 update into stable
18:19:20 <aguestuser> but we just shipped it to alpha last week
18:19:34 <aguestuser> so if we're trying to get on an "every 2 week" cadence
18:20:02 <richard> every two weeks for a new android stable?
18:20:03 <aguestuser> i was thinking of doing the first android release this month as an alpha release rebasing onto v99
18:20:05 <aguestuser> then a stable
18:20:09 <donuts> atm it looks like android and desktop releases are kind of leapfrogging each other on the calendar, is there a plan to get desktop and android releases in sync again?
18:20:28 <richard> so we've tentatively agreed to interleave tor-browser desktop and android releases (ignore chemspill/emergency releases)
18:20:32 <PieroV> I think it was intended
18:20:38 <aguestuser> donuts: i had made the calendar assuming we wanted to "leapfrog"
18:20:42 <donuts> oh gotcha
18:20:45 <richard> yeah
18:20:47 <aguestuser> (it is admittedly somewhat confusing to try to do that!)
18:20:55 <richard> otherwise it's too much to build/sign all at one time
18:21:05 <donuts> the version numbering seems a little weird then
18:21:16 <donuts> but idk how that works
18:22:03 <richard> yeah i'm not sure how to best resolve that
18:22:14 <aguestuser> if now's an okay time, i'd love to touch base on logistics of interleaved releases
18:22:24 <richard> shoot
18:22:26 <aguestuser> i tried to fill in release dates in the calendar for ~2 months out
18:22:48 <aguestuser> with the goal of doing android builds in the weeks in-between when desktop builds were happening
18:22:49 <aguestuser> BUT
18:23:08 <sysrqb> aguestuser: (just fyi, we want to get onto a bi-weekly release schedule, but that shouldn't delay putting out a stable version while we're still behind Mozilla)
18:23:25 <aguestuser> sysrqb: wait i really wanna hear that
18:23:32 <aguestuser> but also want to communicate another thing
18:23:42 <aguestuser> sysrqb: wait now i'm confused
18:23:52 <aguestuser> i mapped out a bi-weekly release schedule in the calendar
18:23:55 <aguestuser> is that not what you are talking about?
18:24:02 <aguestuser> err *we*?
18:24:19 <sysrqb> yes, but we're month's behind mozilla
18:24:25 <aguestuser> i was trying to alternate an alpha release with a stabel release every 2 weeks
18:24:33 <aguestuser> and put that into the calendar from today until 2 months from now
18:24:37 <aguestuser> but had a hard time doing it neatly
18:24:50 <sysrqb> so, in this case, where we have what-appears-to-be a working version based on Moz96
18:24:52 <aguestuser> b/c dekstop has a ~1 week lag between signing/tagging alpha releases
18:24:56 <aguestuser> and shipping them
18:25:00 <sysrqb> we shouldn't delay putting out a stable just because we want a biweekly cadence
18:25:02 <aguestuser> gah
18:25:06 <aguestuser> this is really hard to follow
18:25:11 <aguestuser> can we have a "talking stick" or something?
18:25:22 <richard> ok
18:25:47 <richard> sysrqb: can you outline how this bi-weekly release schedule should look for android?
18:25:49 <sysrqb> aguestuser: you can go ahead, i'll stop
18:25:58 <aguestuser> sysrqb: okay, so i *think* thing (1) is that we want to prioritize stable
18:26:10 <aguestuser> like that's the very next thing b/c playing catch up
18:26:21 <aguestuser> that seems non-controversial and not-that-hard to do
18:26:37 <aguestuser> (others agree?)
18:26:42 <sysrqb> agree.
18:26:59 <aguestuser> kk. so strike the idea of next android release being alpha on top of v99
18:27:04 <richard> 👍
18:27:14 <aguestuser> that gets the next slot (whenever that winds up being)
18:27:32 <aguestuser> but regardless of what is being released when i have a question about the general timing of "interleaving"
18:27:38 <aguestuser> on the bi-weekly cadence
18:27:54 <aguestuser> do people have the calendar in front of them by any chance?
18:28:05 <PieroV> I have
18:28:09 <aguestuser> if you noticed for example the 11.5a6 Dekstop Sign/Tag is on 3/9
18:28:17 <aguestuser> (after rebasing that starts today)
18:28:19 <sysrqb> isn't alternating an ideal scenario, but not strictly needed until Android catches up? so, break the alternating schedule for the next ~1 month and get back in sync with Mozilla?
18:28:29 <aguestuser> the release based on that sign/tag doesn't happen until 3/15
18:28:33 <aguestuser> oh no!
18:28:37 <aguestuser> what happened to richard?
18:28:44 <sysrqb> richard
18:28:49 <richard> yo
18:28:51 <sysrqb> richard's okay
18:28:55 <richard> #rurallyfe
18:29:07 <aguestuser> lolol
18:29:33 <aguestuser> did you miss some scrollback?
18:29:39 <aguestuser> (i can repaste)
18:29:40 <richard> yeah I think so
18:29:41 <aguestuser> +aguestuser | if you noticed for example the 11.5a6 Dekstop Sign/Tag is on 3/9
18:30:01 <aguestuser> [+aguestuser | (after rebasing that starts today)
18:30:10 <aguestuser> +aguestuser | the release based on that sign/tag doesn't happen until 3/15
18:30:16 <aguestuser> (and we're back)
18:30:22 <aguestuser> so my question is:
18:30:32 <aguestuser> i am also rebasing this week
18:31:01 <aguestuser> and would like to release shortly after signing/tagging
18:31:15 <aguestuser> but assuming i sign/tag at the end of the week
18:31:23 <aguestuser> i can't ship until after the desktop release goes out
18:31:38 <aguestuser> (if for no other reason because the dekstop has "taken a lock" on the release number)
18:31:56 <aguestuser> this makes it tricky to neatly interleave the releases
18:32:07 <aguestuser> in our ideal-case scenario
18:32:18 <aguestuser> (once we're caught up and the android releases don't take forever)
18:32:26 <aguestuser> so i guess i'm curious:
18:32:48 <aguestuser> (1) is there a reason we delay for a week btw/ signing/tagging on desktop and releasing? (should we do that on android also?)
18:33:22 <richard> so the delay is a builtin safeguard in case shit breaks
18:33:24 <aguestuser> (2) if we *don't* want to observe that delay on android how to handle the fact that this lag inserts an artificial delay of ~1 week in releasing android once it's essentially ready?
18:34:10 <richard> in theory there's no reason to delay if everything is fine, but i'd rather have that safe window in case we need a build2 or a build3 so we aren't making people wait based on the schedule
18:34:14 <aguestuser> oh also: i *think* waiting on that lag also means we have to delay signing/tagging android releases until after dekstop release went out
18:35:03 <richard> hmm yes
18:35:14 <sysrqb> it's not strictly needed, but it is cleaner if you wait
18:35:32 <richard> technically speaking you can sign/tag once we've verified matching desktop builds
18:35:58 <aguestuser> okay, so we could just follow the same lag?
18:36:02 <richard> at that point we shouldn't need to touch the tor-browser-build branches for that build
18:36:30 <aguestuser> thus far we've always shipped every android build the same day(ish) as signing/tagging
18:36:52 <richard> same day as binary signing you mean?
18:36:53 <aguestuser> but allowed for safety by leaving new branch in nightly for a bit before signing/tagging
18:37:00 <richard> sorry i meant signing/tagging to mean signing/tagging git commits
18:37:09 <sysrqb> 1 week is a longer delay then we've used in the past - we usually put 2-3 days, and then update the changelog with subsequent buildN's, if needed
18:38:12 <sysrqb> richard: we can release an android release in ~24 hours, from tagging to publishing
18:38:15 <aguestuser> what is the difference btw/ (1) the buffer we leave between rebasing patches onto new upstream branch and merging that (shipping it to nightly) and (2) the buffer we leave between signing/tagging commits and publishing release?
18:38:37 <aguestuser> i had thought that (1) was the thing we did to catch bugs, etc.
18:38:50 <aguestuser> is (2) just extending (1)? (leaving the same code in nightly for longer?)
18:39:16 <aguestuser> since these delays are holding something from going from nightly to alpha, right? (2) is just doing more of that?
18:40:10 <aguestuser> in any case: i don't necessarily need to know the motivation to figure out the scheduling stuff.
18:40:32 <aguestuser> the fact is just that interleaving gets a bit tricky b/c of different lenghts of delay between sign/tag and release on different platforms
18:40:49 <aguestuser> i had tried to puzzle it out on my own last week on calendar but figured it would be good to check in with others!
18:40:53 <richard> the (2) buffer in my mind was just to make the release process less crunchy from a timing perspective (and to take into account the long iteration time involved with building releases)
18:41:03 <aguestuser> akc
18:41:07 <richard> (on the desktop side)
18:41:12 <aguestuser> yup yup!
18:41:26 <richard> if android is easier/faster for whatever reason then by all means do what makes sense for you
18:41:40 <aguestuser> okay, but: what about issue numbering
18:41:46 <aguestuser> let's say we start this week
18:41:57 <aguestuser> and you are building 11.5a7 (desktop only)
18:42:05 <aguestuser> i am building 11.5a88 (android only)
18:42:08 <sysrqb> there isn't a technical reason we can't release 11.5a7 before 11.5a6
18:42:19 <aguestuser> this gets to the root of my question
18:42:34 <aguestuser> right now i am trying to take later numbers (b/c i'm assuming i will take longer while still learning)
18:42:42 <aguestuser> but if eventually android finishes faster
18:42:52 <aguestuser> i had thought it should maybe have the first release number
18:43:01 <donuts> maybe it no longer makes sense using the same version numbering system
18:43:04 * donuts quickly exits
18:43:11 <richard> donuts: my thought as well
18:43:15 <PieroV> donuts: I was wondering the same
18:43:25 <donuts> can we use some adaptation of fenix's for android?
18:43:32 <aguestuser> (if, e.g., android 11.5a8 is ready to ship by thursday, but desktop is not ready to ship until next tue)
18:43:34 <sysrqb> eventually, stable android should be build with desktop, and alpha should be at the ~2 week mark which should not align (or block) a desktop-only release
18:44:06 <aguestuser> but it seems like desktop starts to do an alpha-related rebase at the top of every month
18:44:12 <aguestuser> which android is also doing
18:44:28 <aguestuser> (since that's when the mozilla releases roll over for both of us)
18:44:31 <sysrqb> but desktop releases after ~1 week, and android builds/releases after ~2 weeks
18:44:50 <aguestuser> i see. okay. makes sense
18:44:52 <aguestuser> but if android is ready to release after ~1 week
18:44:58 <aguestuser> we still want to hold until ~2 weeks to publish?
18:45:05 <sysrqb> we should stay with the 2 week cadence
18:45:17 <aguestuser> sysrqb: in the current calendar
18:45:20 <sysrqb> you can consider expiditing, but that's on a case-by-case basis
18:45:27 <aguestuser> dekstop does *not* release at ~1 week mark
18:45:35 <aguestuser> it releases at ~2 week mark
18:45:42 <aguestuser> err 1.5
18:46:04 <sysrqb> still seems okay :)
18:46:08 <aguestuser> but regardless... i think i understand the desired cadence
18:46:18 <aguestuser> (1) moz rolls over
18:46:19 <aguestuser> (2) everyone starts rebasing
18:46:25 <aguestuser> (3) dekstop releases alpha
18:46:29 <aguestuser> (4) android releases alpha
18:46:43 <aguestuser> (5) everyone releases stable together at same time?
18:47:00 <aguestuser> (with shared version number for stable release?)
18:47:11 <sysrqb> (3') desktop/android stable
18:47:16 <sysrqb> (4) desktop alpha
18:47:22 <sysrqb> (5) android alpha
18:47:36 <sysrqb> stable release almost always comes first
18:47:53 <aguestuser> hmm... not in the calendar i worked off last week
18:48:07 <aguestuser> or rather it was step (0)
18:48:10 <sysrqb> because we want to get security updates out to our users asap after mozilla releases their version
18:48:13 <aguestuser> happened before moz rolled over?
18:48:43 <sysrqb> ah, i see
18:48:46 <sysrqb> i think.
18:48:57 <sysrqb> there are multiple versions in play
18:49:06 <sysrqb> let's look at this month
18:49:14 <aguestuser> or the stable desktop release happens more or less concurrently w/ (1)
18:49:29 <aguestuser> (the day that moz rolls over and the day after we started rebasing on the next alpha)
18:49:46 <aguestuser> yes, this month!
18:50:09 <aguestuser> (which might be tricky b/c security hotfix, but yes: a concrete example would be great)
18:50:33 <aguestuser> 11.0.7 stable desktop was calendared for release tomorrow 3/8
18:50:47 <richard> mmhm
18:50:55 <aguestuser> (on top of esr91.7)
18:51:16 <sysrqb> (let me know when/where I should jump in)
18:51:50 <aguestuser> i am actually now confused by the fact that 3/8 says it is a stable release on esr91.7 but we also start rebasing alpha onto esr91.7 today
18:52:10 <sysrqb> correct :)
18:52:39 <richard> (again the 1 week lag is just built-in buffer, really I ttry to treat these dates as due dates, not start dates, with limited success)
18:53:08 <aguestuser> "+sysrqb | correct :)" <- that is not how we do it in android?
18:53:18 <aguestuser> fenix versions land in alpha beforfe stable
18:53:27 <aguestuser> i mean jump in at any point
18:53:32 <aguestuser> i'm actually sort of hopelessly lost now
18:53:40 <sysrqb> :)
18:53:43 <sysrqb> it's all good
18:53:52 <aguestuser> but i am not sure the desktop versioning question affects my question
18:54:15 <sysrqb> let's actually look at next month, under the assumpt Android successfully jumps onto the FF99 train
18:54:51 <aguestuser> by next month we mean april?
18:54:59 <sysrqb> yes
18:55:01 <aguestuser> https://nc.torproject.net/apps/calendar/dayGridMonth/2022-04-01
18:55:21 <aguestuser> on 4/4 moz rolls over and we start rebasing
18:55:21 <sysrqb> shortly after 2022-04-04 Mozilla will tag 91.8esr and 99.0
18:55:27 <sysrqb> correct.
18:55:35 <sysrqb> we start with stable
18:55:46 <sysrqb> for the past month, we've been testing 99beta in our alpha release
18:55:53 <sysrqb> (~2 weeks, really)
18:56:08 <sysrqb> we now rebase our patches onto the 99.0 stable release branch
18:56:20 <sysrqb> and desktop patches are rebased onto 91.8esr branch
18:56:39 <sysrqb> we build these new branches and release a stable version on 2022-04-05
18:56:49 <aguestuser> okay, so without need for rebasing, we quickly publish stable targetting both 91.8esr and 99
18:56:59 <aguestuser> on 04-05
18:57:05 <aguestuser> following
18:57:06 <sysrqb> (hrm. okay, the tag date was wrong, it should be around 1 week earlier)
18:57:10 <aguestuser> (and had completely missed that in my release scheduling)
18:57:44 <aguestuser> also if looking at this calendar, note: that i've got fnx99 where i should have fnx100
18:57:58 <sysrqb> sorry, we do rebase the android patches from the 99 beta branches to the stable branches
18:58:14 <aguestuser> onto maint-11.0
18:58:18 <aguestuser> (in this case)
18:58:30 <sysrqb> yes
18:58:49 <aguestuser> and then we rebase fnx100 onto new (soon-to-be-alpha-release) branch
18:59:03 <sysrqb> correct
18:59:14 <sysrqb> and that will take around 1-2 weeks, for rebasing and toolchain updates
18:59:29 <sysrqb> after 2 weeks, we should be ready for that alpha release, on schedule.
18:59:41 <aguestuser> desktop, goes first, then android
18:59:57 <aguestuser> and if helpful for android to wait after signing/tagging to publish we can
19:00:16 <aguestuser> (i guess a helpful insight for me from this is there is no blocker to signing/tagging as soon as i want)
19:00:40 <aguestuser> and: it's still aspirational that any of the rebasing for alpha branches will happen "fast" (under any definition of "fast")
19:00:46 <sysrqb> correct, and we should probably release a combined desktop/android alpha release based on 91.8esr and Fenix98 after the 1 week delay
19:01:00 <sysrqb> because there isn't really a reason not to update android at the same time
19:01:28 <richard> mhnmm
19:01:30 <aguestuser> err... fenix100?
19:01:44 <aguestuser> (if we're talking april?)
19:02:21 <aguestuser> but where did the idea of interleaved releases go then?
19:02:23 <sysrqb> err, no, Fenix 99, sorry. we release desktop/android stable based on 91.8esr and Fenix99, and then after a week I propose we release the alpha for both desktop and android
19:02:49 <sysrqb> and then the android-only alpha based on Fenix100 comes along at the ~2 week mark
19:03:40 <sysrqb> but this doesn't need to decide right now
19:03:46 <sysrqb> we can table this until the next meeting
19:03:48 <aguestuser> "then after a week I propose we release the alpha for both desktop and android" <-- gosh. currently alpha releases are "ahead." ie: alpha is on fenix v96, while stable is on v94
19:03:53 <aguestuser> is that an anomaly?
19:04:17 <aguestuser> i was trying to map out next 2 months assuming that stable is always 1 version behind alpha in terms of fenix version
19:04:32 <aguestuser> also: we are at 5 minuts past time
19:04:38 <aguestuser> sorry for swallowing entire meeting
19:04:38 <PieroV> *35
19:04:55 <PieroV> release meeting is half an hour :)
19:05:00 <aguestuser> oh really?
19:05:00 <richard> lol
19:05:02 <aguestuser> geeze
19:05:03 <sysrqb> aguestuser: no, that is how it should work: alpha -> 99beta, stable -> 99, alpha -> 99, alpha -> 100beta, stable -> 100, etc.
19:05:11 <donuts> ha yes technically PieroV is right but that's totally fine, seems like there's nothing else following this
19:05:27 <PieroV> true
19:05:38 <richard> ok aguestuser, are we good now w/ regards to android release schudling?
19:05:43 <aguestuser> lol
19:05:47 <richard> :p
19:06:12 <aguestuser> i am reading the above tyring to parse the differentce between 99beta and 99
19:06:17 <aguestuser> etc
19:06:29 <sysrqb> aguestuser: beta release verses stable release
19:06:41 <sysrqb> mid-month verses beginnning-of-next month
19:06:55 <sysrqb> https://wiki.mozilla.org/Release_Management/Calendar
19:07:21 <aguestuser> ok, right so if we track that we presereve the invariant that alpha is always a "branch" ahead of stable
19:07:23 <aguestuser> but not a version
19:07:27 <sysrqb> 99beta is mid march, and then 99 is beginning of april
19:07:28 <aguestuser> (which is the mental model i had)
19:07:44 <aguestuser> or not a major version
19:07:49 <sysrqb> yes
19:08:16 <aguestuser> okay, i think i need to take somet time to stare at calendars again before i can actually project 2 months out
19:08:18 <sysrqb> i think i threw a wrench into you mental model when I proposed releasing android-alpha based on 99
19:08:24 <sysrqb> but that's okay
19:08:47 <aguestuser> i will start with figuring out what version numbers to give our android-only emergency releases
19:09:14 <aguestuser> then figure out what to number the next android stable (v96) and android alpha (v99) releases.
19:09:41 <aguestuser> with an honest effort to try to parse whetner i mean v99beta or just v99
19:09:48 <aguestuser> and coordinate with richard on what our release numbers should be
19:10:10 <aguestuser> (punting to next time on question of doing new version number scheme should be! yes?)
19:10:20 <aguestuser> /s/should/might
19:10:30 <sysrqb> (this is why we haven't successfully scheduled future version-number release dates, only version-less release dates)
19:12:05 <aguestuser> ok. i am officially done wasting other people's time in public. :)
19:12:13 <sysrqb> donuts: you may need to end the meeting :)
19:12:17 <PieroV> nope
19:12:19 <donuts> haha yes will do
19:12:21 <PieroV> I have still two points
19:12:29 <PieroV> onion auth is fixed, tor-browser!261
19:12:30 <richard> lol gogogo
19:12:32 <donuts> please go ahead pierov
19:12:34 <aguestuser> nooooooooooo
19:12:43 <PieroV> are we going to do a .7.1?
19:12:48 <donuts> fantastic! what was the issue?
19:12:51 <richard> dope
19:12:55 <PieroV> as Richard said, a missing await
19:13:08 <richard> lol called it
19:13:10 * richard dabs
19:13:15 <PieroV> lol
19:13:30 <PieroV> or are we waiting for next release?
19:13:43 <aguestuser> (sorry: my "noooo" was at meeting ending! not at PieroV saying stuff. really excited for someone else to say stuff! :))
19:13:49 <donuts> hahaha
19:13:56 <PieroV> and in case I would also slip the IPv6 circuit display
19:13:57 <richard> we could do a simultaneous android/desktop stable release with the fix in
19:14:18 <PieroV> okay, then IPv6 can wait
19:14:27 <richard> yeah IPV6 can wait regardless
19:14:46 <richard> PieroV: what's the summary on the onion auth issue?
19:14:51 <PieroV> I proposed it in the backport asap small features spirit
19:15:00 <richard> is it just bad UX if the bug is hit
19:15:03 <PieroV> tor-browser#40802
19:15:04 <richard> or does it just not work at all
19:15:21 <PieroV> it doesn't work at all
19:15:30 <richard> ugh damn
19:15:36 <donuts> does that mean there should be a fix for it next week (in x.x.7.1)?
19:15:54 <richard> ok let's plan on new stable+alpha desktop releases next week then
19:16:31 <richard> i'll get to merging and tagging and whatnot this week
19:16:38 <PieroV> okay, works for me
19:16:53 <richard> aguestuser: i'll follow up wiht you later abotu the right version number to use :3
19:17:24 <PieroV> no more points from me :)
19:17:40 <aguestuser> richard: ack :)
19:18:01 <donuts> okay I'm gonna press the button
19:18:03 <richard> ok
19:18:04 <donuts> 3...
19:18:06 <donuts> 2...
19:18:07 <donuts> 1...
19:18:10 <donuts> #endmeeting