14:00:35 <buxy> #startmeeting
14:00:35 <MeetBot> Meeting started Thu Jan 26 14:00:35 2023 UTC.  The chair is buxy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:56 <helmut> I suggest that we copy the role-call module from other meetings (e.g. ctte) where each participant writes their own full name to indicate participation
14:01:23 <Beuc> we usually just o/
14:01:23 <buxy> #topic Identify yourself
14:01:30 <tobi> o/
14:01:37 <Beuc> o/
14:01:38 <ta> o/
14:01:42 <helmut> o/
14:01:46 <petn-randall> Please no full names. I can elaborate if needed.
14:01:48 <petn-randall> o/
14:01:53 <apo> o/
14:01:55 <buxy> o/
14:02:19 <tumbleweed> o/
14:02:48 <buxy> #topic Git usage and tag monitoring
14:03:00 <utkarsh2102> \o
14:03:13 <buxy> I don't know where gladk is, I have no news, so I'll try to handle the meeting in his place.
14:03:52 <el_cubano> o/
14:04:16 <gladk> Hi
14:04:27 <bunk> .
14:04:43 <buxy> We decided a while ago to make git usage mandatory (except when you have a good reasons) and we now have some monitoring to ensure that there are git tags corresponding to uploads.
14:05:06 <gladk> We started to monitor it, and it runs relatively good
14:05:24 <gladk> we have some uploads, which are still not in the git
14:05:40 <gladk> and it would be good that everybody uses it
14:06:05 <gladk> also I would hear, if there are some objective problems or dificutlies in its usage
14:06:06 <h01ger> o/
14:06:12 <tobi> it as in git or the monitoring tool?
14:06:24 <apo> I have pushed my Java related updates to the java-team repository on salsa as usual. Can we just clone those repositories instead of recreating them again?
14:06:35 <buxy> #chair gladk
14:06:35 <MeetBot> Current chairs: buxy gladk
14:06:38 <helmut> question: does that mean that all packages should be in lts-team or can they be on the maintainer repository (if the maintainer agrees)?
14:07:03 <helmut> hah. same question as apo. :)
14:07:08 <apo> :)
14:07:11 <gladk> apo: sure, you can. If even the repo is created automatically, feel free to drop it and clone
14:07:39 <buxy> dropping a repository requires owner privileges AFAIK
14:07:40 <tobi> related: if there is a maintainer repo that is useable, fork it or recreate it from scratch? I like the later as it keeps the connectin.
14:07:53 <gladk> If you have an opportunity to commit to the original repo - is also OK, this repo then should be added into the package database, so we know, where to look for the history
14:08:31 <apo> right, that sounds sensible
14:08:37 <helmut> I looked for that package database earlier and failed to locate it. would you remind me where that is?
14:08:41 <tobi> where is the package database?
14:08:52 <gladk> https://gitlab.com/freexian/services/deblts-team/debian-lts/-/blob/master/packages.yml
14:08:55 <apo> I'm in favor of just adjusting the link in the database instead of cloning it
14:09:20 <gladk> apo: sure, feel free to do it! Just let us know, whether the newly created repo should be removed.
14:09:45 <apo> ok, I'll send you a private message when I'm done
14:10:05 <gladk> The only problem with the original repo is that not all mainatiners want to have LTS-ELTS stuff in their repos. It can delay our work
14:10:28 <gladk> any more question about that?
14:10:40 <apo> sure, it should be handled on a case by case situation. As for Java stuff it shouldn't be a problem
14:10:53 * helmut updated the repo for lighttpd
14:11:15 <buxy> FWIW, I think that this database should be hosted publicly in lts-team.
14:11:43 <gladk> Regarding the package database. If you are doing FD-work it is better to use the script, which checks, whether the additinal information can be added to the dla-needed: programming language, vcs, testsuite etc,
14:11:50 <gladk> please use it
14:11:53 <buxy> And the tool(s) to interact with it too.
14:12:01 <tobi> when using the maintainers repo, how to ensure maintainers wont delete the branches? Especially in the debian group?
14:12:08 <gladk> If you want, we can organize a short video-tutorial session, where I can show, how to use it
14:12:30 <gladk> it is pretty simple, but helps to keep the stuff in the order
14:12:48 <gladk> buxy: note
14:12:50 <gladk> noted
14:13:11 <helmut> maintainer repo vs lts-team repo: I think maintainer repo should be opt-in upon maintainer agreement. default lts-team is fine imo.
14:13:25 <gladk> tobi: that is why my preference to use the separate repo to escape this situation and potential confilcts
14:13:51 <tobi> I agree.
14:13:55 <buxy> (In general tags are not removed, even if branches are)
14:14:01 <gladk> also the CI is being setted up there automatically, and it increases the number of checks and general package quality
14:14:02 <tobi> and a fork can always be merged back too
14:15:05 <gladk> So, generally, it does not really matter, whether the git repo is hosted, important is to document the done work.
14:15:25 <gladk> any more question about this part?
14:15:59 <gladk> please feel always free to ask or propose improvements if you see a potential for that
14:16:21 <buxy> Regarding the video-tutorial, it's nice to offer it, but IMO some good documentation ought to be sufficient. Is there doc already?
14:16:31 <tobi> if there is a maintainer repo that is useable, fork it or recreate it from scratch? I like the later as it keeps the connectin.
14:16:34 <tobi> if there is a maintainer repo that is useable, fork it or recreate it from scratch? I like the later as it keeps the connectin.
14:16:37 <tobi> if there is a maintainer repo that is useable, fork it or recreate it from scratch? I like the later as it keeps the connectin.
14:16:46 <tobi> srry, bounce button
14:17:33 <buxy> Forking it is best IMO (unless they use some really unusual conventions).
14:18:17 <tobi> s/later/former -- srry my english brain is faulting today
14:18:25 <gladk> I think forking is OK. But please setup CI, if there are no. There are a lot of example in existing projects
14:18:30 <gladk> buxy: https://lts-team.pages.debian.net/wiki/Development.html#front-desk-duties
14:18:37 <gladk> ./bin/package-operations --lts --add --package $packagename
14:18:40 <gladk> ./bin/package-operations --elts --add --package $packagename
14:18:49 <Beuc> Who's responsible for maintaining the .gitlab-ci rules btw?
14:19:10 <gladk> all other stuff is just for monitoring, sanitizing, fixing missing information and other minor stuff, not related to wide usage
14:19:13 <Beuc> (because there're always some failures that we currently have to ignore)
14:19:26 <tobi> BTW, the salsa CI team has something to reference the rules at a central place. maybe soemthign we want too?
14:19:49 <helmut> Beuc: salsa-ci team
14:19:53 <gladk> Beuc: well, generally, there is a salsa-ci team for that. We even proposed some changes there and they were accepted.
14:20:08 <buxy> gladk: OK, nice. But we also need documentation regarding the new git requirements that answer the question that have been asked today.
14:20:17 <gladk> But if there is something package specific.... well, it depends. For example lintian checks can be ignored
14:20:33 <helmut> half-off-topic: did someone figure runes to make salsa-ci work better with elts?
14:20:40 <gladk> buxy: yes, it is new information and I will add it to the developer documentation
14:21:06 <gladk> helmut: for stretch it should work good. For Jessie - is on my todo list
14:21:20 <helmut> gladk: awesome. thanks
14:21:58 <gladk> any more discussion points on that topic?
14:22:11 <buxy> #action gladk will complement LTS/ELTS documentation with explanation about git usage
14:22:33 <gladk> please, take some time and put your changes on git. It saves us a lot of time and make the work more transparent and clear
14:22:38 <tobi> eg. you can have "recipes/debian.yml@salsa-ci-team/pipeline" to use the salsa ci team defaults (wont work us, of course) but maybe something along this would help us to centrally maintain the ci-yml
14:22:48 <Beuc> gladk, I'm just surprised that I get 2 failures after following the documentation, but otherwise I'm doing my testing locally so I don't care that much
14:23:09 <tobi> (you can still override per project, by placing the file in the repo)
14:23:35 <gladk> Beuc: maybe it makes sense to have a look. Sometimes it can definitely be ignored (as I said lintian and even sometimes piuparts)
14:23:46 <Beuc> e.g. https://salsa.debian.org/lts-team/packages/git/-/pipelines and https://salsa.debian.org/lts-team/packages/tiff/-/pipelines
14:24:11 <gladk> Beuc: thanks, I will have a look
14:24:24 <buxy> #action Move packages.yml and bin/packages-operations somewhere public for usage by any LTS team member (in the sec-tracker?)
14:24:36 <buxy> We should go forward on the next topics.
14:25:43 <gladk> #topic long lasting issues in {e,d}la-needed.txt
14:26:21 <gladk> we are raising this question since last year. Some packages are in the qeue for months
14:26:54 <gladk> There are some improvements already, but mostly the inflow = outflow, so we have a large backslog
14:27:15 <gladk> the question is, how can we try to solve this problem within the next few months?
14:27:19 <buxy> It's not really a new topic, but it's not solved yet. gladk was not really in favor of forced allocation and we haven't made much progress since then.
14:28:10 <buxy> It's something that is really important for me, we have sponsors and ELTS customers who are monitoring the work we do and who start to ask me why some packages are not fixed. We recently had a question on tiff.
14:28:25 <gladk> We have some new members, and we hope that it can slightly improve the situation, but if threre are some more ideas, how we can imprtove the situation, let's discuss it
14:28:45 <buxy> It should be important for all of you too, if you care about the long term viability of the current model.
14:28:56 <helmut> Can we possibly compromise on content? A number of needed packages have exclusively CVEs that are tagged no-dsa in stable. Is it really urgent to work on those?
14:29:57 <buxy> We can certainly triage more as "ignored" if we feel that they are not worth being fixed, or "postponed".
14:30:32 <bunk> Back in 2021 it worked when I tried to ask for important packages who would take them at the monthly meeting.
14:30:33 <gladk> helmut: that maybe makes sense to add the info into the package, how many percent of open CVEs are no-dsa or ignored with "normal"
14:30:53 <buxy> From my point of view, I prefer CVE tagged that way, at least I can explain to the customer that they have been classified that way, instead of being classified as worthy of being fixed and then not being fixed...
14:30:55 <tobi> (as one of the new members), I have sometimes trouble to get the prorities right. There is ratio-funding and there is age… Not sure how to weigth them.
14:30:58 <Beuc> Did we plan an update to './find-work' to locate those packages more easily?  Also I'd suggest separating sponsored and non-sponsored packages in the weekly backlog report.
14:31:43 <gladk> Beuc: yes, it is on my task list (find-work)
14:31:46 <helmut> buxy: It feels as a double-standard. stable isn't fixing them, but lts/elts tends to fix them. This will be a problem any time stable transitions to lts
14:32:16 <el_cubano> Is sponsored/non-sponsored a meaningful difference in LTS?  Sponsors pay for "all" of LTS, though they may wish to see specific packages prioritized
14:32:27 <gladk> helmut: yes, but we have an inflow of CVEs. which should be fixed fast
14:33:28 <gladk> el_cubano: it is more for ELTS
14:33:55 <gladk> any more ideas?
14:34:09 <bunk> gladk: 16:32 < bunk> Back in 2021 it worked when I tried to ask for important packages who would take them at the monthly meeting.
14:34:15 <buxy> clearly what's needed for ELTS should also be prioritized in LTS, since we ideally want to fix from newest to oldest
14:34:55 <buxy> gladk: the next point of the agenda is also a proposal to help with this
14:34:55 <gladk> bunk: thanks, do we want to go right now through the list?
14:35:01 <helmut> I think what tobi asked was quite precisely what I asked two meetings ago. that seems recurring
14:36:03 <gladk> prioritizing is a good idea and it can be done, but we the number of the packages does not decrease
14:36:08 <buxy> We need to find some way to compute a priority value that combines: age, severity, usage among sponsors
14:36:26 <buxy> and then let find-work sort by this new value
14:36:38 <gladk> does anybody want to take this task to create a model for that?
14:37:02 <gladk> I mean, we need to have some kind of equation, which calculates it
14:37:12 <helmut> Why not drop all packages from ?la-needed where all of the CVEs are tagged no-dsa in stable?
14:37:21 <buxy> but then it's also the job of the frontdesk to manage more actively the open task
14:38:18 <apo> why so complicated. frontdesk is responsible for triaging. If something is fixed in stable it should be fixed in oldstable too. More prominent packages like openjdk, firefox, the kernel, mysql, etc, faster than random ruby package
14:38:21 <tumbleweed> helmut: or drop them down into a "low priority" list (hoping that we have a day when the high-prio list is empty)
14:38:41 <ta> CVEs tageed as no-dsa in stable should be tagged as no-dsa everywhere else. packages with all CVEs marked as no-das can be removed from ?la-needed ...
14:39:03 <Beuc> Why would we, if there're 10 no-dsa CVEs it's usually time to fix them?
14:39:25 <ta> not when nobody will fix them in stable
14:39:25 <helmut> Beuc: because we have a capacity/throughput problem
14:39:36 <bunk> ta: That's not true in general, in stable no-dsa would ideally be fixed in the next point release.
14:39:57 <gladk> if we do not fix no-dsa issues nobody will fix them. If they are not very important, they are still security issues and we should be careful with that
14:40:00 <ta> it makes no sense to have something fixed in LTS when nobody fixes this in stable and after an update the customer is vulnerable again
14:40:23 <helmut> ta++
14:40:36 <bunk> Unless this has changed, shouldn't the contributor who fixed it in LTS also fix it in stable?
14:40:38 <tobi> for that, I try to get my fixes also into stable…
14:40:45 <ta> bunk: ok, in this case they are at some point no longer marked as no-dsa and such would reapear in ?la-needed
14:40:45 <buxy> I certainly agree with all of you. But we have a backlog currently, so fixing bugs in buster that are not yet fixed in jessie, is not our priority.
14:40:57 <el_cubano> I do that as well (working on that with curl ATM)
14:41:02 <apo> yes, please fix the CVE in stable too if you decide to fix no-dsa in LTS and all should be fine
14:41:30 <apo> it doesn't matter if you issue a DSA for it or make a point update.
14:41:52 <gladk> So, we have to move forward slowly. I would propose mark the packages in the ?la-needed according to the no-dsa  fraction of all affected CVEs.
14:42:31 <helmut> gladk: fraction is not the right measure. a single real CVE can be bad enough. we have plenty of packages with exclusively no-dsa issues though
14:42:38 <tumbleweed> helmut: +1
14:42:44 <buxy> s/jessie/bullseye/ in my previous sentence
14:43:15 <buxy> ack with helmut
14:43:53 <gladk> I generally agree with Helmut. But to be sure: at least one "normal" CVE and the package is high prio, right?
14:44:12 <buxy> We should only remove packages where all CVE are tagged no-dsa in bullseye. And mark them postponed.
14:44:32 <buxy> At least one normal CVE and the package stays in the backlog.
14:44:41 <helmut> gladk: we might have to adjust that later, but it seems like a step in the right direction to me.
14:44:51 <gladk> I Agree
14:45:32 <Beuc> I wouldn't /remove/ the package, maybe just mark it as low-prio with a timestamp
14:46:04 <gladk> one more field as a meta-information in the notes?
14:46:08 <gladk> prio?
14:46:21 <helmut> for now, I'd argue for actually removing to get the backlog down. once ?la-needed shrinks, we can consider adding some back
14:46:29 <gladk> high-mid-low?
14:46:32 <tumbleweed> helmut: yeah, that would make sense
14:47:01 <gladk> if we remove the package, it will generate an additional work in the future to add it again
14:47:23 <buxy> I would remove the package too. And we should have another way to identify packages that might need work for when contributors find nothing to work on within dla-needed.txt
14:48:35 <tobi> I'd say priority would work as well as another list?
14:48:38 <gladk> ok, if we have more-less consensus, let's document it and move forward
14:48:39 <bunk> I don't think low-priority packages are a big problem.
14:48:48 <gladk> we have two more important questions to discuss
14:49:21 <bunk> IMHO the bigger problem is who would be willing and confident to touch packages like samba.
14:49:41 <el_cubano> I've worked on Samba in the past.  It is certainly not for the faint of heart
14:49:58 <el_cubano> But, I think that package owner proposal might help there ;-)
14:50:22 <buxy> #topic package owner proposal by Roberto
14:50:43 <el_cubano> Oh, wow, how convenient!
14:50:55 <buxy> Time flies :)
14:51:04 <gladk> #action prioritize the package in ?la-needed.txt according to no-dsa CVEs. Maybe remove some not important ones (to backlog?)
14:51:30 <gladk> #topic package owner discussion
14:51:40 <el_cubano> So, the "package owner" proposal is something that I came up with a couple of months ago.  I have spoken to a few LTS/ELTS/Freexian folks about it individually and written up an initial proposal, which I send to the debian-lts ML on Tuesday night.
14:52:23 <el_cubano> IRC is not the best medium for an in depth discussion, but I am happy to answer questions and accept suggestions on the topic (especially if you have read the proposal and have specific feedback)
14:53:37 <gladk> I think basically it is a very good idea. @all please read it carefully and comment it on the ML or in the gitlab issue
14:53:59 <gladk> it would really help us to make some changes
14:54:22 <el_cubano> The GitLab issue isn't visible to everyone, so there's that.  The ML thread is fine and I can incorporate all the feedback/questions into the final proposal that will go into the docs
14:54:40 <gladk> https://lists.debian.org/debian-lts/2023/01/msg00017.html
14:54:45 <buxy> My take is that I'm willing to try anything that improves the current situation but I have no idea if people would be willing to step up to such roles. After all it means that you can be summoned to work on "your" package at any time. Even if you have the liberty to find someone else to take over or delegate to external partners when you don't have the skills, it's still a duty that you don't control.
14:54:49 <Beuc> el_cubano, same comment as last time, I'd recommend working in pairs from the start (when somebody's responsible for something important, we gotta have a backup person)
14:55:03 <helmut> how does the package owner proposal affect ?la-needed.txt management? possible routes I see a) owned packages are automatically assigned b) owner is written in a note c) no effect at all
14:55:26 <gladk> helmut: no automatic assignment
14:55:27 <el_cubano> Beuc: Agreed.
14:55:39 <tumbleweed> I think it could be a great way to handle the "scary" packages, and make sure that the regular high-priority packages get the attention they need
14:56:31 <el_cubano> gladk: If we aren't going to auto-assign to the owner (which I think is fine) then we need to ensure that FD pings owners once <time-delta> elapses with no work on the package
14:56:50 <tobi> I think for the scary packages it would help to have >1 person, for peer reviews etc.. to make the scare "lesser".
14:56:57 <buxy> IMO FD should mail the owner, but not auto-assign
14:56:59 * tumbleweed would imagine that the owner could review anyone else's work on a package, too
14:57:07 <bunk> buxy: It works for linux for years to have a fixed owner.
14:57:11 <tumbleweed> (I mean, an obvious go-to reviewer)
14:57:18 <gladk> el_cubano: I think pinging is better, but maybe it is just a....
14:57:25 <el_cubano> Essentially, being an "owner" means you are committing to having bandwidth available (or to making room for the bandwidth) to make sure that work on "your" package gets done
14:57:45 <gladk> OK, let`s read the mail and the issue one more time and please comment it, when you find time.
14:58:18 <el_cubano> Ack.  I will be travelling this weekend, so next week I will go through replies and integrate everything that we have into a final proposal
14:58:30 <tobi> el_cubano: that might be a logistic problem for contributors. the bandwidth is more or less pre-allocated already.
14:58:33 <gladk> the time is over
14:58:39 <gladk> we have one more point
14:59:04 <buxy> Let's take a few minutes for it anyway.
14:59:23 <helmut> tobi: given that we are still understaffed, you can most often acquire unassigned hours. might change in future.
14:59:28 <gladk> #topic security team
14:59:57 <ta> can't we ask the maintainer of packages to update in LTS/ELTS and get paid for it?
15:00:00 <tobi> helmut: yeah, but not the (wall) time I'd need to allocate
15:00:35 <gladk> should I copy the message here?
15:00:50 <buxy> gladk: no
15:01:07 <buxy> ta: might be doable if they can send invoices
15:01:34 <buxy> So regardingt the last point, I would like to know if some of you would be willing to work towards joining the security team like apo did a while ago.
15:01:38 <el_cubano> ta: and then the LTS/ELTS "owner" becomes the coordinator/manager (which presumably takes less time than the actual heavy lifting)
15:02:09 <Beuc> At first glance I'd be interested in joining the security team, what's the security team's view on this idea?
15:02:47 <buxy> As you noticed, it's not correct to fix things in LTS when it's not fixed in stable and it would surely help if we were more active working on stable.
15:03:00 <helmut> ta: interesting idea. though we might have to sponsor the uploads and commit the website things, so it still needs a supporting contributor
15:03:18 <el_cubano> That would also help reduce the backlog problem (though only in the long term)
15:03:33 <el_cubano> helmut: +1
15:03:43 <buxy> I'm considering to make the policy more clear that we should always provide patches for stable, and for those that do, I imaginge that they could join the security team since they are effectively doing stable security work.
15:05:34 <buxy> Not everybody obviously will join obviously but having one or two long time LTS members among the security team would help to create bonds, and possibly make it easier to converge towards a common workflow for security work in the 5 first years.
15:05:50 <ta> but security team does not only mean to fix issues, but also take part of their other tasks ...
15:05:51 <helmut> doing SPUs does not require being a sec team member nor interaction with them. preparing a DSA with a supporting sec team member also works.
15:06:19 <el_cubano> This has been said enough times (that we can/should contribute fixes to stable) that I just do it by default now.  Formalizing the policy would be good, though, especially for new contributors to know that this should be standard practice
15:06:36 <ta> if the sec team is fine with more members, I would be interested as well
15:06:37 <buxy> Right now the security team has zero incentive to work towards a common workflow, it's more work for them, but if we have a few persons within the team that can handle the required work, then it might be different.
15:07:40 <tobi> in what (important) aspects do their workflow differ? Could we change ours?
15:07:46 <buxy> So hence my question, would there be LTS team members that would be willing to go the extra mile to make the required work to prepare tested updates, ready to be published without further review, including drafting DSA and so on.
15:08:19 <ta> yes
15:08:33 <tobi> buxy: I'm doing already so, but I'm feel I'm too fresh
15:09:06 <apo> I'm already doing that, so no changes here
15:09:18 <buxy> Heh and in you are in the team already :)
15:09:18 <tobi> (but until now it was _always_ make a stable proposes update)
15:09:47 <Beuc> yes, I'd like to help security-team
15:10:38 <helmut> my only longer interaction with sec-team since freexian was/is an embargoed issue, everything else was SPU. I expect that much of what we do is going to be SPU, not DSA
15:11:30 <buxy> Ok, if other members prefer to answer later — after all it comes out of nowhere for most of you — feel free to reach out to me.
15:12:09 <buxy> Thank you for the time taken for this meeting and see you next month in a videoconf.
15:12:34 <buxy> #endmeeting