15:01:27 <aguestuser> #startmeeting Application Team Meeting -- 2022-02-14
15:01:27 <MeetBot> Meeting started Mon Feb 14 15:01:27 2022 UTC.  The chair is aguestuser. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:30 <aguestuser> allo!
15:01:46 <aguestuser> pad: https://pad.riseup.net/p/tor-tbb-keep
15:02:22 <aguestuser> giving folks a few minutes to work through updates in pad...
15:04:45 <donuts> o/
15:04:48 <donuts> sorry I'm late
15:05:00 <donuts> lost track of the time
15:05:03 <aguestuser> no worries! welcome! folks are just working through status updates in pad
15:08:47 <aguestuser> okay. i'm seeing typing trail off...
15:09:05 <donuts> all done
15:09:46 <aguestuser> anyone have any blockers, learnings, espscially-pertinent-things-to-share-with-everyone to add to the discussions section?
15:09:53 <aguestuser> going once, twice...
15:09:55 <PieroV> I have a thing to share
15:10:00 <aguestuser> cool!
15:10:03 <PieroV> That is the one I wrote at the beginning
15:10:13 <aguestuser> great. let's start there
15:10:33 <PieroV> at some point, docs link were changed
15:10:53 <PieroV> and tbb dev were diligent and updated them :)
15:11:17 <PieroV> However, we still have an old link, but I don't know if it's an old file as well, that we maybe can remove, instead of updating the link
15:11:37 <PieroV> sysrqb: it's on TBA-land, maybe you can answer me
15:11:42 <sysrqb> where is the link used in Tor Browser?
15:11:54 <PieroV> https://gitlab.torproject.org/tpo/applications/torbutton/-/blob/maint-10.5-android/chrome/content/preferences-mobile.js#L70
15:12:02 <PieroV> it's on torbutton
15:12:29 <PieroV> it was used for the security slider
15:12:34 <sysrqb> i see.
15:12:46 <sysrqb> that is never used
15:12:50 <sysrqb> we can delete it
15:13:09 <PieroV> the whole preferences-mobile.js/preferences.xhtml, or only that function?
15:13:23 <sysrqb> while file
15:13:26 <sysrqb> *whole file
15:13:31 <emmapeel> yay!
15:13:48 <aguestuser> hi emmapeel!
15:13:49 <PieroV> okay, I will do :)
15:14:00 <emmapeel> hello :D thanks PieroV
15:14:05 <PieroV> yw :)
15:14:22 <aguestuser> okie-doke. that seems resolved. yes?
15:14:26 <PieroV> I also have a second point to share
15:14:32 <aguestuser> please do!
15:14:36 <PieroV> (yep, first topic done :))
15:14:41 <PieroV> I surveyed the docs!
15:14:43 <PieroV> https://pad.riseup.net/p/torbrowser-docs-survey
15:15:10 <PieroV> I'd like you to read it when you have some time, and add all the comments you want :)
15:15:33 <PieroV> basically, it's a list of all the doc pages we have at the moment (or so I hope)
15:15:43 <donuts> oh wow great job pierov
15:15:43 <PieroV> and I wrote what we should do with them, in my opinion
15:15:45 <aguestuser> wow. thanks PieroV
15:16:18 <aguestuser> would you care to give us a (completely artificial) deadline for when our feedback on the survey would be appreciated?
15:16:19 <PieroV> it was richard's idea actually
15:16:27 <aguestuser> perhaps next weekly meeting?
15:16:50 <PieroV> yeah, that works for me
15:17:03 <aguestuser> does that work for other people?
15:17:04 * donuts would love to help with a new browser roadmap
15:17:06 <PieroV> I don't know whether I should already start moving pages, or start with other tasks
15:17:13 <donuts> yep wfm
15:17:54 <donuts> oh wait these are team roadmaps
15:17:57 <donuts> nvm
15:18:12 <boklm> wfm
15:18:41 <aguestuser> PieroV anything you'd like to call our attention to as interesting/controversial/deserving of special consideration?
15:18:53 <PieroV> not, I'm done for this week, thanks :)
15:19:09 <aguestuser> kk. i meant in the survey...
15:19:33 <aguestuser> like: be sure to check out line 40 on "Hacking" because <insert controversial claim here{
15:20:06 <PieroV> not really
15:20:10 <aguestuser> all good. :)
15:20:13 <aguestuser> moving on!
15:20:14 <PieroV> I hope everything is already written there
15:20:34 <PieroV> Sadly pads don't have title levels
15:20:40 <aguestuser> :)
15:20:56 <aguestuser> okay, i had a few micro-items (most of which are placeholders to make sure we talk about things elsewhere)
15:21:38 <aguestuser> biggest one is reproduced the download bug and got some error logs out of it that i could use help from sysrqb in turning into clues-for-how-to-fix
15:21:53 <aguestuser> doesn't need to happen now, but wanted to highlight it as warranting attention
15:22:35 <aguestuser> second one was just a "hey anything needed from me on these v96 MRs"?
15:23:04 <aguestuser> hearing nothing, i gather either "no" or "i'll find out soon!"
15:23:04 <sysrqb> aguestuser: we're probably missing a permission on Android :)
15:23:37 <aguestuser> sysrqb: cool! seems like a potential quick fix we could get into alpha release? flag for followup later today?
15:24:01 <sysrqb> possibly
15:24:21 <Jeremy_Rand_Talos__> PieroV, I have some opinions on the pad you linked, where should I send feedback?
15:24:40 <PieroV> You can add them on the pad itself, maybe add your name on them
15:24:57 <Jeremy_Rand_Talos__> ok thanks, will do
15:25:01 <PieroV> thank you
15:25:20 <PieroV> aguestuser: a while ago you mentioned rebasing geckoview again
15:25:22 <aguestuser> yea, i've seen people leave inline comments by indenting under the line they want to talk about andusing `mysusername>` in front of what they want to say
15:25:30 <aguestuser> ^ Jeremy_Rand_Talos__
15:25:53 <aguestuser> PieroV: i think i'm going to try to avoid doing that before merging this bump to get v96 into nightly
15:26:16 <aguestuser> PieroV: did you have opinions about whether or how to do the rebase?
15:26:18 <PieroV> okay, so tor-browser!243 remains valid
15:26:26 <aguestuser> yes!
15:26:45 <PieroV> for opinions sysrqb should be the one to answer :)
15:27:02 <aguestuser> that is the MR that will go into this 4-MR merge sysrqb is currently reviewing
15:27:21 <aguestuser> (fenix + AC + GV + tb-build)
15:27:26 <PieroV> okay
15:28:02 <aguestuser> i did some updates that were mostly superficial to your AC rebase MR, and completed the fenix rebase
15:28:07 <aguestuser> and did the toolchain stuff
15:28:08 <sysrqb> i don't have any comments at this moment
15:28:19 <aguestuser> so at long last we are close to ready to shipping!
15:28:25 <aguestuser> okay so...
15:28:54 <PieroV> yay!
15:29:24 <aguestuser> i think the only remaining item is just to flag that we had wanted to have a follow-up conversation about how to target patches for certain releases (in the context of backports, using gitlab labels) etc...
15:29:39 <aguestuser> but today is almost certainly the worng time to have that followup b/c ricahrd is absent
15:30:01 <aguestuser> however, having brought it up, we wil hopefully be less likely to forget to talk about it next week! (or at the next release meeting)
15:30:18 <aguestuser> but: if anyone wnated to pipe up with opinions now, feel free. :)
15:30:25 <PieroV> you should add it to the pad for the next week
15:30:32 <aguestuser> done
15:31:29 <aguestuser> okay.
15:31:31 <PieroV> what we already said last week works for me
15:31:55 <aguestuser> same. think the "discussion" will likely amount to deciding where to write it down? ;)
15:31:56 <PieroV> I mean: backport small fix, but wait for new features
15:32:38 <aguestuser> and: align both android and dekstop on when to put new things into stable releases. (and how to align android-alpha releases with desktop)
15:33:18 <aguestuser> so: having covered all that
15:33:26 <aguestuser> does anyone have anything else for the good of the order?
15:34:03 <boklm> in the past we put the `tbb-backport` label on tickets that could potentialy be backported, and reviewed those tickets before each stable release to decide whether we backport them
15:34:51 <aguestuser> the wrinkle proposed by donuts was to simply use a label corresponding to stabel release for everything you think should go in that release
15:35:45 <sysrqb> that's a good idea
15:35:57 <sysrqb> except it's difficult ot predict the correct version number
15:36:10 <donuts> I was thinking of just using major version numbers
15:36:31 <sysrqb> ah, okay.
15:36:36 <donuts> so it would only solve the issue of "what's supposed to be in the next 11.0 release" vs "what's supposed to wait for 11.5", for example
15:36:45 <sysrqb> then only a little more specific than `tbb-backport`
15:36:48 <donuts> and the insinuation is that if it's tagged as 11.0 it's asap
15:36:53 <donuts> yeah sounds like the same thing
15:37:14 <donuts> do folks have any preferences?
15:37:26 * sysrqb does not
15:37:49 <boklm> is it easy to create new labels?
15:38:13 <donuts> yeah but we try and manage the volume we create
15:38:24 <sysrqb> yes, creating labels is easy
15:38:26 * aguestuser likes using major version number b/c tbb-backports becomes ambiguous over time. major version number preserves more history looking back?
15:38:45 <donuts> yeah, that's my thinking too
15:38:50 <PieroV> +1
15:39:05 <aguestuser> if we are preparing a stable release we don't have to filter out things that still say tbb-backports but shouldn't
15:39:11 <aguestuser> or reason about adding/removing labels
15:39:27 <sysrqb> that situation should never exist :)
15:39:41 <sysrqb> if it shouldn't be backported anymore, then we should delete the label
15:39:41 <aguestuser> hmm... i might not understand
15:40:07 <aguestuser> right but the nice thing about the major version label idea is you don't have to delete the label
15:40:11 <boklm> I think we have the same problem with a major version number
15:40:12 <aguestuser> it remains true for all time
15:40:23 <aguestuser> (unless i misunderstand?)
15:40:43 <donuts> ah I think boklm and sysrqb are thinking of checking the label to see what currently needs backported
15:40:45 <aguestuser> i have some given feature/patch X. i say: this will go out in stable release Y.
15:41:15 <boklm> if we keep the "major version label" on the ticket even after we backported it, we will have to filter out things to find if it still needs to be backported
15:41:19 <donuts> so if we do major version numbers, we'll also need some kind of confirmation that it's actually made its way to stable
15:41:20 <aguestuser> donuts: and i was thinking "i am preparing a relex x.y.z" let me go check all the issues tagged with that before releasing
15:41:47 <donuts> we could do a combination of both ofc
15:42:18 <aguestuser> i guess i don't understand why the "filtering" is necessary afterward. if you close the ticket don't you know it doesn't need doing anymore?
15:42:26 <donuts> "Tor Browser 11.0"/"Tor Browser 11.5" and "Backport"
15:43:08 <donuts> aguestuser: that also makes sense
15:43:17 <boklm> aguestuser: we put the labels on tickets which are already closed (after being merged to master)
15:43:18 <aguestuser> i am getting into clearly-don't-have-enough-context-to-have-a-well-infomred-opinoin territory tho, so will try to sit back and listen :)
15:43:19 <sysrqb> perhaps we should be more clean about where the label is added
15:43:48 <sysrqb> *clear
15:44:27 <sysrqb> but, as boklm said, historically we added the label on already-closed-tickets
15:44:37 <donuts> gotcha
15:44:40 <aguestuser> i see!
15:44:57 <sysrqb> but you all can create another process, which we started discussing last month
15:45:09 <sysrqb> like creating a new ticket for tracking the backport
15:45:17 <sysrqb> (or something along that line)
15:45:38 <aguestuser> so current flow is: open ticket for feature x -> close ticket when shipping into nightly/alpha -> tag for backporting -> do backporting -> remove label
15:45:50 <boklm> yes
15:45:58 <PieroV> close when it is merged
15:46:12 <PieroV> (that is a bit different from shipping, imho :))
15:46:14 <aguestuser> +1 (which would "ship into nightly" not apha)
15:46:15 <donuts> the downside to this process is that I'm often piping up in closed tickets saying "this has been forgotten about"
15:46:31 <donuts> b/c it's in nightlies or alphas but not stable
15:47:11 <donuts> I know the label fixes that, but still seems weird following up in closed tickets
15:47:15 <aguestuser> are tehre cases in which a feature  has both been tagged for backporting and also forgotten about
15:47:31 <sysrqb> yes
15:47:34 <aguestuser> or is it the case that most issues that have been forgotten about were never tagged?
15:47:50 <aguestuser> kk. so we have some evidence that the current process lets some things fall through the cracks?
15:48:03 <aguestuser> that we tag things but still forget about them
15:48:04 <sysrqb> but that was more a problem with (not) following the the process, as intended
15:48:38 <aguestuser> there is something about being supposed to pay attention to cloed tickets that seems mildly counterintuitive
15:48:47 <donuts> oh wait
15:49:01 <donuts> we have "Backport", "tbb-backport", and "tbb-backported" in here
15:49:21 <donuts> ah the first one is for tpo
15:49:42 <sysrqb> right
15:49:43 <boklm> "tbb-backport" and "tbb-backported" are what we used on trac
15:49:48 <sysrqb> ^
15:49:49 <donuts> riiiiight
15:49:58 <sysrqb> we kept those for historical purposes
15:50:05 <aguestuser> in the counterfactual (potential future): we could imagine a flow in which you'd need to create a "backport feature x" ticket before merging feature x?
15:50:20 <sysrqb> but we decidewd we'd move to using Backport in Gitlab
15:50:38 <donuts> makes sense
15:50:44 <boklm> yes, maybe we could remove "tbb-backport" and "tbb-backported", and use only "Backports"
15:51:09 <aguestuser> donuts, boklm: i am confused who you were responding to above. :)
15:51:14 <donuts> do we also need a Backported? or is the absence of the label all we need to konw?
15:51:27 <donuts> I was replying to sysrqb and boklm
15:51:29 <donuts> :)
15:51:30 <aguestuser> kk
15:51:37 * boklm was replying to donuts
15:51:42 <sysrqb> donuts: we used the absence as in indicator :)
15:51:47 <sysrqb> *an
15:51:53 <donuts> got it
15:52:04 <donuts> okay thanks for explaining that to me ^^
15:52:29 <sysrqb> but, this whole process was chosen without much reasoning, so we should use whatever works for this team
15:52:51 * aguestuser trying to figure out whether to alot more conversation time to this now or wait til next release meeting with richard...
15:53:06 <sysrqb> tbb-backport{,ed} worked well on trac, but gitlab is very different
15:53:10 <aguestuser> donuts: did you substantially shift positions by learning more about existing process?
15:53:14 <donuts> let's chat this afternoon but not make any decisions without richard
15:53:18 <aguestuser> kk
15:53:26 <donuts> aguestuser: I inhabit a permanent state of fence-sitting
15:53:34 <sysrqb> :)
15:53:36 <aguestuser> lolol. "it depends."
15:53:36 <donuts> it's the UX burden
15:53:53 <boklm> aguestuser: I think we could use the process you said (creating new tickets for backport), but in that case we will have a lot of open tickets for things we don't really need to work on (except when preparing the new release)
15:54:02 * gaba is closely reading about this :) and want to discuss labels at the all hands
15:54:14 <donuts> but I'm up for either just adding major release labels on top of continuing to use Backport, or looking at the whole thing more holistically
15:54:17 <donuts> whatever folks prefer
15:54:39 <aguestuser> boklm: okay, so we have a clearer sense of the trade-offs at any rate, which means this was a good use of our time! :)
15:55:22 <aguestuser> boklm: i'm trying to think of how we might usefully use prioritization labels/colums (kanban style) to deprioritize all the open tickets until we actually needed to think about them?
15:55:42 <boklm> aguestuser: and if we create new tickets for backports, we probably still need a label to be able to track them
15:55:50 <aguestuser> right.
15:55:58 <aguestuser> so all we got was "i can have an open thicket for this"
15:56:12 <aguestuser> and not: "i don't need to add/remove labels to traack this process"
15:56:46 <aguestuser> alrighty. i don't think we are going to actually resolve this in the next 3 minutes.
15:56:52 <aguestuser> but we got a lot of good stuff out on the table
15:56:54 <aguestuser> go team!
15:57:08 <aguestuser> anyone have anything else they're burning to get out on the table before we wrap?
15:57:15 <aguestuser> 3...
15:57:23 <aguestuser> 2...
15:57:27 <aguestuser> 1...
15:57:36 <donuts> kanban idea is interesting
15:57:40 <aguestuser> hahahah
15:57:40 <donuts> 0...
15:57:49 <donuts> (sneaking in at the end :P)
15:57:58 <sysrqb> o/
15:58:00 <aguestuser> #endmeeting