18:01:33 <gaba> #startmeeting Applications June 29th
18:01:33 <MeetBot> Meeting started Mon Jun 29 18:01:33 2020 UTC.  The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:47 <gaba> Pad in http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-tbb-2020-keep
18:03:15 <gaba> is anybody here?
18:03:16 <gaba> :)
18:03:19 <sysrqb> o/
18:03:23 <mcs> gaba: in the pad, are we supposed to replace last week’s status info or push it down the page?
18:03:25 * sysrqb is waiting for the pad to load
18:03:37 <gaba> replace it
18:03:40 <ahf> yeah, which status update protocol version are we at?
18:03:41 <ahf> ok
18:03:45 <gaba> we have the last status in the mailing list
18:03:48 <gaba> so it is archived
18:03:49 <mcs> thanks. I don’t remember what I did last time :)
18:03:49 * Jeremy_Rand_Talos isn't accustomed to the new pad structure yet, and is waiting for someone I can mimic
18:04:18 <gaba> Jeremy_Rand_Talos : add your name at the end of the pad and add your status
18:09:39 <gaba> are people done with the statuses?
18:10:23 * ahf is done
18:10:27 * mcs is done
18:10:28 * GeKo too
18:10:28 * antonela done
18:10:35 * mikeperry done
18:10:57 <acat> done
18:11:01 * sysrqb done
18:11:24 <gaba> ok
18:11:49 <gaba> I would like us to use this board to keep track of work done in the team: https://gitlab.torproject.org/groups/tpo/applications/-/boards . Is your stuff up to date on what you are working on or what you are planning?
18:12:51 <mikeperry> I have been unable to track down proxy audit-related tickets. I found one for TCP fast open but can't find others. should I file new ones?
18:13:04 <antonela> can acat put an avatar in his gl profile? P
18:13:08 <gaba> Are you saying that you can not find the ticket in gitlab?
18:13:13 <antonela> acat: :P
18:13:19 * Jeremy_Rand_Talos notes that his GitLab account is still inactive, I need to get that fixed.
18:13:28 <GeKo> mikeperry: might be easiest?
18:13:31 <gaba> mikeperry: if there is none then go ahead and file a new ticket
18:13:32 <ahf> Jeremy_Rand_Talos: huh, the email never made it through?
18:13:41 <GeKo> if they are dupes we just dupe them over :)
18:13:45 <ahf> Jeremy_Rand_Talos: let's talk after the meeting :-)
18:13:48 <mikeperry> I think a ff78 proxy audit ticket was never made, is what I am saying. unless I missed it
18:13:54 <acat> antonela: writing it in my todo list :)
18:13:55 <Jeremy_Rand_Talos> ahf, I need to try again, I'll ping you after the meeting
18:13:57 * antonela oooh all of you
18:13:58 <mikeperry> I can assign the other ones too. those I found but are not for the whole thing
18:14:22 <gaba> does anybody have any issue/question about how that kanban board work?
18:14:28 <GeKo> mikeperry: yeah, you are the first one doing that :)
18:14:55 <GeKo> gaba: how do the columns get updated?
18:15:04 <antonela> Do Merge Ready items needs review?
18:15:10 <gaba> the column gets updated when you change the label
18:15:18 <gaba> each stack is one label
18:15:47 <gaba> I saw that there is a merge ready label so I added that stack but we can remove it if it is not usefull. Those issues are already reviewed.
18:16:13 <gaba> you can filter by your name and see everything you are working on or you will be working on
18:16:53 <GeKo> gaba: how does the board cope with the new MR flow that does not use Needs Review and Merge Ready?
18:17:11 <gaba> MRs can also have labels
18:17:15 <gaba> if that makes life easier
18:17:17 <GeKo> or maybe we use those labels? we should decide that :)
18:18:07 <sysrqb> mikeperry: the closes is https://gitlab.torproject.org/tpo/applications/fenix/-/issues/34177
18:18:12 <gaba> the idea of this board is to have a picture of what you all are working on and help planning
18:18:23 <sysrqb> ff78 is a little tricky because we need that for desktop, but not fenix specifically)
18:18:33 <sysrqb> but it's an important step in the fenix work going forward
18:18:50 <sysrqb> antonela: Merge Pready means the review is complete and the patch is ready to be merged
18:18:56 <sysrqb> *Ready
18:19:13 <sysrqb> (into the main code repo)
18:19:21 <antonela> it needs a merge request?
18:19:32 <sysrqb> not for older tickets/patches
18:19:36 <antonela> oh i see
18:19:47 <sysrqb> we're continueing the old process for existing patches
18:19:54 <sysrqb> and we'll use MRs for all new patches
18:19:57 <sysrqb> *continuing
18:19:59 <antonela> gotcha
18:20:27 <sysrqb> maybe, in general, i'll say that all existing patches can follow the old Merge Ready process
18:20:37 <sysrqb> but any new patches (even for old ticket) we should use MRs
18:20:50 <sysrqb> (hopefully that
18:20:55 <sysrqb> that's clearer)
18:21:45 <sysrqb> gaba: can we filter the board for only S58 issues?
18:22:09 <ahf> in the search bar above?
18:22:12 <sysrqb> ah, is that just adding the label
18:22:13 <ahf> Label=Sponsor 58
18:22:14 <ahf> ye
18:22:16 <sysrqb> so easy :)
18:22:22 <ahf> i do it to check just my own stuff
18:22:25 <gaba> yes
18:22:39 <sysrqb> yeah, temporary silly moment for me
18:23:37 <gaba> I forgot if TBB is using milestones but do not see any in applications
18:23:49 <GeKo> not yet
18:23:52 <gaba> ok
18:24:04 <GeKo> but we could like 10.0
18:24:08 <gaba> we will be able to filter the board by milestones whenever we have them
18:24:24 <GeKo> (which is waht we said for the esr transition work for desktop)
18:25:45 <gaba> are we done checking the board?
18:25:46 <sysrqb> gaba: how is the Backlog label used?
18:25:52 <sysrqb> did you add that on some tickets?
18:25:58 <gaba> yes
18:26:23 <gaba> next are the tickets that you are going to be working next. We can use them as a next sprint whenever we decide on time intervals for it
18:26:33 <gaba> Backlog is all the other stuff in the roadmap that needs to be done
18:26:41 <sysrqb> okay
18:26:42 <gaba> but not necesary has anybody assigned to it
18:26:48 <sysrqb> for example, i see https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34432
18:26:59 <sysrqb> which GeKo is working on "child tickets" of it
18:27:09 <sysrqb> but that issue is labeled with Backlog
18:27:18 <gaba> yes, it should be moved to Doing
18:27:29 <sysrqb> ah, okay
18:27:30 <gaba> you all can move the tickets you are working on to the right place
18:27:32 <sysrqb> thanks
18:27:34 <GeKo> done
18:27:50 <sysrqb> yeah, i just wasn't sure if it was labeled as Backlog for a reason :)
18:27:54 <sysrqb> that's all
18:27:55 <gaba> if you filter by assignee with your name you can get the board of what you are working on
18:27:59 <gaba> ok
18:28:22 <gaba> next is checking about reviews that are not assinged or that people need help with
18:28:29 <gaba> how are you all tracking or assigning reviews?
18:28:32 <gaba> does     https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review work?
18:28:44 <sysrqb> we're assiging MRs, when we use them
18:28:53 <sysrqb> and the assignee is the reviewr
18:28:56 <sysrqb> *reviewer
18:29:09 <gaba> so no issues in neds review
18:29:18 <sysrqb> but, for older patches where the branch needing review is posted in a comment on the issue
18:29:22 <gaba> should we remove all those tickets from needs review and remove the stack from the board?
18:29:28 <sysrqb> when we use the Needs Review label
18:29:35 <sysrqb> and i don't remember how we are assigning reviewers for those
18:29:39 <GeKo> gaba: for the sprint part i am not sure that model makes sense for tor browser, see my comment in https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/28#note_2679539
18:29:40 <gaba> there are 12 tickets in needs review that have nobody assigned to it https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review&assignee_id=None
18:29:47 <GeKo> but we'll figure it out
18:30:26 <gaba> geko: right
18:30:32 <sysrqb> the ticekts with Needs Review need reviewers
18:30:47 <sysrqb> we need to keep those labels for now
18:31:10 <gaba> ok, so let's go through the list and see who can take what? https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review&assignee_id=None
18:31:20 <GeKo> how is the reviewer denoted in those cases?
18:31:30 <GeKo> is it the assignee?
18:31:30 <sysrqb> we don't have a process
18:31:37 <sysrqb> i guess we decide that now
18:31:42 <gaba> We could put the ticket in needs review and assign it to none
18:31:46 <GeKo> then we should make one up
18:31:50 <sysrqb> yes
18:31:52 <gaba> each time a person goes to review a ticket hten put their name in asignee
18:32:24 <GeKo> that is for old tickets without an MR or for alk tickets?
18:32:28 <ahf> if you use MR's then MR's can have an assignee that is different from the ticket
18:32:29 <GeKo> *all
18:32:31 <gaba> whenever you are done with the review you put the ticket back into the asignee taht was doing it and move it back to doing ?
18:32:39 <sysrqb> the former, only old tickets with old patches
18:32:40 <gaba> yes, for MRs is easier
18:33:09 <GeKo> how would it look like for the MR case?
18:33:35 <GeKo> because now you can set both labels and assigned on the ticket and MR
18:33:41 <gaba> we can still asign the label to get it in the right stack in the board AND use the MR process for reviewers
18:34:06 <GeKo> hm
18:34:18 <sysrqb> i'd prefer keeping this simple
18:34:28 <sysrqb> and having fewer moving parts on different issues/MRs
18:34:29 <GeKo> but i feel it a bit weird to just keep labels around and set them so the thigns are showing up on the board
18:34:54 <gaba> it is to have a process from planning to done
18:34:57 <sysrqb> do MRs show on the board?
18:35:04 <sysrqb> or, can we add them?
18:35:15 <gaba> MRs will show in the board if they are with the label doing, etc
18:35:20 <gaba> or any label from the stack
18:35:28 <sysrqb> okay
18:36:04 <sysrqb> oh.
18:36:11 <sysrqb> /copy_metadata <#issue>
18:36:11 <gaba> the issue with needs reviews right now is that we have tickets without MRs, right?
18:36:16 <gaba> eh?
18:36:25 <GeKo> gaba: yes
18:36:31 <sysrqb> "Copy labels and milestone from another issue in the project. "
18:37:01 <gaba> ideally there will be some point we will not have tickets with needs reviews but all tickets associated to MRs
18:37:07 <sysrqb> maybe there is a quick action we can use within MRs for updating the issue
18:37:39 <gaba> we need a way to list everything that neeeds a review so people can assign it
18:37:52 <sysrqb> right
18:37:55 <GeKo> gaba: okay, "Needs Review" on MRs is it then
18:38:05 <gaba> :)
18:38:05 <GeKo> but *not* on tickets for the newer model?
18:38:11 <gaba> ok
18:38:34 <gaba> how do you all want to assign those 12 reviews we have here: https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review
18:38:38 <GeKo> because if we set both suddenly we have twice the amount of reviews on the board :)
18:38:46 <gaba> right
18:38:47 <sysrqb> right
18:38:59 <sysrqb> we can try this process
18:39:28 <gaba> anybody else have any thoughts/opinions about this?
18:39:38 <sysrqb> gaba: some of those issues are not a priority
18:39:55 <gaba> sysrqb: what should we do with them?
18:40:00 <sysrqb> so we should review them, at some point
18:40:27 <sysrqb> i would only focus on Needs Review and Sponsor 58 (or milestone 10.0)
18:40:30 <gaba> ok, how do we identify the ones that are a priority?
18:40:31 <gaba> ok
18:40:32 <sysrqb> at this point
18:40:46 <sysrqb> (but we're lacking tht milestone right now)
18:40:53 <gaba> in that case we have Zero https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review&assignee_id=None&label_name[]=Sponsor%2058
18:41:06 <sysrqb> hrm
18:41:15 <sysrqb> https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/33760
18:41:21 <gaba> 11 that needs reviews that seems people are reviewing https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review&label_name[]=Sponsor%2058
18:41:22 <sysrqb> is one with both labels
18:41:29 <sysrqb> ah!
18:41:39 <sysrqb> assignee_id=None
18:41:41 <gaba> yes, these 11 have somebody assign to them
18:42:08 <gaba> are those issues the ones that you all are reviewing? https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/33760 + 2 MR
18:42:09 <GeKo> now we have one for s58
18:42:10 <sysrqb> a ticket like https://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/34189
18:42:18 <GeKo> and i assigned it to me
18:43:00 <sysrqb> 34189 would get the milestone for the desktop work
18:43:11 <gaba> ok, lets add the milestone
18:44:35 <gaba> ok, let's contiue with the agenda that is only 15 more minutes for the hour
18:44:40 <sysrqb> acat: does this process seem reasonable to you? :)
18:45:01 <gaba> yes please, acat, ahf, antonela, others: give your opinions please
18:45:33 <acat> sysrqb: yeah
18:46:09 <sysrqb> okay, great
18:46:24 <sysrqb> gaba: the last item on the agenda is regarding the release?
18:46:36 <gaba> sysrqb: next one is
18:46:39 <gaba> then there are 2 more issues
18:46:44 <gaba> 2 more items
18:46:51 <gaba> release: how are you all doing with it?
18:46:53 <ahf> it is OK with me :-)
18:46:53 <sysrqb> ah, discussion, yes
18:46:59 <sysrqb> ahf: great :)
18:47:21 <sysrqb> the release is about 50% complete
18:47:34 <sysrqb> the new stable version is nearly ready for publishing
18:47:52 <sysrqb> and i start signing the new alpha versoin today
18:48:00 <gaba> great! any help needed or discussion to happen here?
18:48:05 <sysrqb> so that will hopefully be ready for tomorrow, as well
18:48:14 <sysrqb> i don't have any requests right now
18:48:28 <gaba> \o/
18:48:50 <gaba> Next item. The s58 report that Bekeela will send today or tomorrow is at: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/58-report-june
18:49:01 <gaba> please check it out and say something if you think anything is missing
18:50:42 <gaba> And the net item is the review that Antonela is asking for related to dev.torproject.org https://gitlab.torproject.org/tpo/web/trac/-/issues/24132
18:52:13 <GeKo> i've it on my list for this week
18:52:14 <gaba> are people still here? anything else?
18:52:18 <gaba> thanks geko!
18:52:35 <Jeremy_Rand_Talos> Nothing from me today :)
18:53:16 <gaba> :)
18:53:31 <sysrqb> i don't have anything else
18:53:52 <acat> oh, quick question: do we support 1 MR for several tickets in our process?
18:54:13 <sysrqb> i think yes
18:54:13 <gaba> The idea situation would be to have 1 MR per ticket
18:54:17 <gaba> ideal*
18:54:21 <sysrqb> yeah
18:54:40 <sysrqb> but, if one larger feature is divided into multiple issues
18:54:41 <gaba> but still I do not think it would be a problem
18:54:46 <gaba> yes
18:54:52 <sysrqb> then it seems combining them in a single MR is okay
18:54:56 <mcs> how are issues closed? is that automatic?
18:55:22 <sysrqb> GeKo did that with https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/3
18:55:24 <gaba> in an idea situation the person that opened the issue should close it :)
18:55:44 <mcs> OK. So nothing magic happens when an MR is merged?
18:55:45 <gaba> mcs: but for how we are working I think the person working on the issue should close it
18:55:51 <gaba> ahh, no
18:56:10 <mcs> OK. I am not sure why I thought there was magic. Never mind. :)
18:56:13 <sysrqb> i heard gitlab can be smart about closing isuses if the commit message says it closes that issue (in a certain format)
18:56:15 <acat> mcs: i think one way is to add a "Fix YYY" comment in the MR description and i think when merging it it's automatically closed
18:56:16 <gaba> there is always magic :)
18:56:18 <sysrqb> but i haven't tried it
18:56:33 <gaba> nice
18:56:33 <acat> or "Fixes YYY"
18:56:44 <sysrqb> ah, in the MR is nicer
18:56:59 <sysrqb> then it won't pollute the commit message
18:57:17 <mcs> maybe something to experiment with then
18:57:22 <sysrqb> yes
18:57:45 <ahf> we have used it in the network team, if an MR is attached to an issue, the MR gets closed upon merge (also via torproject-pusher from git.torproject.org) and the MR closing closes the issue too
18:57:48 <acat> https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern
18:57:49 <ahf> is very nice
18:58:18 <sysrqb> huh, i wonder why i didn't see this happen
18:58:23 <sysrqb> that is nicer behavior
18:58:34 <sysrqb> okay, we'll experiment with it
18:59:03 <gaba> ok. I will close the meeting and we can continue talking about it in other channel.
18:59:04 <sysrqb> acat: thanks
18:59:07 <gaba> #endmeeting