18:59:33 <sysrqb> #startmeeting Tor Browser meeting 25 January 2021
18:59:33 <MeetBot> Meeting started Mon Jan 25 18:59:33 2021 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:37 <sysrqb> o/
18:59:41 <dunqan> o/
18:59:43 <Jeremy_Rand_Talos> Hello!
19:00:00 <acat> o/
19:00:15 <gaba> hi!
19:01:46 <sysrqb> Pad: https://pad.riseup.net/p/tor-tbb-keep
19:02:18 <GeKo> hi
19:09:54 <sysrqb> is tor-browser#40282 remaining from last week?
19:10:02 <sysrqb> I'm assuming yes
19:10:42 * sysrqb delete's dunqan discussion item from last week, too
19:10:56 <dunqan> oh sorry, thanks
19:10:57 <GeKo> i hope it is finall fixed :)
19:11:49 <GeKo> *finally
19:11:58 <sysrqb> i didn't try it in the nightly
19:12:11 <sysrqb> i'll test it after the meeting :)
19:12:18 <GeKo> well, the testsuite got fixed, too, and did not complain
19:12:27 <GeKo> sooo
19:12:30 <sysrqb> true
19:12:34 <sysrqb> surely it's fixed :)
19:12:50 <GeKo> time will tell :)
19:13:37 <acat> i think it should be fixed this time :)
19:13:55 <sysrqb> Weekly reminder to update you boards (if necessary)
19:14:46 <sysrqb> Later today I'll assign some MRs we have
19:16:08 <sysrqb> I'll jump to the last discussion item, because that should be quick
19:16:25 <sysrqb> GeKo: is that about the Revier field?
19:16:29 <sysrqb> *Reviewer
19:17:03 <GeKo> yes
19:17:13 <GeKo> and about a weird issue i fighted with last week
19:17:40 <GeKo> so, for some reason we have a usable Reviewer field now
19:17:41 <sysrqb> okay, you have the floor
19:17:46 <GeKo> ahf filed an issue
19:17:47 <GeKo> thanks
19:17:56 <GeKo> but that one got not fixed :)
19:18:05 <GeKo> likely some dupe instead
19:18:23 <GeKo> either way we can think now about using the Reviwer field for MRs
19:18:37 <sysrqb> nice
19:18:42 <GeKo> and then additional labels to indicate review state
19:19:07 <GeKo> like Needs Review, Needs Revision and friends
19:19:17 <sysrqb> sounds reasonable
19:19:18 <GeKo> turns out just with Assignee we did not need those
19:19:34 <GeKo> so things get more complex when doing them correctly ;)
19:19:55 <GeKo> but i heard other teams jumped already on that train
19:19:56 <sysrqb> but, now MRs will be reflected on the Boards, and that may help with organizing, too
19:19:59 <sysrqb> maybe
19:20:09 <GeKo> could be!
19:20:20 <sysrqb> or maybe they don't show there, idk :)
19:20:28 <GeKo> so, i guess it's time for us to follow
19:20:35 <GeKo> althought i don't feel strongly here
19:20:37 <sysrqb> but yes, we can experiment with using the Reviewer field now, too
19:20:39 <GeKo> *although
19:21:46 <sysrqb> so Assignee will almost always be the person who is opening the MR and responsible for the issue/patch
19:21:57 <GeKo> yep
19:22:00 <sysrqb> and Reviewer will be the person who is assigned to reviewing the patch
19:22:26 <sysrqb> (maybe "assigned to reviewing" is not the best phrase)
19:23:10 <sysrqb> acat: sounds okay
19:23:12 <sysrqb> ?
19:23:18 <GeKo> and then we have the usual "Needs Revision" etc. workflow
19:23:29 <acat> yep
19:23:32 <sysrqb> yeah
19:23:43 <GeKo> as i said the downside is you need to keep track on your "Needs Revision"  items now
19:23:44 <sysrqb> okay, let's try it
19:23:52 <GeKo> which is not so easy
19:23:56 <sysrqb> yeah
19:24:02 <GeKo> i think label change is not causing an email sent
19:24:21 <GeKo> so, that's a big drawback for folks with an email-based workflow
19:24:23 <sysrqb> but the state is now explicit, instead of implicit in the current assignee and comments
19:24:31 <GeKo> yep
19:24:33 <sysrqb> ah, hrm, that could be
19:25:02 <GeKo> so, one needs to have a bookmark or tab open and refresh hings
19:25:03 <sysrqb> we can make adjustments if this doesn't work well
19:25:04 <GeKo> *things
19:25:15 <GeKo> yeah, just saying
19:25:18 <sysrqb> yep
19:25:30 <acat> or add a "needs revision" comment
19:25:40 <acat> when updating the label
19:25:40 <GeKo> the other thing was me fighting with tor-browser#40292 during triage
19:25:42 <GeKo> yep
19:26:04 <GeKo> i was not able to set a milestone last friday
19:26:05 <sysrqb> Needs Revision \n \label "Needs Revision"
19:26:17 <GeKo> i think this got fixed with a gitlab update over the weekend
19:26:34 <GeKo> however, the reason for that was the issue not being an issue but an incident
19:26:41 <acat> oh, forgot to set the undefined milestone
19:26:48 <GeKo> no you could not :)
19:26:53 <GeKo> until recently
19:26:59 <sysrqb> oh! Incident
19:27:03 <GeKo> yes
19:27:16 <GeKo> ideally i'd like to get rid of that type
19:27:33 <GeKo> but maybe that's not important now anymore as we can set milestones (again)
19:27:39 <GeKo> not sure what other folks think
19:27:55 <sysrqb> Is the only indication "Close Incident"?
19:28:12 <GeKo> i think so
19:28:18 <sysrqb> great
19:28:20 <GeKo> which is why it took me ages
19:28:29 <sysrqb> yeah, i understand
19:28:29 <GeKo> to figure out wtf is going on
19:28:31 <GeKo> :)
19:29:25 <GeKo> maybe we just live with the additional ticket type
19:29:30 <sysrqb> i don't know we have control over the available issue types
19:29:35 <GeKo> and move on with our lives
19:29:43 <GeKo> now that we can set milestones
19:29:55 <sysrqb> but i am leaning toward moving on
19:30:10 <sysrqb> if it doesn't afect our lives/productivity much now
19:30:14 <sysrqb> *affect
19:30:49 <sysrqb> gaba: do you know if any other team had issues with the Incident issue type?
19:31:38 <gaba> i do not know anybody using it
19:31:56 <sysrqb> if nothing else, we know know there could be a different between the issue types, and we can look at it in the future
19:32:03 <sysrqb> if there is something weird
19:32:12 <sysrqb> *we now know
19:32:13 * gaba reading backlog
19:32:31 <sysrqb> thanks
19:33:02 <sysrqb> in the mean time, we can move on to the 85 retrospective
19:33:05 <gaba> you mean use the incidents insteadl of issues?
19:33:14 <GeKo> in addition to
19:33:22 <GeKo> err
19:33:57 <sysrqb> gaba: and, if any teams had trouble with them, possibly because a contributor opened an Incident instead of an issue
19:33:57 <GeKo> i guess look into getting rid of it
19:34:13 <gaba> yes, there was an incident in core and there were issues with it
19:34:18 <gaba> because we couldnt set a milestone
19:34:29 <GeKo> yeah, but it seems you now can
19:34:34 <gaba> what kind of problems you have with it?>
19:34:39 <gaba> ahh, ok
19:34:41 <sysrqb> GeKo had the same
19:34:46 <GeKo> i was not able to set a milestone :)
19:35:10 <gaba> yes, maybe incidents should get converted into issues if they make sense
19:35:15 <gaba> if somebody open thems
19:35:20 <gaba> we do not have to get rid of them
19:35:31 <GeKo> you can't convert them i think
19:35:37 <GeKo> at least i failed
19:35:37 <sysrqb> i don't see a way
19:35:54 <sysrqb> except manual copy/paste
19:36:03 <GeKo> (it's one of the bunch of things i tried to trick it into getting a milestone)
19:37:04 <sysrqb> this isn't critical now, but we should remember it for the future
19:37:09 <gaba> convert in the sense of opening a new issue and referring to the incident
19:37:23 <sysrqb> ah, yeah.
19:37:39 <gaba> there may be many incidents that could be related to only one issue that needs to be fixed
19:37:56 <GeKo> is anybody using incidents anyway?
19:38:23 <sysrqb> I can imagine the Network Health team may use it in the future :)
19:38:39 <GeKo> smart
19:39:02 <sysrqb> but, i think we really only deal in issues
19:39:18 <sysrqb> and, while Gaba is right, there could be multiple incidents related to a single issue
19:39:36 <sysrqb> i don't think that maps onto our work flow processes very well
19:39:50 <sysrqb> *work flow or processes
19:39:58 <sysrqb> and a user openeing an incident is not very helpful to us
19:40:02 <sysrqb> *opening
19:40:48 <sysrqb> that is especially true in browserland, but i think that is true for most other teams, too
19:41:17 <sysrqb> except maybe TPA, if they want to separate information in that way
19:41:33 <sysrqb> but, now I'm just guessing :)
19:41:44 <sysrqb> and we have a more important  topic we should get to
19:42:27 <sysrqb> so, we can look into whether disabling incidents is possible on a per-project basis
19:42:36 <sysrqb> but i'm okay with keeping them for now
19:42:40 <GeKo> yeah
19:42:46 <gaba> ok
19:43:13 <GeKo> no user complained about that when filing a ticket, so that's good too
19:43:19 <GeKo> aynway
19:43:25 <sysrqb> yeah
19:43:26 <GeKo> *anyway
19:43:33 <sysrqb> okay, and now on to the retro
19:43:37 <GeKo> i added some sub-items
19:43:42 <GeKo> we could think about
19:43:50 <sysrqb> yep, thanks for that
19:43:52 <GeKo> that seemed to me the pain-points
19:44:00 <GeKo> maybe there are more
19:44:06 <GeKo> or different ones
19:44:29 <GeKo> as i said if all of our assumptions hold we shold be in good shape for the release imo
19:44:44 <GeKo> but i don't like trusting our assumptions here :)
19:44:58 <GeKo> *just
19:45:22 <GeKo> personally, i think we did well until we came back from vacation this year
19:45:43 <GeKo> like we had done the major parts of the rebasing and the toolchain updates for the first alpha
19:46:10 <GeKo> but then things got bumpy
19:46:35 <GeKo> e.g. i think the time between coming bac and our first alpha getting out was way too long
19:47:06 <acat> i think i should have started the closed bugs review earler for sure, ideally the first week of coming back
19:47:24 <GeKo> *back
19:47:30 <sysrqb> I agree that our monthly release cycle should prepare us for a smooth roll out
19:48:15 <sysrqb> i think your work in december was good and kept us on schdule then
19:48:25 <acat> re: testsuite, it seems some times gets stuck in some kind of infinite loop, and the process has to be killed manually
19:48:32 <sysrqb> i was tired and very burned out, and i did not finish everything needed before the december break
19:48:53 <acat> not sure if you refer to that. i'll try to fix when i do the MR together with the android work
19:48:59 <sysrqb> and then coming back in January, I was distracted by a few other items
19:49:12 <sysrqb> and that further delayed the first alpha
19:49:18 <GeKo> acat: the test suite item is torlauncher#40004
19:49:36 <GeKo> because that is blocking us from running the tests at all i think
19:49:43 <acat> oh, right
19:49:50 <GeKo> which is bad
19:50:17 <GeKo> tor-launcher#40004
19:50:56 <GeKo> sysrqb: i hope you feel better now.
19:50:59 <acat> i think on a normal release without vacs i could have started than one earlier, too
19:51:16 <acat> sysrqb: yeah, i also hope you feel better
19:51:35 <GeKo> sysrqb: overall, that's cool imo. what we need to do in those cases then i think is to distribute the work
19:51:36 <sysrqb> heh, thanks, yeah - breaks are nice
19:51:53 <GeKo> i did not know that you were distracted by other stuff
19:51:59 <GeKo> not sure about acat
19:52:12 <GeKo> but it have been easily doable to put the work on our plaate
19:52:15 <sysrqb> no, i was trying to hold my responsibilities
19:52:27 <sysrqb> but i wasn't as successful as i needed to be in that case
19:52:27 <GeKo> to fix the remaining 5% of work
19:52:42 <GeKo> and it was not more than 5% imo
19:53:23 <sysrqb> that's true
19:53:45 <sysrqb> i need to be better about communicating, in general
19:54:00 <GeKo> dunno :)
19:54:33 <sysrqb> :) :/
19:54:55 <GeKo> i did not mean to blame you or anyone here
19:55:09 <GeKo> (or single anyone out)
19:55:30 <GeKo> i am just wary so we get our processes right for the future storms to come
19:55:42 <GeKo> which includes my last item as well
19:56:05 <GeKo> we usually said we were late in the release building process because
19:56:14 <GeKo> of fenix being so late
19:56:20 <GeKo> but mozilla fixed their shit
19:56:32 <GeKo> and the tag we needed was ready on thu last week
19:56:57 <GeKo> yet we still hadn't rebased and reviewed that by the end of friday
19:57:41 <GeKo> and i am not talking here about the dream not doing work on weekends :)
19:57:55 <sysrqb> yeah
19:58:10 <GeKo> it's likey hard to avoid working on weekends when doing release builds
19:58:18 <GeKo> but barring some unforseen accident
19:58:40 <GeKo> we should not be in the need of reviwing rebase changes on friday evenings anymore
19:58:45 <GeKo> *reviewing
19:58:52 <sysrqb> i agree
19:59:06 <GeKo> again, i think we could cope here by distributing the work better
19:59:13 <GeKo> in case it is needed
19:59:22 <GeKo> taking timezones into account
19:59:53 <GeKo> if we need to do those things on fridays at all
20:01:13 <sysrqb> i would like to s tarts out work on the 86 cycle without making many changes
20:01:26 <sysrqb> i think we'll be more successful this month
20:01:42 <sysrqb> if we find we're stretched too thin
20:01:49 <sysrqb> and we aren't hitting our target dates
20:02:19 <sysrqb> then we can give you (GeKo) more of the load
20:02:46 <sysrqb> but I don't want to do that unnecessarily
20:02:46 <GeKo> fine with me
20:03:03 <sysrqb> and we should see how well we are doing by early next week
20:03:04 <GeKo> yeah, it was just an option i brought on the table if needed
20:03:17 <sysrqb> yeah,i appreciate that
20:03:38 <GeKo> there are other sponsor commitments
20:03:54 <GeKo> and we get essentially an unknown amount of work with every beta
20:03:55 <sysrqb> yes
20:03:59 <GeKo> down from mozilla
20:04:21 <GeKo> so we should be very flexible imo and not shy asking other folks for help
20:04:27 <GeKo> given our browser dev capacity
20:04:42 <GeKo> and with the goal to have a really good mobile browser
20:04:47 <GeKo> not just for our users
20:05:12 <GeKo> but for us ourselves as well (it's still the gold standard out there :))
20:05:25 <GeKo> and folks trusting our quality
20:05:26 <sysrqb> indeed
20:07:00 <sysrqb> let's see how we do this week
20:07:21 <sysrqb> surely we can load balacnce across three of us easier than load balancing the tor network :)
20:07:39 <sysrqb> (2.x of us)
20:08:22 <acat> :)
20:08:28 <sysrqb> okay, any last comments?
20:08:52 <GeKo> differnt type of difficulty ;)
20:08:57 <GeKo> *differnt
20:08:59 <GeKo> i am fine
20:08:59 <sysrqb> heh
20:09:07 <sysrqb> okay
20:09:13 <sysrqb> thanks
20:09:16 <sysrqb> this retro was helpfu;l
20:09:23 <sysrqb> *helpful
20:09:33 <sysrqb> at lesat for me, i hope it was for you
20:09:34 <GeKo> np, thanks
20:09:37 <sysrqb> i guess we'll see
20:09:52 <acat> thanks, i think it was
20:10:14 <sysrqb> okay, talk with you all later
20:10:23 <sysrqb> have a good week
20:10:25 <GeKo> o/
20:10:31 <acat> o/
20:10:31 <sysrqb> #endmeeting