13:58:15 <el_cubano> #startmeeting
13:58:15 <MeetBot> Meeting started Thu Mar 23 13:58:15 2023 UTC.  The chair is el_cubano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:58:22 <utkarsh2102> hellu
13:58:28 <helmutg> hello
13:58:29 <sgmoore[m]> hi
13:58:29 <el_cubano> Hello everyone, please announce yourself here
13:58:40 <ta> hi everybody
13:58:40 <tobi> \o
13:58:41 <el_cubano> #topic intro
13:58:42 <rouca> hi
13:58:46 <pochu__> o/
13:58:49 <buxy> Hello
13:58:55 <Beuc> o/
13:59:17 <tumbleweed> \o
13:59:34 <lamby> Hope all are doing well.
14:00:04 <h01ger> o/
14:00:38 <el_cubano> Alright, that looks like mostly everyone.  Before we start with the formal agenda, did anyone have anything they would like to say?
14:01:59 <el_cubano> OK.  It looks like there are no specific opening remarks.
14:02:08 <el_cubano> We will be working from this agenda: https://pad.riseup.net/p/lts-meeting-agenda
14:02:18 <el_cubano> #topic gbp workflow
14:02:47 <el_cubano> petn-randall: This looks like your topic.
14:03:54 <el_cubano> Beuc: You had a comment on the agenda about this item.  Did you want to share anything?
14:04:00 <pochu__> should we have per-release upstream branches?
14:04:19 <utkarsh2102> no, please 🥹
14:04:20 <buxy> FWIW petn-randall didn't announce his presence in the introduction part
14:04:33 <buxy> utkarsh2102: why? it certainly makes sense
14:04:35 <el_cubano> buxy: Ah, yes, I see that.
14:04:54 <Beuc> I worked a but with petn-randall during the apache2 upload; it seemed to me that there was no workflow conflict as-is, as I noted,
14:04:57 <utkarsh2102> do we really need it?
14:05:37 <el_cubano> In the case of apache2, the buster work happens in the maintainer's Salsa repo (directly in their repo, rather than a fork) and the stretch/jessie work in our lts-team repo (which is not a fork of the maintainer repo)
14:05:38 <buxy> utkarsh2102: it really depends whether upstream is still doing releases against old branches?
14:05:49 <utkarsh2102> which is rare
14:05:59 * h01ger dislikes gbp personally (too opaque) but likes the idea of using git for everything
14:06:20 <buxy> but I have often used upstream/4.2.x as the upstream branch for a specific debian release
14:06:23 <el_cubano> So, we could do per-release upstream branches for apache2 in stretch/jessie but if we want to work in the maintainer repo for buster, then we need to go by what the maintainers are doing
14:06:55 <helmutg> i only needed multiple upstream branches Ehen adding elts after LTS thus far
14:07:37 <Beuc> el_cubano, I think we need to avoid Aton's from-scratch approach AND forking apache-team's initial repo, in the same git repo
14:07:40 <el_cubano> And even then (as I noted in my comment on the agenda) if you don't use gbp push, then it isn't an issue to put multiple upstream releases on the same upstream branch
14:08:14 <el_cubano> Beuc: I was under the impression that the lts-team/apache2 repo was entirely separate and distinct (with no link to the maintainer repo)
14:08:23 <el_cubano> At least, that's how I treated it when I last worked on apache2
14:08:35 <el_cubano> Is it different now?
14:08:53 <Beuc> Issues happened when petn-randall attempted to import apache-team's history,
14:09:17 <buxy> Beuc is arguing to avoid that except when the debian maintainer is using something not compatible with gbp
14:09:17 <Beuc> but if petn-randall can't confirm what he wrote in the agenda at the start of the month, we should let him bring this to the mailing list as he mentioned last week I think
14:09:46 <el_cubano> Ah, I see.  I didn't try to do that and instead preferred to work in the two separate repos.  I didn't see a particular benefit to trying to have both the maintainer repo history and our unlinked stretch/jessie history in the same repo
14:10:07 <el_cubano> OK. I think I will ask him to bring the issue up on the mailing list and we can dicuss it there asynchronously
14:10:15 <el_cubano> Any final comment on this topic?
14:11:57 <el_cubano> OK
14:12:00 <el_cubano> moving on
14:12:09 <el_cubano> #topic buster package lists
14:12:11 <tobi> I didn't find an opportunity to write a guide how to spot and then fork a gbp compatible workflo, but I didn't forget about it.
14:12:28 <el_cubano> tobi: Is there a ticket for that task?
14:12:40 <buxy> There might be things to improve in gbp to avoid the kind of problems. Like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862788 and that error could then advise to introduce different upstream branches.
14:12:47 <tobi> no, I don't think so, it  was agreed in the last Jitsi meeting.
14:13:20 <el_cubano> #topic gbp workflow
14:13:26 <el_cubano> tobi: OK.  Thanks
14:14:02 <el_cubano> #action el_cubano tobi create ticket to capture the need to document gbp-compatible workflow for LTS work
14:14:19 <el_cubano> Alright, anything else on this?
14:15:37 <el_cubano> #topic buster package lists
14:15:51 <el_cubano> Beuc: The floor is yours
14:16:54 <Beuc> Thanks. I recap'd the status in the pad. Unless buxy has more updates about the buster packages list (which was updated recently) I think we're good.
14:17:29 <Beuc> buxy, maybe let us know if there are more updates underway, or if the current 'packages-to-support' list is now reasonably final?
14:17:35 <buxy> I can just say that we are far from having full coverage from all sponsors.but we did a decent job
14:18:16 <buxy> We did a decent job by requesting updated lists from customers and repurposing stretch package lists for ELTS customers that are also LTS sponsors.
14:19:08 <helmutg> i suggested customizing popcon for customers as an alternative to sending lists
14:19:14 <buxy> We have 32 package lists, this is rather low compared to the 78 LTS sponsors but many of them don't really care about providing a package list.
14:20:53 <buxy> That was still sufficient to provide a new list that is not smaller than the former one.
14:22:24 <el_cubano> And the idea is that we want to ensure that packages in use by sponsors are being prioritized above other packages?  (Knowing that we aren't ignoring unlisted packages, since we claim/offer to support all packages)
14:22:31 <buxy> There might further minor updates but we are not aware of any other update that shall arrive in the short term.
14:22:50 <buxy> el_cubano: correct
14:23:02 <el_cubano> Great, thanks!
14:23:08 <el_cubano> Anything else on this item?
14:23:16 <buxy> Not from me.
14:23:30 <Beuc> Nope.
14:23:34 <el_cubano> Excellent.
14:23:38 <el_cubano> #topic any other business
14:24:05 <buxy> I'd like to mention that we have on-boarded many new contributors recently.
14:24:21 <rouca> thanks buxy
14:24:21 <sgmoore[m]> o/
14:24:38 <el_cubano> buxy: I was going to mention that at the end.  But thanks for bringing it up now.
14:24:48 <el_cubano> Welcome to the newest contributors
14:24:55 <lamby> Yes, welcome!
14:25:05 <utkarsh2102> welcome, indeed!
14:25:05 <h01ger> \o/
14:25:06 <buxy> Scarlett, Bastien and Federico can certainly benefit from reviews and mentorship to get started in good conditions.
14:25:09 <tobi> \o/
14:25:34 <tumbleweed> \o welcome
14:25:41 <buxy> Tobi too, but he's a few months old already :-)
14:26:12 <el_cubano> OK.  Last call for comments or any other business
14:26:24 <el_cubano> Actually, I have something.
14:26:32 <buxy> On the other side, as newcomer don't hesitate to file bugs wherever appropriate to report things that can be improved or need to be updated.
14:26:40 <sgmoore[m]> Happy to be here! a big thank you to Utkarsh Gupta whom has agreed to mentor me
14:26:42 <utkarsh2102> happy to! :D
14:26:51 <el_cubano> As an FYI for everyone, Anton has requested to transition away from the coordinator role and I will be assuming those responsibilities in the coming weeks
14:26:57 <sgmoore[m]> Absolutely!
14:27:09 <rouca> el_cubano: noted
14:27:11 <buxy> In the last LTS meeting, we spoke of the need to revamp the LTS/ELTS documentation and your feedback is certainly important in identifying the shortcomings.
14:27:37 <rouca> buxy: I have adapted my pbuilder script to get lts/elts build
14:27:47 <rouca> may be worth sharing
14:28:18 <tobi> I've got some general pbuilder setup I've stolen years ago somewhere… I can certainly share that too with you all
14:28:34 <buxy> Yup. I would like a clear "getting started" documentation that explains everything you need to setup (or can setup)
14:29:03 <Beuc> not to mention the pbuilder command lines from the Development doc (that I use everytime) :)
14:29:54 <el_cubano> Alright, anyone else?
14:29:56 <sgmoore[m]> I will also document my journey to success.
14:30:52 <el_cubano> As an FYI for everyone, the next meeting will be on Thursday, April 27th at 14:00 UTC via Jitsi
14:31:03 <rouca> a snapshot.debian.org like service will be nice in case of regression ... I may document how to test regression compared to last debian version
14:31:07 <el_cubano> The schedule of upcoming meetings is here: https://lts-team.pages.debian.net/wiki/Meetings.html
14:31:09 <lamby> el_cubano:   Thanks; confirmed in calendar.
14:31:10 <rouca> (manual way)
14:31:49 <h01ger> whats the jitsi url / room name?
14:32:01 <h01ger> or is that in Meetings.html? :)
14:32:07 <el_cubano> rouca: This has been discussed several times.  It requires substantial infrastructure.  For the time being we are trying to get all of our changes/releases into a common git workflow to help us be able to see difference from one release to the next.
14:32:12 <helmutg> how much can we invest on tests? e.g. activating an upstream suite, autopkgtests for poc samples etc
14:32:13 <buxy> rouca: yup, we already have a ticket about this (snapshot), it's just not getting worked on currently
14:32:17 <el_cubano> h01ger: It's at the link
14:32:30 * h01ger just saw, thanks
14:33:04 <rouca> el_cubano: ok thanks
14:33:22 <buxy> helmutg: what kind of guidance are you looking for? It's certainly something worth doing, in particular on packages where we know that there will be further updates.
14:34:02 <rouca> h01ger: asan is prohibitive to run and a lot of poc need asan nowaday
14:34:42 <el_cubano> helmutg: In my case, I've found that maintainers have disabled the test suite and getting it going as part of the regular package build was too difficult.  In those cases I run the test suite manually and compare the output (e.g., numbers of pass/fail) from runs before I've made any changes to after I've made changes
14:34:45 <helmutg> like how much time (proportionally) we can spend reasonably
14:35:10 <el_cubano> It's not as well integrated as part of the package build, but it helps give me confidence that my changes fix the vulnerability and don't introduce a regression
14:35:13 <buxy> that said it also depends on whether we are coping with the workload or not, we used to have some margin that can easily be invested into extra work, the situation is less clear nowadays since we seem to be having some backlog.
14:35:33 <helmutg> I enabled it for six and am wondering whether that took too much time
14:37:26 <utkarsh2102> I’d focus on getting the backlog clear than anything else. But enabling tests for important packages is definitely a +1, I think.
14:38:32 <pochu__> I think it's worth spending some time enabling tests, whether that's a good idea for a specific package depends on various factors such as the time needed and how important that package is
14:39:41 <helmutg> i still ended up introducing a regression despite tests :(
14:39:51 <pochu__> it's also a bonus if that work is sent higher upstream, i.e. go the master branch if missing there
14:40:12 <buxy> Ack. I don't know how much time you spend on average on testing the update but I expect it to be significant, so that can easily include time for that kind of activity.
14:40:29 <pochu__> helmutg: if the tests covered everything, there would be nothing for us to fix in the first place :)
14:40:44 <helmutg> thank you
14:41:41 <el_cubano> OK, last call for comments
14:43:24 <el_cubano> Alright, thanks everyone for participating.  Have a good day.
14:43:27 <el_cubano> #endmeeting