13:58:04 <el_cubano> #startmeeting
13:58:04 <MeetBot> Meeting started Thu Jan 25 13:58:04 2024 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:58:12 <el_cubano> #topic Roll Call
13:58:30 <el_cubano> Hello everyone! Please say 'hi' (or something) to record your attendance
13:58:33 <helmut> hi
13:58:36 <ta> hi
13:58:44 <h01ger> hi
13:58:51 <bunk> .
13:58:51 <petn-randall> hi
13:58:55 <tobi> hi
13:58:56 <guilhem> hi
13:58:59 <tumbleweed> \o
13:59:11 <jochensp> hi
13:59:13 <santiago> o/
13:59:42 <buxy> hi
14:00:18 <pochu[m]> o/
14:01:10 <el_cubano> And we have noted on the agenda that spwhitton will miss the meeting.
14:01:15 <el_cubano> So, I think that is everyone.
14:01:18 <el_cubano> Let's get started.
14:01:30 <el_cubano> #topic Contributor hours management
14:02:46 <el_cubano> As announced in December, we have implemented a 'dormant contributor' policy, where if a contributor goes two months in a row with available hours but makes no report then that is considered to have gone dormant
14:03:06 <el_cubano> If I recall correctly, last month there were no warnings issued (i.e., nobody crossed that threshold)
14:03:53 <el_cubano> Next month (February) when the dispatch is done I will mail out warnings (rather than taking action). Starting in March, if the script flags you as dormant, your hours will be reclaimed and you will be set to 'inactive'.
14:04:20 <el_cubano> I'll announce this once more in next month's meeting for maximum visibility.
14:04:27 <el_cubano> Any questions on this topic?
14:04:57 <santiago> not from my side
14:05:19 <ta> no, everything is fine
14:05:23 <pochu[m]> sounds reasonable
14:05:28 <helmut> thanks for being so careful
14:05:34 <petn-randall> sounds like a sensible implementation
14:06:40 <el_cubano> OK. Thanks to everyone for your help with this. I also want to mention that in preparing the last couple of monthly reports I have been very pleased with the overall quality of the individual reports.
14:06:59 <el_cubano> It has really made the monthly report process very smooth and it provides plenty of interesting highlights.
14:07:22 <el_cubano> Alright, so moving to the next topic
14:07:28 <el_cubano> #topic Usefulness of commit notifications to the mailing lists
14:07:35 <el_cubano> santiago: you have the floor
14:07:42 <santiago> thanks!
14:08:08 <santiago> the point is: the email notification for every commit is likely too much for everybody. The notifications are sent to the whole team, and we are planning to change the destination address to lts-coordinator.
14:08:44 <utkarsh2102> (late hi!)
14:08:54 <santiago> is there any objection?
14:08:59 <el_cubano> utkarsh2102: o/
14:09:03 <santiago> is there any notificaiton that someone finds useful?
14:09:12 <petn-randall> I agree, I think it's of little use as everyone has a copy of the git history. If someone needs mails for this, I think they can sign up with their private mail.
14:09:27 <petn-randall> So +1 for removing it from the mailing list.
14:09:39 <pochu[m]> for which repos are we talking about?
14:09:43 <guilhem> is that gitlab.com/freexian/services/deblts-team/debian-lts?
14:09:50 <tobi> +1, (even though my sieve filter will get bored ;)
14:09:59 <ta> yes, I would like to see the commit of my working hours to be sure that I have done it
14:10:14 * h01ger likes commit notifications too
14:10:31 <ta> so where can I subscribe? :-)
14:11:02 <helmut> We can also filter them at the client. Is there an expectation for contributors to read them as a means of communicating important changes?
14:11:04 <ta> (the git history does not tell me that I really pushed)
14:11:55 <tobi> ta: git log shows you if your head is in origin
14:12:09 <santiago> sorry if this was not obvious. yes, for gitlab.com/freexian/services/deblts-team/debian-lts, and also for the elts security-tracker
14:12:30 <pochu[m]> please don't filter the elts sec-tracker
14:12:48 <buxy> ta: the lack of warning by Roberto also tells you about it :-)
14:12:56 <ta> tobi: ok
14:13:00 <pochu[m]> would be ok to filter the automatic merge commits though
14:13:25 <ta> buxy: the warning goes to everybody, doesn't it?
14:13:26 <santiago> mmm, not sure how it would be possible to filter only the automatic merge commits
14:13:42 <buxy> ta: no the warning is sent to each individual
14:14:11 <el_cubano> How about if we create a -changes group (along the lines of debian-devel-changes, debian-lts-changes, etc) and anyone who wants commit notifications can subscribe to that group?
14:14:37 <buxy> I assume the ELTS security tracker mail is mainly useful to those doing frontdesk? Would it make sense to have something specific to subscribe to for people taking part to this?
14:14:48 <santiago> el_cubano, that is the only solution I would have in mind
14:15:26 <el_cubano> santiago: OK. Perhaps I misunderstood. It seemed at the start that you were suggesting redirecting the notifications to lts-coordinator
14:15:30 <ta> buxy: so you don't mean the "Reminder - Please report .." emails?
14:15:43 <santiago> el_cubano, that is was initially suggested
14:16:29 <utkarsh2102> el_cubano: a separate -changes list would be a good idea unless it’s too much hassle.
14:16:37 <helmut> I don't see consensus in reducing commit notifications and question the benefit/effort for splitting the list as opposed to filtering at the receiving end
14:16:46 <buxy> ta: on the 8th or 10th you can get direct mails with a title like "LTS Report Reminder for December" if you have failed to do your report
14:17:05 <utkarsh2102> I sometimes check what’s being added to dla/ela-needed via mail. But I can change my workflow, of course.
14:17:48 <utkarsh2102> I also like to see other sec tracker commits by sec team to see what they’re triaging, et al, et al
14:17:53 <utkarsh2102> sometimes come in handy
14:18:00 <ta> buxy: oh, it is not about the report but putting the hours into the ledger
14:18:21 <buxy> ah ok, sorry
14:18:27 <utkarsh2102> again, I’m more than happy to change my way or subscribe privately. So no objections either way.
14:19:06 <santiago> should we vote about having a dedicated list/group, or keeping the status quo?
14:20:14 <el_cubano> santiago: That sounds good
14:20:37 <el_cubano> I suggest setting up a poll and sending it to extended-lts-team@freexian.com (as that is the address which receives the commit emails)
14:20:47 <buxy> It would be at least good to know if some people would be happy to not receive the commit notifications (because they get in the way, or because they don't need theme).
14:21:18 <buxy> There 3 sources of commit noficitions, the two repository to track hours an the ELTS security tracker.
14:21:20 <santiago> buxy, yes, that is right
14:21:25 <helmut> Do I understand correctly that reading the commits to stay up to date is not required? (and other means of communicating change such as non-commit mails are always used)
14:22:10 <buxy> helmut: given the amount of noise, I think it's fair to no longer expect everybody to read all commit notifications, yes
14:22:21 <el_cubano> +1
14:22:29 <helmut> from my pov, that's enough :)
14:22:33 <petn-randall> Conceptually, I think they should be opt-in, and I'm thinking of newcomers to the LTS team. The on-boarding should not involve triaging the correct (sieve) filters.
14:24:29 <buxy> Agreed.
14:24:29 <santiago> any other comment? AFAICS, we could have a dedicated list
14:24:31 <el_cubano> petn-randall: That's an excellent point
14:24:40 <el_cubano> santiago: I concur
14:25:39 <santiago> As I can see, there is consensus on that sense. Everybody would be free to subscribe to it, or not
14:25:49 <santiago> any objection?
14:26:02 <el_cubano> So to make sure I am clear on what we are doing: no poll, create a dedicated list, announce the list to everyone so that they subscribe if they wish, then stop the messages going to extended-lts-team@freexian.com
14:26:10 <ta> no, this is fine with me
14:26:25 <el_cubano> santiago: Does my summary capture it?
14:26:46 <helmut> +1
14:26:49 <h01ger> +1
14:26:49 <petn-randall> +1
14:26:58 <santiago> el_cubano, that is how I see this; yes
14:27:04 <ta> el_cubano: ... and add an entry in the onboarding documentation that this list exists
14:27:20 <tobi> I can also provide my sieve filters ;-)
14:27:35 <tobi> (additonally)
14:27:41 <el_cubano> #action santiago el_cubano redirect commit notifications to a dedicated list/group, announce the change, and document this in the onboarding docs
14:27:55 <el_cubano> ta: Good point. I added that in the action item
14:28:13 <el_cubano> tobi: If you could mail those to us at the coordinator address, that would be good
14:28:26 <el_cubano> OK. So, let's move to the next topic
14:28:35 <el_cubano> #topic Notification: please update python3-pyxian before the end of the month
14:28:41 <el_cubano> santiago: You again have the floor
14:28:49 <santiago> thanks again
14:29:07 <santiago> and actually, I think all the information is already in the agenda (thank you buxy?)
14:29:31 <buxy> (not me)
14:29:40 <helmut> https://pad.riseup.net/p/lts-meeting-agenda
14:30:23 <el_cubano> santiago: I was the one who added the extra info to the agenda
14:30:36 <santiago> tl;dr: It is recommended that you use the command 'freexian monthly-report' to submit your hours reports, rather than crafting entries manually. And please upgrade python3-pyxian before the end of this month
14:31:33 <santiago> everything is clear in the agenda, so let me just copy+paste it:
14:31:38 <santiago> Beginning immediately, when a monthly report is made it will be dated on the last day of the month for which the report is being made and the entry will be inserted at the appropriate place in the ledger
14:31:53 <h01ger> are there plans to upload python3-pyxian to unstable?
14:31:56 <santiago> I.e., all February reports will be dated 2024-01-31, all March reports will be dated 2024-02-29, etc.
14:32:33 <el_cubano> Is anyone in the habit of creating ledger entries manually?
14:32:48 * petn-randall raises hand.
14:32:53 * ta is doing this
14:32:55 * h01ger too
14:33:05 <tobi> yeah, but I'm looking forward to have a tool for it
14:33:13 <petn-randall> I wasn't aware that there's an other tool for this.
14:33:14 <h01ger> (but i've added a todo to switch to the tool)
14:33:16 <buxy> h01ger: there are no such plans currently, I'm not opposed to it either, but it seems a bit weird for something that is restricted to very few persons
14:33:39 <helmut> the user base for pyxian seems to small to me to justify an upload
14:33:58 <h01ger> the user base is not that small.
14:34:13 <h01ger> there are several many packages with less users
14:34:18 <jochensp> I think uploaded it to unstable is fine
14:34:28 <buxy> if you have issues with the tool and/or its documentation, please raise them so that we can get them fixed
14:34:34 <h01ger> but shrugs, i'm not too bothered about it
14:36:05 <guilhem> i would welcome an upload to sid too
14:36:10 <santiago> the upload the unstable is something that we could discuss in another moment
14:36:40 <el_cubano> I agree that this should be further discussed another time.
14:36:44 <helmut> I also note that a number of contributors expressed working on an older release than unstable (sometimes not even bookworm), so we'd not reach them with uploading to unstable unless also backporting
14:37:09 <santiago> are thy LTS users? :-)
14:37:18 <el_cubano> helmut: That was one of the points I was going to make. I would need to use a backport or pin from unstable
14:37:51 * petn-randall runs stable most of the release cycle.
14:38:01 <buxy> I note that while installation of pyxian is documented, the use of "freexian monthly-report" doesn't seem to be.
14:38:14 <el_cubano> For the moment, however, the important thing seems to be that everyone needs to be made aware of the need to sequence ledger entries correctly and that the recommended way to do this is by using the 'freexian monthly-report' command
14:38:24 <helmut> I'd expect pyxian to change more rapidly than stable releases accomodate
14:38:27 <el_cubano> buxy: I was getting to that :-)
14:38:53 <el_cubano> So, do we need to announce to everyone that this is now the preferred way (e.g., via the mailing list) and then document this in the onboarding docs for new contributors?
14:39:22 <pochu[m]> probably worth a mail, yes
14:39:38 <ta> el_cubano: I would say so, yes
14:39:43 <santiago> +1
14:40:18 <buxy> Yes, please. And we should aim to add to pyxian some basic commands for contributors to look up their remaining hours and to give them back.
14:40:45 <santiago> any other comment?
14:41:45 <el_cubano> #action el_cubano in the near term, announce to everyone that 'freexian monthly-report' is the recommended way to make entries (especially for proper sequencing)
14:41:47 <santiago> #action: el_cubano santiago to send a mail to inform the preferred way to add entries when reporting the hours, and to document this
14:42:01 <el_cubano> :-)
14:42:31 <el_cubano> #action el_cubano santiago in the longer term, look at adding to pyxian some basic commands for contributors to look up their remaining hours and to give them back.
14:42:45 <el_cubano> OK. That seems like everything for this topic.
14:43:03 <el_cubano> #topic Mandatory dcut migration for ELTS (and later LTS)
14:43:14 <el_cubano> santiago, helmut: you're up
14:43:27 <helmut> I uploaded dput-ng 1.38 to unstable ahead of the meeting
14:43:47 <helmut> Some of you have already used dcut migrate on ELTS uploads (I know this is the LTS meeting ;)
14:44:17 <helmut> Are there any objections to a) make that dcut migrate workflow mandatory for ELTS very soon? b) make that dcut migrate workflow mandatory for LTS later?
14:45:02 <utkarsh2102> no objections for me.
14:45:09 <helmut> difference to workflow now: after upload you're expected to check a britney excuses url (to be added to documentation) and issue "dcut migrate srcname srcversion" to put your changes live
14:45:09 <utkarsh2102> s/for/from/g
14:45:11 <tobi> I think it is a good thing to have this feature
14:45:25 <ta> no to a) and b)
14:45:36 <helmut> you can then sync issuance of your DLA/ELA with that dcut migrate command
14:46:03 <tobi> I'd also like to see that feature for LTS...
14:46:18 <helmut> tobi: pochu[m] is working on that
14:46:31 <santiago> helmut, could you remind the dcut command for rejecting the changes please?
14:46:44 <tobi> cool, thanks pochu[m] (and helmut of course)
14:46:54 <helmut> santiago: it'll be in the docs. dcut migrate --reject srcname srcverion
14:47:28 <santiago> helmut, pochu[m]: thanks a lot for your work on this to both of you
14:47:31 <helmut> ok. we'll announce a flag day (at least one week in future of sending the announcement) to change the workflow
14:48:09 <helmut> I'll update the docs before taking effect, but that means the docs briefly do not reflect reality
14:48:54 <helmut> handing the microphone back
14:49:46 <el_cubano> #action helmut add dcut workflow to docs and announce when the switch will take place
14:50:33 <helmut> you may already use the dcut workflow if changing the login to extended-lts-staging (for ELTS), but that'll change back to extended-lts
14:51:31 <el_cubano> OK. Does anyone else have anything to add on this topic?
14:52:37 <santiago> not me. thanks
14:52:43 <el_cubano> Then it seems like we are done with this topic.
14:52:47 <el_cubano> Moving on
14:52:50 <el_cubano> #topic AOB
14:53:03 <el_cubano> Does anyone have anything they'd like to mention at this point?
14:53:39 <santiago> o/
14:54:21 <santiago> I am looking for someone using a sid machine to confirm petn-randall's ftf works or not
14:54:41 <santiago> I haven't had time to dig on the issue I encounter here
14:54:59 <santiago> so it would help, for the moment, if it's just not me
14:55:58 <el_cubano> So, if anyone is able to help santiago with this, please ping him and let him know
14:56:02 <el_cubano> Anyone else?
14:56:39 <el_cubano> OK. So it seems like we're about done
14:56:49 <el_cubano> One final thing, the reminder for next month's meeting
14:56:52 <el_cubano> Next meeting: Thursday, February 22, 14:00 UTC on Jitsi https://jitsi.debian.social/LTS-monthly-meeting
14:57:07 <el_cubano> And with that, thanks to everyone for participating today!
14:57:15 <santiago> thank you el_cubano
14:57:21 <ta> thank you
14:57:33 <el_cubano> #endmeeting