13:57:47 <el_cubano> #startmeeting
13:57:47 <MeetBot> Meeting started Thu Nov 30 13:57:47 2023 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:57:47 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:57:57 <el_cubano> Hello Everyone!
13:58:20 <spwhitton> Greetings from Sean Whitton
13:58:37 <spwhitton> (wanted for minutes I assume)
13:58:51 <bwh> Hi all
13:58:57 <el_cubano> I hope that everyone who travelled to the Mini-DebConf in Cambridge had a good time and made it home safely.
13:58:58 <helmut> hi
13:59:10 <bunk> .
13:59:11 <el_cubano> I personally had a great time and especially enjoyed meeting many of you IRL for the first time.
13:59:15 <santiago> hi!
13:59:20 <spwhitton> I am envious of those of you who went and wish I had made it.
13:59:26 <el_cubano> Please go ahead and say 'hi' if you haven't already so we have a record of who is here.
13:59:31 <guilhem> hi there
13:59:32 <lamby> Hi!
14:00:07 <tobi_m> hi
14:00:21 <Beuc> o/
14:00:41 <santiago> (#topic rollcall ?)
14:00:49 <el_cubano> We also have apologies from utkarsh2102, tumbleweed, and rouca; so they will not be here
14:01:01 <el_cubano> santiago: Argh! I forgot
14:01:07 <el_cubano> Next time ...
14:01:27 <el_cubano> #topic December meeting
14:01:41 <el_cubano> As noted in the agenda: December meeting will take place on the *third* Thursday (rather than the *fourth*) on 2023-12-21 at 14:00 UTC (to avoid falling between Christmas and New Years)
14:02:08 <el_cubano> I am assuming that there are no questions/discussion on this. However, in case there are, does anyone want/need to bring up anything related to this?
14:02:08 <lamby> Confirmed :)
14:02:41 <bwh> I will already be on vacation, so will not be attending
14:03:32 <el_cubano> bwh: Thanks for the heads up
14:03:36 <el_cubano> OK. Moving on
14:03:48 <el_cubano> #topic Infrastructure changes for LTS (and ELTS) uploads
14:03:52 <el_cubano> helmut: You're up
14:04:12 * spwhitton is excited for this
14:04:24 <helmut> I know it's short notice, I sent an email a couple of hours ago about changes to ELTS uploads. did anyone get it?
14:04:39 * spwhitton saw the one for buster
14:04:41 <el_cubano> spwhitton: And you didn't get to hear about for 6 days in eager anticipation like some of us did ;-)
14:04:45 <tobi> yes, saw the mail for ELTS
14:04:54 <spwhitton> :)
14:05:16 <helmut> good. not gonna repeat here. any objections for changing from scp to sftp or for adding another step to the upload process?
14:05:34 <lamby> None here.
14:05:45 <santiago> nop here
14:05:59 <helmut> assuming there are no objections, you all need to change your .dput.cf after the meeting, right?
14:06:21 <Beuc> and switch to dput-ng iiuc?
14:06:37 <el_cubano> helmut: Will you be sending a follow-up email with precise instructions and a sample config? If not, could you please do that after the meeting?
14:06:50 <bwh> I have a question about how this will affect signed builds of linux, but I think that doesn't need to be answered right now
14:07:01 <helmut> Beuc: I think dput (non-ng) is using sftp when it says scp, so either you're using <=bullseye or dput shouldn't be working
14:07:04 <el_cubano> As in, 'install dput-ng, adjust alternatives if needed, add this config snippet here' and such?
14:07:36 <helmut> bwh: let's take that to query or mail then
14:08:44 <tobi> docs might need updating too
14:08:52 <helmut> Beuc: I'm actually not exactly sure how the change affects dput (non-ng), but we expect you all to be moving to dput-ng OR reimplement the upcoming dcut plugin in dput
14:09:30 <helmut> Beuc: would you volunteer to do a test upload via the (converted) staging queue?
14:09:46 <helmut> tobi: any places I might miss?
14:10:01 <Beuc> https://freexian.gitlab.io/services/deblts-team/documentation/elts/information-for-extended-lts-contributors.html#initial-setup
14:10:02 <spwhitton> the ELTS docs website has sample config.
14:10:05 <spwhitton> that
14:10:24 <tobi> helmut: not sure, didnt check, but there was a section IIRC in the LTS documentation
14:10:34 <tobi> currently on the road, so cannot check right now
14:10:57 <helmut> good. I'll look into bwh's concerns, get feedback from Beuc and if both work we move forward (+ a followup mail + updating docs)
14:11:37 <el_cubano> OK. So, that seems like there just a couple of housekeeping points and then we should be in good shape to proceed with the change (post-meeting)
14:11:47 <Beuc> helmut, I have a few things on my plate right now, maybe check with other contributors for the test upload
14:12:02 <helmut> any objections to changing from "dput; wait for builds; send dla" to "dput; wait until convenient; dcut migrate + send dla"?
14:12:10 <tobi> helmut, what CI is run after the upload?
14:12:22 <helmut> anyone else not using dput (without -ng)?
14:12:44 <spwhitton> helmut: *not* using it?  I am using dput-ng.
14:12:47 <helmut> tobi: britney2 schedules autopkgtests just like on testing migration. you cannot see results just yet
14:12:48 <el_cubano> tobi: That's covered in helmut's email earlier today
14:13:11 <tobi> ok, thanks
14:13:29 <helmut> spwhitton: sorry. negation failure. I'm looking for dput (non-ng) users now
14:13:38 <bunk> I have something to upload today (last day of month), could yo make the change tomorrow?
14:13:41 <spwhitton> coolio
14:13:42 <bwh> Yes I'm currently using dput
14:13:47 <el_cubano> OK. Any objections to moving to the next topic? Or do we need a few more minutes on this one?
14:13:47 <helmut> bunk+1
14:14:00 <guilhem> also using dput atm
14:14:09 <helmut> dput on >= bookworm?
14:14:16 <guilhem> yes
14:14:19 <bwh> yes
14:14:48 * bunk is using dput on buster
14:14:52 <helmut> guilhem, bwh: either of you. please temporarily change your upload user from "extended-lts" to "extended-lts-staging" and upload something. will be built. will not be moved to the archive
14:15:25 <tobi> I might also have opendkim ready tonight, but not sure yet.
14:15:37 <spwhitton> tobi: oh, nice
14:15:56 <bwh> helmut: I'm only uploading to LTS at the moment though
14:16:13 <guilhem> and /me too :-)
14:16:33 <helmut> bwh: sorry. the whole thing is ELTS only. though we want the dcut plugin for LTS later
14:16:59 <helmut> so no dput users for ELTS except for bunk and emilio both of which are pre-bookworm
14:17:15 <el_cubano> OK. So, is that everything on this topic?
14:17:28 <helmut> so the only concern is bunk's please wait 1 day?
14:17:44 <helmut> the dcut thing is later
14:18:45 <helmut> looks like no objections to me.
14:19:14 <santiago> it seems so
14:19:21 <pochu> o/
14:19:23 <helmut> bunk: I'd appreciate if you could also upload the elts thing (today) to extended-lts-staging
14:19:27 <el_cubano> #action helmut to look into some residual concerns, then implement the change after a suitable delay, and send an email announcing that the change has been made and also include specific instructions for the necessary config changes
14:19:37 <el_cubano> #action @helmut to look into some residual concerns, then implement the change after a suitable delay, and send an email announcing that the change has been made and also include specific instructions for the necessary config changes
14:19:45 <el_cubano> (Sorry, I forgot the '@' in the first one)
14:20:02 <el_cubano> #topic EOL process for LTS/ELTS
14:20:16 <santiago> actually, I am not sure meetboot understands the @
14:20:34 <el_cubano> I thought it was important for some reason. :shrug:
14:20:40 <el_cubano> Please note that @santiago and I have collaborated to make a more structured EOL process.
14:20:58 <spwhitton> is there a link to it from the docs?
14:21:28 <el_cubano> If you find yourself in the position of making a recommendation that we EOL a package (whether for LTS or ELTS), then please file an issue in the appropriate repository using the "Proposed EOL of package" issue template
14:21:32 <el_cubano> spwhitton: For the EOL process?
14:22:18 <spwhitton> el_cubano: I was thinking that perhaps the information in the template ought to be accessible from the docs, somehow
14:24:07 <el_cubano> spwhitton: https://freexian.gitlab.io/services/deblts-team/documentation/elts/information-for-extended-lts-contributors.html#what-is-the-proper-way-to-handle-a-package-which-cannot-be-updated
14:24:30 <_rouca> hi, all can get 10 minutes with you
14:24:36 <el_cubano> I am fairly certain that I made a corresponding update in the LTS docs. However, I can't locate it at the moment
14:24:49 <spwhitton> great thanks
14:24:55 <el_cubano> you're welcome
14:25:23 <el_cubano> From the contributor perspective, the process is the same, with the only difference being which project is the target for filing the issue based on whether it is LTS or ELTS
14:25:43 <el_cubano> That means that if a package is to be declared EOL for both LTS and ELTS, then two issues are required.
14:26:22 <el_cubano> The purpose of this is to provide a guide for the person making the recommendation, such that we (/me and @santiago) don't need to ask a million follow-up questions with all the extra round-trip interactions.
14:26:37 <el_cubano> This we hope to make most EOL recommendations a two-step process.
14:26:44 <el_cubano> s/This/This way/
14:27:01 <tobi> +1!
14:27:06 <_rouca> +1 for me also
14:27:13 <spwhitton> It's really nice documentation too.
14:27:19 <el_cubano> spwhitton: Thanks!
14:27:21 <spwhitton> Helps you decide whether a package might be EOL'd.
14:27:24 <santiago> _rouca, hi!
14:27:33 <lamby> +1
14:28:00 <_rouca> does this step include the decsion to backport ?
14:28:06 <el_cubano> There is also a coordinator checklist that goes with it. It is meant for /me and @santiago primarily, but anyone can look at it to see what sorts of things we are looking at from our side.
14:28:10 <el_cubano> https://freexian.gitlab.io/services/deblts-team/documentation/lts/LTS-coordinator-package-eol-procedure.html
14:28:28 <el_cubano> _rouca: That is one of the questions/considerations that should be answered/addressed in the initial issue
14:28:44 <el_cubano> We rely on the contributor's assessment as a starting point for that
14:29:36 <el_cubano> OK. Any further questions/discussions on this item?
14:29:41 <_rouca> ok for LTS for backport like unstable process now could we ask first to upload to a backport distribution and asses risk from existiting backport ?
14:30:06 <el_cubano> _rouca: That is absolutely something that can be done (and perhaps should be the norm when recommending a backport)
14:30:34 <_rouca> I think it could be the norm in order to share infrastructure
14:30:48 <spwhitton> You mean, to the existing buster-backports{,-sloppy} suites?
14:31:15 <_rouca> spwhitton: yes or even stable-backport (better than nothing)
14:31:37 <bwh> spwhitton: Those suites are closed (-backports does not support LTS)
14:31:38 <spwhitton> okay.  that might be quite slow -- backports NEW is slow, and you are meant to check with the unstable maintainer before uploading, too.
14:31:43 <santiago> _rouca, but remember that a full version backport should come from release+1
14:32:06 <el_cubano> OK. For the time being we have our draft issue template, so if you would like to propose a more concrete procedure for the backport part, feel free to propose an MR to the template. If you need to discuss the idea first to make it more concrete, feel free to email the team address or the coordinator address and we can discuss the specifics there.
14:32:12 <santiago> to ensure an upgrade path
14:33:15 <el_cubano> santiago: That's why spwhitton indicated {,-sloppy} for the cases where a direct upgrade path might be an issue
14:33:32 <santiago> el_cubano, indeed
14:33:51 <santiago> anyway, we can discuss and document this later
14:33:59 <el_cubano> OK. As always, updates, suggestions, revisions to the issue template and associated docs are very welcome. MR, email, whatever to get the process started with us.
14:34:13 <el_cubano> Any other comments/questions on this?
14:34:22 <santiago> not here
14:34:40 <el_cubano> #topic LTS/ELTS contributors helping maintainers setup Salsa CI for unstable
14:35:04 <el_cubano> For the last 6 days, santiago has been going around like a religious zealot asking everyone if they have Salsa CI running for their packages.
14:35:20 <el_cubano> Now, he wants all of us to become his acolytes and help implement his plan for world domination
14:35:32 <lamby> hah :)
14:35:35 <el_cubano> santiago: You're up (hope you like the intro ;-)
14:35:42 <tobi> for debian namespace I just enable it ;-)
14:36:03 <santiago> being el_cubano at the front of those acolytes!
14:36:37 <santiago> this is something we have discussed during the freexian sprint/minidebconf UK, and that we actually mentioned during the LTS presentation
14:36:41 * h01ger waves
14:37:03 <santiago> since we (LTS team) are relying on CI (salsa CI and autopkgtest) as much as possible when preparing an update, it would make sense that we could also help maintainers to setup those CI tools
14:37:37 <santiago> this means, IMHO, it makes sense to send patches and MRs to include debian/salsa-ci.yml and autopkgtest for unstable
14:38:13 <tobi> for LTS / ELTS there was some central place to manage CI configuration, however that seems quite not working for me most of the times. are there updates I am not aware of?
14:38:17 <el_cubano> Note that this is work which can be done under the "25% of work which isn't direct LTS/ELTS package uploads"
14:38:21 * h01ger is reminded he wants to watch that talk from cambridge. also: nice talk title!
14:38:26 <_rouca> should go to my students thanks for you
14:38:30 <santiago> the paid LTS contributor documentation already mentions it is possible to spend time on DEP-8, and I think this can be extended to salsa ci
14:38:38 * el_cubano agrees
14:38:59 <santiago> tobi, please, feel free to notify me about those issues
14:39:17 <santiago> the lts-team/pipeline should currently work (with a few caveats, I think)
14:39:21 <el_cubano> In my mind, what makes the most sense is to either tackle the Salsa CI and autopkgtest in unstable for packages as you work on them for LTS/ELTS and/or to tackle specific packages that you are interested in or knowledgeable with
14:40:23 <santiago> and that would make sense to set it up when forking a project (when needed)
14:40:26 <tobi> santiago: will do
14:41:22 <santiago> it is also helps to better collaborate with maintainers to be consistent in the ci configuration path in gitlab (I would have to document this)
14:41:29 <Beuc> Is https://lts-team.pages.debian.net/git-workflow-lts.html up-to-date ?  Currently it recommends to apply per-repo configuration.
14:41:57 <Beuc> with a debian/.gitlab-ci.yml file
14:42:10 <spwhitton> Beuc: is there an alternative to doin gthat?
14:42:13 <santiago> Beuc, I will take a look after the meeting
14:42:51 <Beuc> IIRC a global configuration is possible (without the .gitlab-ci.yml file) but it failed to recognized the right branches last time I tried with pochu iirc.
14:43:18 <pochu> yes, that's an upstream gitlab bug
14:43:20 <santiago> we would always need to customize the ci configuration
14:43:24 <spwhitton> isn't it more useful to have it in the .yml, so the file is carried around with the repo, no matter the git host?
14:43:24 <el_cubano> #action santiago to review the documentation for implementing Salsa CI in package repositories
14:43:28 <pochu> santiago: why?
14:43:41 <santiago> pochu, e.g. to setup the RELEASE
14:43:52 <pochu> santiago: there was some magic to do that based on the branch
14:44:40 <santiago> pochu, not sure that is working, and it is more important to be consistent with the maintainers' repo
14:44:58 <el_cubano> BTW, please note that as you work on helping maintainers implement Salsa CI for their packages in unstable, that is an "interesting" thing which we could specifically want to highlight in our LTS monthly report, so make sure to mention this activity in your own monthly reports.
14:45:01 <Beuc> Anyway, more users to fix all the salsa corner cases and non-autopkgtest/internal failures would be good :)
14:45:04 <santiago> I would like to mention the idea was well received by people during the presentation
14:45:07 <pochu> the RELEASE part is working, but gitlab fails to load the dependencies
14:45:17 <pochu> so I'm not advocating its use, as it's broken atm anyway :)
14:45:52 <santiago> any question or comment about this?
14:46:07 <pochu> perhaps removing or ammending the recomendation to use --creategitrepo in the doc would be nice
14:46:21 <el_cubano> OK. Thanks santiago and pochu for your work on this.
14:46:23 <pochu> we should suggest to fork the maintainer repo, if that's needed
14:46:36 <santiago> pochu, that is true. that feature is "broken"
14:46:47 <el_cubano> pochu: I believe that is on my TODO list. There is a note like "we are considering prefering to fork instead", but I don't think I ever went back to amend it
14:47:07 <tobi> I was also working on the forking guide a bit, but unfortunatly could not find much time for it...
14:47:09 <el_cubano> #action el_cubano update docs to eliminate --creategitrepo recommendation and prefer forking instead
14:47:26 <el_cubano> OK. Anything else on this?
14:47:28 <tobi> (I don't have the link to the pad with me right now, but can provide it later)
14:47:40 <el_cubano> tobi: Thanks
14:47:46 <el_cubano> OK. So, next topic
14:47:55 <el_cubano> #topic FD needs to monitor mailing list and IRC
14:48:02 <santiago> thank you all to help world domination
14:48:14 <el_cubano> A few days ago utkarsh2102 sent an email about the need for FD to monitor IRC.
14:49:07 <el_cubano> I understand that not everyone is present on IRC all the time. However, many (most?) Debian teams (notably, secteam, ftpmaster, release team, and others) are reachable via IRC. We have committed to operating in a fashion similar to other Debian teams in this way (and in the matter of mailing lists, for instance)
14:49:44 <el_cubano> So, that means that when someone is assigned FD duty, it is necessary to monitor IRC and ensure queries received a response, and if not then respond to them personally
14:50:08 <el_cubano> The minimum level here that seems to make sense is to review the scrollback at least once per day while on FD
14:50:31 <el_cubano> If you want to be present during your timezone's working hours, or whatever hours are convenient for you, then you can absolutely do that as well.
14:50:34 <bwh> FD is a single person and is not being paid for "on call" time, so I don't think we can demand responsiveness on IRC
14:51:04 <el_cubano> bwh: Right, but what we are asking for here is roughly the same level of responsiveness as for the mailing list (i.e., once per day)
14:51:25 <bwh> OK, but then IRC is the wrong channel for that
14:52:07 <tobi> IRC is a fine channel for small queries. (IMHO it does also not need immediate answeing)
14:52:10 <el_cubano> Understood. But we can't just abandon IRC altogether without it being an issue for people who expect to be able to reach an official LTS representative on IRC.
14:52:47 <el_cubano> So, and this is for everyone, if for some reason you feel like the IRC commitment is more than you would like to make, then simply don't register yourself for FD
14:52:55 <pochu> a query on irc might happen and the user may leave before FD (or anybody else) is around to answer it anyway
14:53:33 <el_cubano> Right. And that is perfectly fine. We don't need to meet some sort of 2 hour or 4 hour SLA. Rather, we just need to generally operate like other teams in Debian
14:54:14 <el_cubano> lamby: You raised some concerns in the email discussion about asking people to take discussions to email when it had become apparent that IRC wasn't the best means of communication.
14:54:21 <el_cubano> That is a valid concern
14:54:27 <helmut> irc stuff regularly gets answered with a delay of sometimes 12h.
14:54:47 <lamby> Yes, shall I try and re-summarise here or would my mail suffice? You seem to summarise it pretty well there.
14:54:51 <el_cubano> We should still try to respond at some point, especially if the person remained in the channel (indicating tha they were fine to wait for a response)
14:55:08 <santiago> From wiki.debian.org/LTS: "The most important way of communication is the mailing list debian-lts."
14:55:10 <el_cubano> lamby: I think the email is fine (since we are close to time for the the meeting)
14:55:14 <bwh> el_cubano: But as I said, FD is one person (at a time), not a team. I don't think we can expect to provide the same responsiveness as other teams unless this changes
14:55:49 <el_cubano> bwh: FD is the designated team representative. Just as with the mailing list, anyone can answer, but if nobody answers then the responsibility falls to FD
14:56:03 <Beuc> In practice there are contributors here happy to answer. FD would just check if nothing feel through the crack IMHO.
14:56:06 <bwh> el_cubano: Oh right, that makes more sense
14:56:24 <el_cubano> To everyone, please read the email discussion on this and reply there if you have a question or concern
14:56:30 <el_cubano> bwh: Cool.
14:56:33 <el_cubano> Let's move one
14:56:40 <el_cubano> #topic Mini-DebConf Cambridge 2023 presentation
14:56:47 <spwhitton> Would you recommend those of us not at mini-debconf watch the talk recording, or is it not likely to be too much use for existing contributors?
14:56:48 <tobi> I'd also say that team <-> FD communication on IRC is a nice feature...
14:56:51 * el_cubano and santiago presented at the mini-DebConf
14:57:01 <el_cubano> https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Sanchez
14:57:34 <el_cubano> spwhitton: I mean, you'd have to endure /me and santiago talking for 35 minutes and then dodging questions for 25 minutes after that ;-)
14:57:48 <el_cubano> But, if you don't mind the torture, then yes go ahead
14:58:29 <el_cubano> In all seriousness, I would say to review the slides first (there are also notes in the notes view of the slides) and if you feel like watching the presentation might be beneficial after that, then go ahead
14:58:54 <spwhitton> nice
14:58:55 <el_cubano> However, there is nothing earth shattering there, I believe
14:59:40 <el_cubano> The main concept (as exemplified by the desire to help maintainers set up Salsa CI and autopkgtest in unstable) is that we want to start doing more things at the point of unstable and having them filter down, rather than doing them only (or first) in LTS
15:00:03 <spwhitton> Do these things also fall into the 25% of LTS time rule?
15:00:12 <spwhitton> In general.
15:00:20 <el_cubano> spwhitton: Yes, in my view they do, and both santiago and buxy agree
15:00:59 <el_cubano> OK. So, we are a little past time and I'd like to not hold people longer than needed (plus I have another meeting after this)
15:01:03 <el_cubano> #topic AOB
15:01:09 <tobi> If it is unstable first, I guess, the 25% can be get the bottleneck fast.
15:01:09 <lamby> None here. :)
15:01:37 <el_cubano> tobi: And if it becomes a bottleneck, please get in touch with us (the coordinators) and we can approve >25%
15:01:44 <el_cubano> Does anybody else have any other items of business?
15:02:46 <helmut> that scp->sftp upload will happen tomorrow. you'll get another mail
15:02:56 <el_cubano> OK. Thanks for confirming.
15:03:01 <el_cubano> Anyone else?
15:03:16 <santiago> tobi, we could discuss that. we could have some feedback in a future meeting
15:03:24 <santiago> (talking about the 25%)
15:03:29 <tobi> ok, maybe i need to watch the talk first, to get the scope right.
15:03:50 <santiago> nothing else for me
15:03:57 <el_cubano> I also have nothing else.
15:04:07 <el_cubano> OK. Thanks everyone for participating today.
15:04:09 <lamby> Thanks, all.
15:04:10 <spwhitton> thanks all.
15:04:13 <guilhem> o/
15:04:15 <Beuc> thx!
15:04:21 <tobi> have a nice day everyone!
15:04:22 <el_cubano> In a few hours I will send out the customary post-meeing email.
15:04:33 <santiago> thank you all!
15:04:37 <el_cubano> Reminder: Next month, 2023-12-21 @14:00 UTC on Jitsi
15:04:48 <el_cubano> OK. Have a great day, everyone!
15:04:52 <el_cubano> #endmeeting