15:01:52 <richard> #startmeeting Tor Browser Weekly Meeting 2022-02-22
15:01:52 <MeetBot> Meeting started Tue Feb 22 15:01:52 2022 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:59 <richard> today is a blessed date
15:02:19 <sysrqb> tell us about it
15:02:45 <richard> if you haven't already please fill out your pad sections and we'll get this meeting rolling
15:02:50 <richard> sysrqb: it's all 2s and 0s
15:03:12 <donuts> 22022022 :D
15:03:28 <richard> lol
15:03:55 <donuts> or 02222022 if you prefer
15:03:59 <sysrqb> or, or, it's all zeroes...mod 2.
15:04:13 <richard> sysrqb: must integers are :3
15:04:36 <sysrqb> hey, not the point.
15:04:47 <richard> (at this point the mathematicians in the chat start furiously writing me an agnry email about that's now how infinities work)
15:04:51 <aguestuser> o/
15:05:52 <boklm> o/
15:07:44 <richard> oh and while you're waiting, if y'all could make sure your kanban boards on gitlab are all straightened out, relevant tickets are closed, etc that would be swell
15:10:42 <richard> ok, aguestuesr, looks like you have a laundry list of discussion points so let's get started
15:11:07 <richard> aguestuser*
15:11:31 <richard> well actually, this discussion may take a bit
15:11:59 <richard> PieroV: can you give me a summary of the Bug 16439 issue?
15:12:06 <aguestuser> richard: the teamwide one (about releases) was just something i flagged as requiing followup once yr back
15:12:16 <richard> (I am planning on doing the rebase for 91.7 desktop next Monday
15:12:25 <PieroV> richard: it was a patch that excluded screencasting code on TBA
15:12:34 <PieroV> It isn
15:12:43 <sysrqb> aguestuser: i'm planning on merging tor-browser-build!406 today, and we can prep a release tomorrow
15:12:44 <PieroV> * it isn't doing anything on desktop
15:12:56 <aguestuser> sysrqb: cool! :)
15:13:06 <richard> ah ok, i misread TBA as torbutton
15:13:08 <PieroV> and sysrqb told me to remove it also from TBA
15:13:44 <sysrqb> right, mozilla removed the code upstream in Firefox 95 (?)
15:13:58 <richard> alright, that sounds good to me
15:14:05 <sysrqb> so i recommended dropping our patchfor it in geckoview
15:14:13 <sysrqb> but it's still living in the desktop/esr branch
15:14:48 <sysrqb> and i think i agree with PieroV that it's not needed there anymore, because we shouldn't be building an Android geckoview from that code, in any case
15:15:01 <richard> ok, I'll be sure to drop them then for the 91.7 rebases
15:15:28 <sysrqb> the proxy-bypass code is still in 91esr, but i believe it is only included when compiled for Android
15:15:49 <sysrqb> if PieroV didn't already confirm that, then we should before dropping the patch
15:16:02 <sysrqb> if it was already confirmed, then we should be good
15:16:15 <richard> (are these two separate patches?)
15:16:33 <PieroV> let me find the commit
15:16:52 <PieroV> https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/28d36e0ac9eec25601b11c8816b02f49cf9f7498
15:17:19 <PieroV> You see that there's an `else:` that is run only when in Android
15:18:09 <richard> mmhm
15:18:30 <richard> so to be clear
15:18:51 <richard> this code no longer exists post FF 95(?) and is only needed in Android
15:19:17 <richard> so we can drop it from desktop and it's now meaningless in FF 97
15:19:28 <PieroV> is only needed in Android: correct; no longer exists post FF 95 I'll check it
15:19:53 <PieroV> s/97/91.7/?
15:20:29 <richard> i meant whichever version tor-browser android is based off of
15:20:52 <sysrqb> (currently 96, but yes)
15:20:53 <PieroV> Now it's on 96
15:20:58 <richard> regardless, I'm sure you and aguestuser can coordinate on the android part
15:21:07 <richard> ok, let's now go back to aguestuser's dicussion topics
15:22:10 <aguestuser> ok!
15:22:41 <aguestuser> last week we dove into the issue that had come up in an ad-hoc fashion in #tor-dev about how to deal with tracking backports from alpha to stable
15:22:45 <aguestuser> (on both android and desktop)
15:23:16 <aguestuser> and we wanted to bring it back up when we were all here to make a decision
15:23:49 <aguestuser> i am honestly a bit under-the-weather to recap and facilitate, but i think duncan had a pretty good grasp of the state of where we shot out at?
15:24:33 <aguestuser> err.. donuts! but perhpas donuts is not here!
15:24:41 <donuts> So sysrqb and boklm explained that we currently use the "Backport" label, which indicates a closed ticket & associated MR should be backported
15:24:48 <donuts> and once that's complete, the label is removed
15:24:53 <donuts> that's the current process, at least
15:25:45 <donuts> we discussed continuing to use that system (perhaps with Backport/Backported labels) and throw in extra labels for major versions too (e.g. Tor Browser 11.0 and Tor Browser 11.5), which would make it easier to figure out where a specific patch landed historically too
15:26:06 <donuts> however then we got into the weeds as to whether or not we wanted to just patch the existing process, or rethink it
15:26:18 <aguestuser> the key new idea i remember was opening tickets for performing a given backport
15:26:29 <donuts> and that's where aguestuser's suggestion about tracking fixes across release channels came up as well
15:26:39 <aguestuser> so that you weren't having to rifle through closed tickets to see what still needed to be backported
15:27:19 <aguestuser> which would add friction to the process of merging a new feature (every time you do so, you'd create a ticket for backporting it)
15:27:22 <richard> hmm
15:27:35 <richard> so to add a grenade to the discussion
15:27:36 <aguestuser> but remove friction from tracking what had been backported by making it more visible, naming it as "work that needs doing"
15:27:40 <boklm> I think looking at closed tickets with the backport keyboard is not difficult, you just need to bookmark the url to do that
15:27:49 <boklm> keyword
15:28:24 <aguestuser> but if for example, your flow is to look at the kanban board to see what is "next" or "active" to track what's coming up...
15:28:42 <richard> over the past week I started adding a version label to the Merge requests
15:28:55 <richard> for the version they need to be merged into (along with the 'Backport' label)
15:29:11 <Jeremy_Rand_Talos__> Back when Trac was a thing, we had a wiki page that listed useful ticket query URL's that were non-obvious; maybe bring that concept back if it isn't already a thing?
15:29:24 <richard> eg those various UX MRs got the 11.0.7 label
15:29:31 <richard> though I'm not sure if that will scale well with gitlab
15:29:50 <boklm> richard: to the MR, or to the ticket?
15:29:55 <richard> to the MR
15:29:57 <donuts> richard: yeah, I think it'll create a lot of tickets
15:30:04 <donuts> but I love the idea
15:30:07 <aguestuser> oh, i think the other relevant data point was that in the current system, we frequently fail to backport things
15:30:22 <aguestuser> err.. don't know if "frequentLY' is accurate
15:30:40 <aguestuser> but we at least sometimes fail to notice that something needs backporting. (according to folks who were around)
15:30:45 <sysrqb> ("we" == sysrqb, maybe richard and aguestuser will be better)
15:30:48 <richard> (tbf backporting tickets was a bit of a blind-spot for me other past few months)
15:31:05 <aguestuser> i can speak for myself that i am 100% likely to not go back through closed tickets
15:31:11 <donuts> I've also found it difficult to figure out where and when fixes should be landing too
15:31:12 <aguestuser> or to mess that up rather
15:31:54 <richard> yeah I'm also inclined to not be looking through old tickets
15:32:18 <sysrqb> part of this is "just follow the documented process"
15:32:59 <sysrqb> but, for myself, my releaes preparatin process became sloppy and I went through many of the steps from memory
15:33:02 <aguestuser> but also if the process is counterintuitive and likely to induce errors b/c it conflicts w/ intuition, why not design a process that corresponds w/ intuition?
15:33:25 <sysrqb> and that resulted in missing some steps, like looking at patches that needed backporting
15:33:33 <aguestuser> (the UX thing about not insisting the path be where people don't actually walk, but moving the path to where they do walk)
15:34:15 <richard> i will say that for my workflow, having to create a new ticket for each backport and then having to resolve it is going to be kind of tedious
15:34:15 <sysrqb> true, i agree with that in principle
15:34:46 <donuts> what if the backport ticket was just kept open until it's done?
15:34:50 <donuts> I don't know if this is opening another can of worms, but closing bugs before they're fixed in stable/have been validated also seems a little counterintuitive
15:35:23 <PieroV> can we add issue statuses?
15:35:33 <sysrqb> donuts: not a crazy idea
15:35:36 <PieroV> for example at my previous jobs I never closed tickets, but sent them to qa
15:35:50 <aguestuser> donuts, PieroV: we have columns for this in existing gitlab kanban
15:35:51 <PieroV> and then only if the passed the qa they were closed
15:35:57 <aguestuser> (and i am warm to this idea)
15:36:01 <donuts> yeah, that's how I've worked before too (what PieroV said)
15:36:12 <donuts> I'm treating alpha -> stable as "QA" here though
15:36:12 <aguestuser> (by "columns" i also mean labels)
15:36:37 <gaba> pierov: i really like that idea of a qa stack. I know it is used in many places. We would need somebody to do the qa
15:37:08 <aguestuser> this would also sort of change our "definition of done" ...
15:37:23 <gaba> oh yes, we need a definition of done
15:37:26 <aguestuser> ... to "passed 'QA' in alpha, has been merged into stable"
15:37:27 <gaba> in each ticket
15:37:28 <sysrqb> it's a new work-flow/release-flow for us, but that may help us backport fixes
15:37:43 <richard> yeah that sounds reasonable to me
15:38:30 <donuts> so basically we need new statuses for beyond "doing"/"needs review"?
15:38:31 <sysrqb> i don't know that Gitlab is designed for this process, but it sounds worth trying
15:38:58 <richard> 'needs testing' or something similar?
15:39:08 <gaba> we have needs revision too :) this is a topic of conversation for the next two all hands
15:39:30 <richard> and only once it's out in nightly and verified works do we close?
15:40:05 <aguestuser> richard: i'm hearing that it's not done until it's in stable
15:40:13 <aguestuser> am i hearing right tho?
15:40:19 <aguestuser> (reading? ;))
15:40:27 <donuts> yeah that was my thought, it also makes things clearer for observers/cypherpunks
15:40:37 <sysrqb> richard: good question. that usually depends on the severity. sometimes we've gone straight from Nightly to Stable, and sometimes we let it bake in a coupe Alpha versions before we backport to stable
15:41:08 <richard> sysrqb: yeah that comment didn't quite articulate the complexities
15:41:09 <PieroV> how does Mozilla do for esr backport?
15:41:43 <richard> given that we have major features that don't get merged to stable until the next major version, versus emergency fixes that need to be quickly backported, etc
15:41:48 <boklm> there are also things we never backport to stable until the next major release. do we want to keep an open ticket for this for 6 months?
15:42:13 <sysrqb> PieroV: one ticket with status/label fields for each supported version
15:42:17 <donuts> boklm: yeah, that's the major issue with this plan
15:42:19 <richard> right exactly my thinking
15:42:33 <aguestuser> one nice thing about some sort of "in nightly/alpha" tag is that it gives donuts and crew a "single source of truth" as to new features they might want to be primed to listen for issues from users about
15:42:35 <donuts> unless we treat immediate fixes and major release fixes differently
15:42:41 <aguestuser> boklm: good point!
15:42:43 <donuts> but that's confusing
15:43:18 <donuts> +1 for nightly and alpha to potentially be statuses
15:43:36 <donuts> nightly essentially doubles for internal QA, Alpha for community QA
15:43:44 <sysrqb> yeah
15:44:19 <Jeremy_Rand_Talos__> Data point: Bitcoin Core closes issues when they're merged to master, and adds a "needs-backport" tag which is then handled by team members who are responsible specifically for backports
15:44:27 <donuts> maybe we close after something hits alpha (or stable if it doesn't hit alpha at all)?
15:44:49 <donuts> (in response to boklm's point)
15:45:11 <sysrqb> if it will eventually be included in a stable, then it should always hit alpha first
15:45:40 <sysrqb> hrm, i guess that's not 100% true
15:45:59 <sysrqb> sometimes we do rush emergency fixes into stable before alpha - but that's rare
15:46:04 <richard> yeah see emergency security updates
15:46:05 <boklm> I think I like having tickets open meaning that some work is needed on the ticket, and closed as no more work needed (and doing the backport does not count as work, unless the patch needs to be adapted)
15:46:19 <richard> boklm: +1
15:46:53 <aguestuser> (tyring to think devil's advocate a bit): it seems like there will be a fair amount of (tedious/fiddly/error-prone?) ticket label housekeeping work required when doing an alpha release
15:47:15 <aguestuser> like you don't just need to update the changelog, you need to hunt down all the tickets associated with the changelog and change their statuses?
15:47:39 <richard> aguestuser: well to be fair, that could be helpful though
15:47:52 <aguestuser> richard: say more!
15:47:59 <aguestuser> like it's helpful b/c it makes you think about it?
15:48:08 <aguestuser> and/or make what's happening in the changelog more visible in gitlab?
15:48:11 <richard> to have a set of tickets that *need* to be modified that also gives us precisely the list of things to add to the changelog
15:48:27 <aguestuser> mmm
15:48:56 <richard> just because sometimes fixups! get comitted but don't have a message associated with them
15:48:59 <aguestuser> like a filtered label search generates the changelog
15:49:25 <richard> yeah more or less
15:49:52 <aguestuser> yum!
15:50:01 <aguestuser> yum?
15:50:18 <richard> anything that minimizes the amount of issue sleuthing/detective work during changelog generation would be good
15:50:47 <PieroV> so, would you include the number of alpha in the label?
15:50:53 <PieroV> like 11.5a7?
15:51:49 <sysrqb> unfortunately that may be misleading because we may haev an emergency release or android release
15:52:04 <sysrqb> and that causes the "expected version" to be wrong
15:52:15 <PieroV> right, it's unfortunate indeed
15:52:31 <aguestuser> also: if you want to use columns at all (i might be the sole person here who likes looking at kanban board view of gitlab?) then you need something more generic
15:53:05 <aguestuser> or... if you want everyone (eg: UX team) to have one label they can always search on reliably, etc...
15:54:15 <sysrqb> PieroV: oh, did you mean the Alpha version where the patch was first merged?
15:54:36 <donuts> yeah I think specific version labels may lead to label chaos
15:54:47 <sysrqb> or the target alpha version when the patch should be packported?
15:54:51 <sysrqb> *backported
15:55:39 <PieroV> each alpha which sooner or later needed the related commit
15:55:56 <aguestuser> (time-check :))
15:56:26 <PieroV> I was wondering if we can have two kinds of labels, like some labels that are more "disposable" but useful to track changes when going back
15:57:33 <boklm> an other idea: we could have a wiki page for the changelog of the coming alpha release, where we write each ticket number when the patch is merged
15:57:34 <sysrqb> you can all experiment and see which processes work best in practice, as well
15:57:58 <richard> yeah I think that we're not going to come up with the perfect system here
15:58:47 <richard> well this meeting time slot is just about up
15:59:02 <Jeremy_Rand_Talos__> (when is discussion about PieroV's docs survey, if any, going to occur?  I'm not in a hurry to discuss it, just want to make sure I'm around for it)
15:59:30 <richard> oh yeah i was going to bring that up too as I think I was afk for the meeting it was initially shown off
15:59:53 <PieroV> I shared the link at last week's meeting
16:00:09 <PieroV> but we decided to comment it later, so that everyone could have time to look at it
16:00:58 <richard> PieroV: ok, could you schedule an hour in the next week or two after we've all gone through the doc and we can make some forward progress on that front
16:01:00 <richard> in the meantime
16:01:04 <richard> it's time to go
16:01:10 <aguestuser> o/
16:01:12 <PieroV> okay, thanks!
16:01:14 <PieroV> o/
16:01:18 <Jeremy_Rand_Talos__> thanks!
16:01:21 <richard> cya later everyone
16:01:22 <richard> #endmeeting