13:58:22 <buxy> #startmeeting
13:58:22 <MeetBot> Meeting started Thu Sep 22 13:58:22 2022 UTC.  The chair is buxy. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:58:42 <buxy> #topic Who is here?
13:58:51 <el_cubano> o/
13:58:52 <Beuc> o/
13:58:56 <buxy> Now is the time to say "hi" :-)
13:58:59 <ta> o/
13:59:00 <apo> ^^
13:59:00 <el_cubano> hi
13:59:00 <tumbleweed> o/
13:59:11 <utkarsh2102> yo-yo
13:59:15 <el_cubano> Or as we say, hola
13:59:23 * lamby -> Chris Lamb
13:59:25 <pochu> o/
13:59:28 <Natureshadow> moin
13:59:30 <helmut> Helmut Grohne
13:59:58 <buxy> Anton can't make this meeting, so I'll chair it.
14:00:09 <lamby> Thanks, buxy
14:00:15 <buxy> As usual the agenda is over at https://pad.riseup.net/p/lts-meeting-agenda
14:01:01 <buxy> #topic How to make sure that people in charge of FD do not forget it?
14:01:27 <pochu> I have a cron job that sends me an email if I'm fd :)
14:01:47 <buxy> AFAIK, we recently had a case where there was no FD work done for a week because someone forgot.
14:02:15 <apo> for almost two weeks
14:02:24 <utkarsh2102> automate salsa (trivial enough) to spawn up an issue mentioning the person in charge?
14:02:34 <buxy> It's true that between assignation of FD weeks and the actual week, there are sometimes multiple months, so it's easy to forget if one has not written it down in his usual workflow.
14:03:04 <tumbleweed> put the FD in the IRC topic and have the previous update it at the end?
14:03:10 <buxy> It would be nice to provide some automation to avoid that kind of mistake... but what exactly do we want/need?
14:03:15 <helmut> question from the one who doesn't know the processes: is there an active handover of open issus from one fd to the next? if not, why is that not needed?
14:03:54 <Natureshadow> I made a tool that can schedule issues and assignments in a GitLab instance given a configuration repo: https://edugit.org/nik/gibihm
14:03:55 <lamby> I would guess that anything that generates an email (including creating a salsa issue, I suppose by extension) would be enough to cover most cases.
14:03:57 <apo> there is a list of open issues and a script that takes care of automatic EOLing, so it is often pretty much self-explaining
14:04:13 <pochu> helmut: there's not, usually fd triages from lts-cve-triage.py's output
14:04:56 <buxy> Anton already sends a weekly status email, should that email also include the name of the person in charge of FD and ask that person to reply with an ack?
14:05:40 * ta got a reminder  email from Anton at the beginning of this week, so I think this is enough
14:05:46 <pochu> buxy: that could be a start... the question then is, what happens if fd doesn't ack?
14:06:13 <buxy> someone else jumps in?
14:06:15 <el_cubano> We could deploy the drones at that point
14:06:36 <pochu> buxy: ok, sounds reasonable
14:06:37 <utkarsh2102> I could set up a drone.
14:07:21 <pochu> the problem with Anton's email is that it won't be until late Monday or even Tuesday. if we add a 48h period to ack that, then we're already Thursday
14:07:43 <buxy> #action gladk should expand his script generating the weekly status email to also give the person in charge of FD this week
14:07:53 <utkarsh2102> buxy: for the automation part, there’s a way in gitlab (and thus salsa) to do that. Create weekly issues and ping the person in the queue. Where the queue is know, of course :)
14:08:01 <utkarsh2102> just fyi^
14:08:22 <utkarsh2102> not saying we need to or want to. Anton’s ping should suffice.
14:08:39 <utkarsh2102> if the problem still persists, we can revisit the topic in the next meeting.
14:08:50 <utkarsh2102> or have a retrospective regardless.
14:08:51 <buxy> utkarsh2102: I'd gladly take a link to the relevant documention, but I assume it's something custom built out of the GitLab API, no?
14:09:16 <buxy> #info if the FD person doesn't ack the weekly email, then someone else jumps in
14:09:35 <buxy> Now somewhat related...
14:09:39 <utkarsh2102> buxy: I’ll have to take a look for the documentation. I’ll link it after the meeting. Not on system atm.
14:09:49 <buxy> #topic What are the expectations for FD work?
14:09:56 <Beuc> If you see that some packages need triage, and FD was not responsive, ping him again and start triaging?
14:10:58 <buxy> I usually expect that people in charge of FD do CVE triaging on a daily basis on work days at least, is that a shared expectation?
14:11:21 <Beuc> yes for me
14:11:23 <pochu> buxy: yes
14:11:28 <utkarsh2102> yes and answer questions on IRC or email, if needed.
14:11:43 <buxy> by work days I mean Monday to Friday, but security issues do not stop during week-ends
14:12:06 <ta> yes for me as well
14:12:56 <buxy> Do we relax rules to bypass FD during WE or do we expect FD to also work during WE?
14:13:01 <lamby> Yes for me as well.
14:13:20 <utkarsh2102> not make a compulsion for the weekend, I think.
14:13:36 <utkarsh2102> unless there’s something critical or on fire, things can wait a day or two.
14:13:56 <ta> I would say on urgent issues FD can be bypasswd on the weekend and holidays, but not for normal stuff
14:14:35 <buxy> OK. Looks reasonable. What is our definition of urgent?
14:15:09 <apo> if there is a DSA release that mentions RCE or similar, then it is urgent
14:15:42 <Beuc> It's pretty rare that something is so urgent that a day or two matters, usually in such cases (e.g. sudo CVE) somebody feels entitled to take things over, probably one of the people on the private secteam list
14:16:04 <Beuc> otherwise if FD did work during the week there's plenty to do during the week-end
14:16:05 <utkarsh2102> yep. I agree.
14:16:07 <buxy> I assume embargoed issues never leave embargo during the WE
14:16:55 <ta> yes DSA and RCE = urgent
14:17:02 <apo> buxy: not sure, but we are aware of them anyway because Thorsten and myself get notified
14:17:09 <lamby> Happy to leave such a definition partly subjective; the urgent cases are indeed quite few (DSA-1571, sudo, log4j, etc.)
14:17:13 <ta> I have never seen an embargo ending on the weekend
14:17:30 <buxy> #action gladk to file an issues asking someone to summarize the outcome of this discussion about expectations for FD work
14:17:41 <helmut> I already did on the pad
14:18:07 <utkarsh2102> all hail helmut :)
14:18:29 <buxy> Nah I mean documenting the FD expectations more clearly somewhere in our documentation
14:19:46 <buxy> Ok, anyone willing to take the above ticket before it's submitted? i.e. work on the doc?
14:20:24 <buxy> Ok moving on then.
14:20:51 <buxy> #topic Are there LTS contributors who could work more and do ELTS work too?
14:22:04 <buxy> We seem to have some backlog in ELTS, it's true that we expanded recently by adding stretch on top of jessie, and that we are not dispatching all the hours that we have available (which are based on the estimation we use to define our prices).
14:23:00 <Beuc> I can work on the FD doc, I have a change I mentioned in a recent discussion ("Re: ELTS frontdesk and webkit2gtk"), that I plan to apply
14:23:36 * utkarsh2102 can look at more ELTS packages that LTS ones.
14:23:46 <buxy> I have asked a few collaborators to focus a bit more on ELTS (enrico, helmut) to try to resolve that situation... but it could be useful to have more people in general.
14:23:57 <utkarsh2102> hoping to reduce the queue by a little thereby.
14:24:27 <buxy> utkarsh2102: hoping to have people spend more time on LTS/ELTS, not having other spend more time on ELTS and having to decrease LTS due to that
14:24:54 * pochu has been looking at that list of "packages added long ago", slowly making progress
14:25:09 <pochu> more hands would certainly be welcome
14:25:11 <utkarsh2102> it’d be a workaround to the issue, true.
14:25:14 <buxy> also it might be that my perception is skewed and that we just have more in-progress updates in ELTS because they are older and it's harder to complete them quickly
14:25:59 <el_cubano> Over the last several months I committed to several non-packaging issues.  I'm trying to knock those out and still hit a few packages now and again.  By next month I should have considerably more time to dedicate to both LTS and ELTS
14:26:36 <buxy> Great, but if anyone knows other DD that could possibly join, don't hesitate to suggest names and Anton or me, we can reach out.
14:27:41 <buxy> Beuc: thank, can you file the ticket and self-assign it then? I assume it will go in lts-team.pages.debian.net
14:27:56 <Beuc> ok
14:28:42 * enrico follows on and off, got workers in the office room
14:29:05 <buxy> Ok, moving to the next point.
14:29:24 <buxy> #topic Update on the DD survey analysis by Roberto
14:30:32 <el_cubano> So, I've been working on the DD survey analysis.  I started around the last week of August and worked through the first week of September, then I just started it again today.
14:31:28 <el_cubano> I have a LibreOffice spreadsheet that I created for the initial visualisation beyond what the SurveyMonkey PDF provided and then I started working in a Google Doc that buxy created.
14:32:32 <el_cubano> The work on the report is roughly 2/3 to 3/4 completed.  My goal is to have the initial draft completed in the next few days then make any necessary revisions/corrections before buxy publishes it.
14:32:56 <el_cubano> That said, please don't feel that you need to wait for the draft to be completed before you have a look.
14:33:31 <el_cubano> If you are interested in the survey and its results, feel free to have a look and make comments.
14:34:11 <el_cubano> I would prefer comments (or even suggestions with change tracking enabled) rather than direct edits just so I can keep everything in my head of what is where.
14:34:37 <buxy> I don't know if we shared the link already, I'll do that over deblts-team@ I guess
14:35:38 <el_cubano> That sounds good.  The link I received was a direct mail, so I don't think everyone has it yet.
14:36:13 <utkarsh2102> I do have the direct link, too. So I can confirm.
14:37:49 <buxy> Ok mail sent.
14:38:07 <buxy> el_cubano: anything else you wanted to share/say?
14:38:45 <el_cubano> No, that was all I had to say about the survey.
14:38:48 <el_cubano> Thanks.
14:39:08 <buxy> #topic Any other business
14:39:33 <buxy> We have completed today's agenda, did you have other questions or things to mention before we close the meeting?
14:39:46 <utkarsh2102> LTS sprints (:
14:39:58 <pochu> I wanted to bring up how sometimes we reclaim or update a note of a package by just modifying the date, without adding any useful content. I think we should change that practice, and add extra notes rather than modifying a previous one, or reclaiming a package without adding any info
14:40:33 <pochu> sometimes that happens more than once (e.g. a whole month without any real update), if there's progress it should be noted, if there's not, perhaps one should give others a chance to work on that package
14:41:12 <lamby> Do you think those cases are trying to communicate "yes I'm still working on it, please don't return to the pool yet" ?
14:41:35 <Beuc> +1  I think you already called for this in the past, checking if this is documented
14:42:40 <pochu> lamby: I don't know, because there's no extra info
14:43:15 <buxy> That sounds fair, I was also surprised by seeing reclaims where people just add their name back without adding any extra info.
14:43:39 <Beuc> we can add a bit at https://lts-team.pages.debian.net/wiki/LTS-Development.html#claim-the-issue-in-the-security-tracker-in-dla-needed-txt
14:45:10 <buxy> I fear that page is growing too much... do we have a place where we document the semi-automatic unclaim?
14:45:36 <Beuc> same page I'd say
14:46:36 <Beuc> or the page for the coordinator's duties, but contributors don't read it
14:47:14 <buxy> Beuc: can you open a ticket to discuss this further? and maybe a make proposal with a MR?
14:47:21 <buxy> or pochu?
14:47:34 <utkarsh2102> I just wanted to add that I totally agree with this. I’m someone who did this recently, only because the packages are ready and I thought I’d just release them this week. But I think it’s my bad, I could’ve just added that comment instead.
14:47:42 <utkarsh2102> so I agree and apologize. :)
14:48:14 <Beuc> I'll make that ticket too after the meeting, pochu you can contribute :)
14:48:27 <pochu> Beuc: cool, thanks :)
14:48:47 <buxy> #action Beuc to create a ticket to document the need to expand info in dla-needed.txt when reclaiming a package
14:49:11 <buxy> Great, anything else to discuss?
14:49:45 <pochu> Beuc: also about not doing s/20220915/20220922/ without actually editing the note. I'd rather see an extra note, but maybe that's just me
14:49:53 <pochu> (sorry, moving on)
14:50:01 <Beuc> noted
14:50:02 <utkarsh2102> I’d say LTS sprints (maybe w/ FOSDEM) but I don’t have anything to add in that.
14:50:26 <utkarsh2102> just brining it up since we discussed this months ago. But COVID prevented us from discussing further.
14:50:35 <utkarsh2102> but that’s that. Nothing to add from my side.
14:51:15 <buxy> utkarsh2102: you want to bring all the team in a single place or just try to gather some people together in events that they would already attend?
14:51:44 <utkarsh2102> either would be nice, I think. :)
14:52:36 <tumbleweed> there is a training centre near brussels that we've used for video sprints around fosdem before
14:52:51 <tumbleweed> but that's if you want dedicated days before/after the event
14:53:54 <buxy> It seems unlikely that we will bring together all the LTS contributors, many are working a few hours per month only and I don't expect them to be willing to travel for this "side-activity" but maybe I'm wrong. A first step could be to ask everybody if they would be interested in something like this.
14:54:30 <buxy> And how far they are willing to go and whether there are some events that they are already attending anyway, etc.
14:55:43 <buxy> To me, it seems more likely to bring together the subset who are Freexian collaborators.
14:56:14 <lamby> I have a "hard-out" now I'm afraid, but it looks like we are deep into AOB. Thanks for running the meeting, and speak soon, all. o/
14:57:24 <buxy> Yeah, and we are moving past the pure LTS territory, so I will stop the conversation here. But utkarsh2102 I invite you to continue to explore that option further with us if you are interested.
14:57:35 <utkarsh2102> gotcha, thanks!
14:57:47 <buxy> Thank you everybody for the fruitful discussion today.
14:57:55 <pochu> thanks o/
14:57:56 <utkarsh2102> yay, thank you, indeed!
14:57:59 <buxy> #endmeeting