14:01:29 <gladk> #startmeeting
14:01:29 <MeetBot> Meeting started Thu Jul 28 14:01:29 2022 UTC.  The chair is gladk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:29 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:59 <h01ger> hihi
14:02:02 <gladk> Hello everybody, please raise a hand, just to know, who is here
14:02:15 <gladk> Agenda is here https://pad.riseup.net/p/lts-meeting-agenda
14:02:17 <buxy> o/
14:02:18 <gusnan> o/
14:02:18 <Beuc> o/
14:02:19 <apo> hiho :)
14:02:32 <gladk> #topic Buster as LTS. August 2022. What should be prepared?
14:02:35 <el_cubano> hi
14:03:03 <gladk> It looks like we will get Buster LTS soon, does anybody have something to say about it?
14:03:25 <buxy> gladk: only that we can drop armel
14:03:27 <gladk> It looks like technically we are ready for that. Of course, we need to check everything and maybe fix it
14:03:58 <gladk> buxy:  OK, I will write it in the notes and create a ticket
14:04:22 <gladk> Anything else?
14:04:47 <gladk> #topic Jessie and Stretch as ELTS. Problems? Ideas? Suggestions?
14:04:49 <buxy> pochu asked me what architecture we want to keep and I already notified him, chances are that the ticket he filed for ftp.debian.org contains the right information already
14:04:55 <bwh> Has anyone talked to FTP masters about enabling signing of a linux-5.10 package?
14:04:59 <bwh> If not I can do that
14:05:29 <bwh> (that is for buster LTS, not the new topic)
14:05:37 <gladk> bwh: OK
14:05:50 <Beuc> Btw we have a checklist at https://wiki.debian.org/LTS/Development#Switching_to_the_next_LTS_release
14:06:37 <buxy> bwh: I don't think so, AFAIK only pochu worked on preparation for buster and I don't remember anything where we talked about this
14:06:59 <bwh> buxy: OK, then I will make contact
14:08:23 <gladk> OK, that another (active) topic: Jessie and Stretch as ELTS
14:09:02 <gladk> it looks like main technical questions have been solved: scripts are ready, build are set up, uploads are working. Anything else?
14:09:46 <buxy> gladk: my main question is whether we are up to the task, i.e do we have enough resources or are things piling up?
14:10:28 <gladk> well, we have a lot of open packages in ela-needed. But it is being cleared up step-by-step
14:10:47 <buxy> It's a rather sharp increase in (theoretical) workload, somewhat mitigated because we handle the same packages in two releases with similar fixes
14:10:52 <gladk> The actual statistics can then be gathered at the end of the month
14:11:24 <buxy> gladk: yeah, but I'd like you to keep an eye on this, and ensure we don't have packages staying unfixed for too long
14:11:40 <gladk> buxy: yes we will monitor it
14:13:13 <apo> there is still the question what to do with mysql-connector-java? Do we have got more information from that customer?
14:13:46 <gladk> apo: no, customer contacted. But it looks like we will get a reply in 2 weeks
14:13:55 <gladk> summer time
14:14:01 <apo> okay
14:14:44 <gladk> but I think there is clear, that mysql-5.5 is no supported any more, so the dependent package cannot be supported as well, from my humble point of view
14:15:30 <gladk> are there any other problems, ideas, suggestions regarding the discussed topics?
14:15:56 <buxy> Maybe one question.
14:16:30 <buxy> Emilio prepared the new kernel, but AFAIK nobody else teste the new kernels that we released to customers.
14:17:04 <buxy> Did someone test the backported kernel that Emilio prepared?
14:17:39 <buxy> I think it would be nice if some of us could test them in their usual jessie/stretch test environment.
14:18:36 <apo> Sounds sensible. I suggest to keep it simple and ask for testing on the elts mailing list
14:18:52 <gladk> Has anybody an opportunity to test it on real hardware?
14:18:58 <gladk> Maybe we can ask some customers?
14:19:58 <buxy> gladk: we already informed customers that they can upgrade, I have added a big fat warning "test your upgrades" first because I was worried that our testing was not sufficient
14:20:33 <buxy> we will get feedback if something does not work, but it might come later (summer time as you say)
14:21:15 <gladk> Should we wait, till, say september and then update a kernel?
14:22:21 <gladk> even if do not get any feedback?
14:22:47 <buxy> I don't follow you, but no, there's no reason to wait on anything. If anything, we were quite late in preparing those backports. I'm just asking that we put some more hours in internal testing to try to uncover potential issues before our customers do.
14:23:40 <buxy> But the kernels have been released already and Emilio is already preparing a first update IIRC.
14:25:02 <gladk> OK, can we move further or do we have something to discuss here?
14:25:42 <buxy> Go ahead
14:26:40 <gladk> #topic How to minimize regressions?
14:27:29 <gladk> Last months we had some problems with updates of important packages: web servers, dns servers etc. The question is, how can we reduce and even prevent it?
14:27:44 <gladk> Just asking for testing does not help too much
14:28:22 <gladk> are there any suggestions?
14:29:14 <buxy> Yet, there's not much more than testing that can be done to detect regressions and avoid to release updates with regressions. The security team is currently working on automating autopkgtest for security updates.
14:29:50 <gladk> At least salsa CI should be a "must have" for such cases
14:30:53 <apo> there are only two solutions, you can either write a test or you have to manually test the feature. This implies you are testing the correct feature. We could make it mandatory that we make it mandatory to ask for another reviewer before we upload an important package. That's the only thing that makes sense
14:30:55 <el_cubano> I've thought about this specifically in the context of the apache2 update.  I don't see how the regression could have been detected by any reasonable level of testing.  Even if there were automated tests (like autopkgtest) I don't think those would have caught the issue either.
14:31:20 <gladk> Maybe we can monitor a very limited set of packages and require a "double" review for them?
14:31:59 <apo> yes, another pair of eyes is sensible.
14:32:07 <el_cubano> That seems like it might catch some issues
14:33:17 <gladk> Any other thoughts?
14:34:05 <bwh> Be more willing to decide that an issue is minor and not worth the risk?
14:35:10 <gladk> bwh: it is an important note
14:35:45 <gladk> #topic Debian LTS BoF & Meeting with some members of the (E)LTS teams
14:36:00 <gladk> just an info. We have personally meet, it was very pleasure.
14:37:35 <gladk> Second question, can put some slides somewhere in one place for the internal use?
14:38:01 <gladk> I have found only one in some of repos
14:38:18 <buxy> Glad that you had some good time in Kosovo.
14:39:41 <gladk> let's move furhter
14:39:46 <buxy> gladk: I don't think that you need anyone's permission to put LTS slides in the internal LTS repository
14:40:23 <gladk> OK
14:40:30 <gladk> #topic Git workflow. Opinions.
14:41:27 <gladk> I have seen, that some of members are using it, some not. Are there any suggestions?
14:41:38 <gladk> I am preparing a script, which makes the creation of repos easier. But it takes some time
14:42:22 <el_cubano> I personally like the workflow.  It might also be worth adding repo information to the [ed]la-needed.txt, since we also have programming language info there
14:43:37 <el_cubano> That way, when someone claims a package they know right away if there is a repo for it (whether the repo created under our Salsa group, or a repo which the package maintainers use and which we can also use)
14:43:51 <buxy> programming language can help select entries, but is the (almost predictable) URL of the git repo really useful? or is it meant as reminder that one should work in git now?
14:44:19 <buxy> ah ok
14:45:32 <apo> let's just assume that we always have a lts-team Git repo for a package. I often just import an existing repo and add our branches + CI file. The rest is just gbp import-dsc
14:45:51 <el_cubano> A reminder and also a helpful pointer for the packages which we don't have under our umbrella.  For instance, when I did a mediawiki update ayear or two ago, the package maintainer asked for the work to be pushed into their existing salsa repo on the jessie or stretch (whichever it was at the time) branch
14:45:57 <gladk> yes, if you did it one-two times, it is much faster
14:46:39 <gladk> el_cubano: thanks
14:46:59 <el_cubano> np
14:47:11 <bwh> It sounds like we should have a record of which packages can be updated in the regular maintainers's repository
14:47:20 <bwh> and that should be persistent, not part of [ed]la-needed.txt
14:47:39 <buxy> gladk: for the contributors who are not working with git, I think you need to question/nudge them individually
14:48:03 <gladk> buxy: OK
14:48:17 <gladk> #topic Funding projects
14:48:26 <buxy> bwh: at the same time, such updates might require to create MR and such MR are best created out of our own fork in lts-team, so it might be ok to have a copy in lts-team in all cases
14:49:03 <el_cubano> It might make sense to have a YAML file where we record "special" packages.  Where "special" could mean "needs second review of patches" (like we discussed a few moments ago), "use the maintainer's git repo for LTS/ELTS work", "special testing considerations", etc.
14:49:05 <buxy> but yeah recording this information somewhere is useful in any case
14:49:37 <el_cubano> Then a triage script could be run by FD to make sure that the notes are present for packages in [ed]la-needed.txt.
14:49:52 <gladk> Then it is better not to add the packages "manually", but through the script, which can do all the background work
14:50:30 <gladk> into the dla-needed, ela-needed I mean
14:51:09 <gladk> OK, "funding projects" it is just a reminder for those, who want to complete some Debian-related projects
14:52:23 <gladk> ok, we go to the last topic
14:52:42 <gladk> #topic Any other business
14:52:58 <el_cubano> I have one AOB item
14:53:32 <buxy> I really wait the outcome of the DD survey to relaunch a bigger discussion on project funding but utkarsh2102 is not really reactive to provide more insights out of the data collected. :-( Would someone else be interested to help process the survey data into some more advanced report than the plain copy of limesurvey data?
14:53:43 <el_cubano> I have documented the Available:Extra account on the team website (both LTS and ELTS packages) and in the timekeeping.ledger comments (in both the LTS and ELTS repos)
14:55:19 <gladk> el_cubano: thanks for that!
14:55:40 <el_cubano> np
14:55:42 <gladk> buxy: do we have a raw data?
14:56:03 <buxy> gladk: yes we have it
14:56:31 <gladk> buxy: I can only propose to create a ticket for that.
14:56:41 <buxy> a big CSV file that is
14:57:22 <el_cubano> buxy: What sort of analysis are you thinking is needed?
14:57:51 <gladk> One more note for all. Please have a look at the open tickets in our trackers. If you can fix or work on some of that.
14:57:56 <buxy> el_cubano: the kind of thing that I asked for in my reply to Utkarsh (in deblts-team@freexian.com)
14:58:18 <el_cubano> OK.  I'll go back in look at the email and see if I can help with that.
14:58:39 <buxy> message id Yr8rceMyJJoQkEEv@t14-buxy.home.ouaza.com for reference
14:59:06 <gladk> I would create a ticket, so we can coordinate a work on that
14:59:42 <buxy> There's likely already a ticket related to the survey.
14:59:53 <gladk> buxy: I will check
15:00:17 <gladk> We are good in time. If we have nothing to discuss, let's close it
15:00:31 <gladk> #endmeeting