15:00:19 <richard> #startmeeting Tor Browser Weekly Meeting 2021-01-31
15:00:19 <MeetBot> Meeting started Mon Jan 31 15:00:19 2022 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:36 <boklm> o/
15:00:40 <richard> ok let's go through update the pad
15:03:21 <Jeremy_Rand_Talos_> Hi!
15:04:22 <sysrqb> tor-browser#28325
15:04:35 <sysrqb> hrm. no.
15:05:12 <boklm> is that tor-browser-build#28325 ?
15:05:29 <sysrqb> yes, that's my next guess
15:05:59 <sysrqb> and, if that is what richard wanted, then i think the current answer is "soon, but not immediately"
15:06:09 <sysrqb> boklm: GeKo: correct? ^
15:06:25 * GeKo got summoned
15:06:43 <sysrqb> *a GeKo appears*
15:07:02 <GeKo> uhm, what did richard want?
15:07:07 <GeKo> i don't have the pad open
15:07:13 <sysrqb> thae pad says: " @boklm/@sysrqb is this something we need to do soon?"
15:07:16 <sysrqb> *the
15:07:20 <GeKo> no, we don't
15:07:47 <sysrqb> okay, that's what i remembered.. richard ^
15:07:49 <richard> aah tor-browser-build i was wondering what that ticket was
15:07:50 <GeKo> even 1.17 which we have in our alpha series is fine
15:07:57 <richard> when looking at it this morning
15:07:58 <boklm> https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40345#note_2767389
15:08:12 <GeKo> so, i suspect we have at least like a year of so until it gets really urgent
15:08:20 <GeKo> assuming 1.18 is finally breaking things
15:09:15 <richard> ok sorry i've filled out my section, runnnig a bit late today
15:09:36 <sysrqb> sorry, i jumped straight to discussions :)
15:09:59 <richard> yeah something came up right before so i'm in a bit of a tizzy
15:11:00 <richard> ok, so sounds like we don't need tor-browser-build#28325 immediatley immediatley but something we need to do soon
15:11:26 <sysrqb> within the next ~6-10 month-ish
15:11:35 <richard> ook good to know
15:11:56 <sysrqb> <+GeKo> so, i suspect we have at least like a year of so until it gets really urgent
15:12:06 <sysrqb> (is what I am going from)
15:12:40 <richard> alright added to my calendar for like july then
15:13:13 <richard> ok PieroV, what qs do you have about dark themes for tor-browser#40774?
15:13:29 <PieroV> Do we have some figmas for dark theme?
15:13:31 <richard> in general, we try to not break the built-in themes
15:13:47 <PieroV> Some elements like the borders do not look good with dark theme on
15:14:02 <richard> ah most likely not, donuts doesn't tend to do dark modes
15:14:19 <PieroV> okay, then we'll see when the whole thing is ready :)
15:14:31 <richard> my general process here is to steal css rules/colors/vars from existing dark-mode elements
15:14:33 <donuts> there's UI for dark theme in the Proton design library :<
15:14:36 <richard> and go from there
15:15:00 <PieroV> ack
15:15:14 <richard> yeah a lot of the xul/html elements tend to 'just work' but sometimes you need to take extra care to figure out which to use
15:15:40 <PieroV> yeah, I saw... I solved the problem with labels
15:15:44 <richard> in my experience there's not really a better way to go about it apart from 'right-click inspect elements you want to steal css from' vOv
15:15:59 <PieroV> I was adding content inside, instead of adding it to the value attribute
15:16:00 <donuts> would you like me to do a quick dark theme version of preference PieroV?
15:16:05 <donuts> *preferences
15:16:26 <PieroV> as you prefer, I can also send you a screenshot with dark theme on, so you can tell me if anything needs to be fixed
15:16:38 <donuts> sure that works too, feel free to add it to the design ticket
15:17:07 <richard> ok i think the only remaining thing is me then
15:17:12 <PieroV> in general, does richard create a testbuild for you to review the changes?
15:17:28 <richard> yep :)
15:17:52 <richard> i'm looking to merge PieroV's tor-browser#40562 tonight/tomorrow AM
15:18:10 <PieroV> yay!
15:18:11 <richard> i assume the smart way to do this would be to just make a new 11.5-2 or 3 branch?
15:18:19 <PieroV> we already have a -2 branch
15:18:24 <PieroV> I targetted it on the MR
15:18:38 <richard> ok well there you go
15:19:00 <richard> alright then i'll do that unless there are some hidden footguns I'm not aware of here
15:19:09 <boklm> yes, a -2 branch (and using it in the nightly) sounds good
15:19:19 <richard> then all future patches should be targeting that branch
15:19:42 <richard> ah right, boklm: I'll make a tor-browser-build code MR for you to look at to make sure I don' forget anything
15:20:03 <PieroV> I don't know if you want me to add also tor-browser!251 before merging
15:20:24 <richard> but soon we should be in a better (?) place w/ regards to manging our patche set :)
15:20:38 <richard> PieroV: yeah i'm planning on merging that onto the new 11.5-2 branch
15:21:07 <PieroV> and then squash it with on the next esr?
15:21:13 <richard> yep
15:21:15 <richard> which speaking of which
15:21:31 <richard> the mozilla release calndar suggest 91.6 is coming down the pipes next week
15:21:36 <sysrqb> yep
15:22:08 <sysrqb> do you want to go through the release prep and tagging?
15:22:20 <sysrqb> (with or without my help?)
15:22:39 <richard> sysrqb: is the date on that calendar for when the tagged esr91.6 commit happens, or when builds are released?
15:22:53 <richard> is 91.6esr available some days before?
15:23:07 <sysrqb> Mozilla's calendar is when it's released
15:23:12 <sysrqb> we should get tags today/tomorrow
15:23:19 <sysrqb> so we just need to look out for those
15:23:43 <sysrqb> (they usually tag ~1 week before release)
15:24:03 <richard> ok, then I'd like to get a nightly or two of the re-organized 91.5 before moving it all to 91.6
15:24:39 <richard> and the next alpha can hopefully be 91.6 based
15:24:52 <richard> (I still need to update our own release calendar)
15:25:40 <richard> sysrqb: does that whole plan seem reasonable to you?
15:26:17 <sysrqb> my only clarifying question is: "and the next alpha can hopefully be 91.6 based"?
15:26:39 <sysrqb> we usually first build stable based on the next esr
15:27:00 <sysrqb> are you talking about the the new reorganized patchset?
15:27:06 <richard> ah, rather than letting it sit in alpha for a bit?
15:27:35 <sysrqb> right, we usually move stable first, asap, and then move alpha as soon as we're done with stable
15:27:53 <richard> ok that makes sense
15:27:59 <sysrqb> we don't usually let a new monthly esr release bake in alpha
15:28:17 <sysrqb> mostly because there are security updates in it
15:28:47 <richard> riiight ok
15:29:35 <richard> alright, so 91.6 tags should be available soon this week (if their release is planned for the 8th)
15:29:47 <sysrqb> correct
15:29:50 <boklm> so we probably don't want the new reorganized patchset in stable for 91.6, only in the alpha
15:29:53 <richard> we want move stable over to 91.6, then move alpha
15:30:10 <richard> boklm: ok that's the conclusion i came to too
15:31:44 <richard> alright, then i'll plan on rebasing stable this week, and alpha next
15:32:30 <richard> does that sound reasonable to everyone?
15:32:43 <boklm> yes
15:32:45 <richard> have i missed anything important from the pad?
15:33:07 <PieroV> I had another bold item for boklm
15:33:08 <aguestuser> flagging for later convo (don't need to answer now): i am confused about basing alpha off of the esr branch. (b/c "alpha" and "stable" seem opposite and i thought we based our alpha branch off of mozilla's beta branch). can folo w/ sysrqb off-thread?
15:33:43 <aguestuser> PieroV i have buried your guidance on how to setup a listing on tpo/people and wanted to make sure to do that!
15:34:00 <boklm> (maybe rebasing alpha can be done end of this week, when we are done with stable)
15:34:19 <sysrqb> richard: our ideal release schedule has been: 1) get tag on ~tuesday, rebase our patchset and release prep on tuesday/wednesday, build releaes wed/thu, sign packages on friday and start alpha release prep
15:34:26 <PieroV> boklm: for changes, do you prefer a fixup commit, or a force push?
15:35:10 <sysrqb> richard:  i wasn't always successful in hitting those marks, but that usually results in a smoother release on the following tuesday
15:35:18 <sysrqb> boklm: (yeah)
15:35:19 <PieroV> aguestuser: there's an how to on GitLab for tpo/people, let me find it
15:35:49 <sysrqb> aguestuser: that is only for android, confusingly we're only talking about desktop here
15:36:09 <richard> sysrqb: sounds good to me, though I would need to delay alpha prep to the following week
15:36:25 <aguestuser> kk (would be good to build a mental model of how that works to avoid being confused!)
15:37:16 <richard> ok
15:37:25 <sysrqb> richard: okay, you could even do alpha prep on thursday, if the stable building is still running - or someone else could take tagging alpha
15:37:35 <sysrqb> but do what you think is best
15:37:41 <sysrqb> (as i know you will :) )
15:37:50 <boklm> PieroV: what I usually do is: push fixup commits in the existing MR, then open a new MR with the commits squashed and close the old MR
15:38:11 <PieroV> okay
15:38:12 <richard> :)
15:38:22 <boklm> PieroV: but I can do the commit squashing part before merging if you want
15:38:42 <richard> boklm: yeah I think in general this is the best(?) way to handle updating MRs
15:39:00 <richard> ie fixups in the existing then squashing in new MR for final merge candidate
15:39:08 <richard> but anyway
15:39:15 <richard> if there's nothing else i'm happy to call it
15:39:18 <PieroV> as you prefer, I can open a new MR when you tell me it is okay
15:39:23 <PieroV> (nothing else from me)
15:39:25 <aguestuser> boklm sysrqb i'd like to consolidate all of your helpful guidance on workflow for TBA build into a "playbook"-like docs page. any preference where it goes? (wiki page? `tb-build/doc`?)
15:40:09 <richard> gosh
15:40:21 <sysrqb> aguestuser: if it's only related to working within tor-browser-build, then I would say putting it into tor-browser-build/docs is best
15:40:33 <boklm> aguestuser: I think with all the other docs related with tor-browser-build, tor-browser-build/doc would be fine
15:40:37 <richard> yeah I'm inclined to agree
15:40:50 <sysrqb> but if it's more generally for build fenix withint tor-browser-build and outside of tor-browser-build, then putting it on the wiki may be better
15:41:07 <richard> i may just be bad at computers, but i find the wiki a pretty awful place to *find* information (even when it exists)
15:41:22 <richard> but that's another issue for another meeting
15:41:23 <aguestuser> cool! the center of gravity is tb-build. but the guide i want to make is comprehensive. like, it touches on the rebase commits you make to 3 other repos
15:41:24 <sysrqb> you need to know where to look...
15:41:45 <aguestuser> (in general i prefer docs in repos, but the problem is that they are "heavier" there, thus more likely to get stale)
15:41:55 <aguestuser> if i want to edit a wiki, i can make small chantges
15:41:58 <sysrqb> aguestuser: hrm
15:42:03 <richard> i think tor-browser-build is one of the better places to put docs, since at some point everybody needs to use tor-browser-build vOv
15:42:13 <sysrqb> so, we also have tor-browser-spec which contain processes documentation
15:42:15 <richard> and everything ultimately goes through it
15:42:18 <aguestuser> if i want to edit docs in a repo that can require an MR, etc... as a result i avoid editing them and they can get outdated
15:42:47 <richard> doc updates are a very easy MR to approve though :)
15:42:51 <aguestuser> true! :)
15:42:52 <Jeremy_Rand_Talos_> FWIW it would be nice if the guidelines for MR workflow were linked from a CONTRIBUTING.md in tor-browser-build, which is where I initially looked for it.
15:43:00 <sysrqb> but this may be a good converation to have regarding where we want processes docs to live
15:43:30 <richard> yeah agreed
15:43:49 <sysrqb> because wiki vs tor-browser-build/docs vs tor-browser-spec is confusing
15:43:54 <sysrqb> and not obvious for most people
15:44:07 <aguestuser> if it's helpful, i have an open ticket and we could move discussion to an asynchronous chat there if not time in this meeting: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40421
15:44:16 <richard> aguestuser: maybe the team should set some time to discuss this some other time in the coming weeks?
15:44:23 <boklm> maybe we should link tor-browser-build/docs and tor-browser-spec from the wiki
15:44:53 <sysrqb> yeah
15:44:57 <sysrqb> richard: that seems smart
15:45:03 <aguestuser> richard agree that pulling this out into it's own convo sometime/place is probably good!
15:45:18 <richard> alright great, can you take point on this aguestuser?
15:45:22 <aguestuser> (i don't need immediate clarity on where to put this and can continue drafting it on my laptop in the meantime)
15:45:55 <aguestuser> richard happy to take point. am i taking point on scheduling a meeting or ensuring that the convo in that ticket reaches satisfactory resolution?
15:46:06 <aguestuser> if meeting: like on BBB? or...
15:46:14 <richard> erm just scheduling the meeting for now
15:46:24 <aguestuser> sure!
15:46:29 <richard> and I think #tor-meeting would be fine for now
15:46:42 <aguestuser> dig.
15:46:50 <richard> ok that's enough for one meeting
15:46:56 <sysrqb> o/
15:47:00 <sysrqb> thanks richard
15:47:00 <richard> later everyone!
15:47:02 <PieroV> o/ thanks!
15:47:05 <richard> #endmeeting