14:00:35 #startmeeting 14:00:35 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:56 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 we usually just o/ 14:01:23 #topic Identify yourself 14:01:30 o/ 14:01:37 o/ 14:01:38 o/ 14:01:42 o/ 14:01:46 Please no full names. I can elaborate if needed. 14:01:48 o/ 14:01:53 o/ 14:01:55 o/ 14:02:19 o/ 14:02:48 #topic Git usage and tag monitoring 14:03:00 \o 14:03:13 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 o/ 14:04:16 Hi 14:04:27 . 14:04:43 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 We started to monitor it, and it runs relatively good 14:05:24 we have some uploads, which are still not in the git 14:05:40 and it would be good that everybody uses it 14:06:05 also I would hear, if there are some objective problems or dificutlies in its usage 14:06:06 o/ 14:06:12 it as in git or the monitoring tool? 14:06:24 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 #chair gladk 14:06:35 Current chairs: buxy gladk 14:06:38 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 hah. same question as apo. :) 14:07:08 :) 14:07:11 apo: sure, you can. If even the repo is created automatically, feel free to drop it and clone 14:07:39 dropping a repository requires owner privileges AFAIK 14:07:40 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 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 right, that sounds sensible 14:08:37 I looked for that package database earlier and failed to locate it. would you remind me where that is? 14:08:41 where is the package database? 14:08:52 https://gitlab.com/freexian/services/deblts-team/debian-lts/-/blob/master/packages.yml 14:08:55 I'm in favor of just adjusting the link in the database instead of cloning it 14:09:20 apo: sure, feel free to do it! Just let us know, whether the newly created repo should be removed. 14:09:45 ok, I'll send you a private message when I'm done 14:10:05 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 any more question about that? 14:10:40 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 FWIW, I think that this database should be hosted publicly in lts-team. 14:11:43 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 please use it 14:11:53 And the tool(s) to interact with it too. 14:12:01 when using the maintainers repo, how to ensure maintainers wont delete the branches? Especially in the debian group? 14:12:08 If you want, we can organize a short video-tutorial session, where I can show, how to use it 14:12:30 it is pretty simple, but helps to keep the stuff in the order 14:12:48 buxy: note 14:12:50 noted 14:13:11 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 tobi: that is why my preference to use the separate repo to escape this situation and potential confilcts 14:13:51 I agree. 14:13:55 (In general tags are not removed, even if branches are) 14:14:01 also the CI is being setted up there automatically, and it increases the number of checks and general package quality 14:14:02 and a fork can always be merged back too 14:15:05 So, generally, it does not really matter, whether the git repo is hosted, important is to document the done work. 14:15:25 any more question about this part? 14:15:59 please feel always free to ask or propose improvements if you see a potential for that 14:16:21 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 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 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 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 srry, bounce button 14:17:33 Forking it is best IMO (unless they use some really unusual conventions). 14:18:17 s/later/former -- srry my english brain is faulting today 14:18:25 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 buxy: https://lts-team.pages.debian.net/wiki/Development.html#front-desk-duties 14:18:37 ./bin/package-operations --lts --add --package $packagename 14:18:40 ./bin/package-operations --elts --add --package $packagename 14:18:49 Who's responsible for maintaining the .gitlab-ci rules btw? 14:19:10 all other stuff is just for monitoring, sanitizing, fixing missing information and other minor stuff, not related to wide usage 14:19:13 (because there're always some failures that we currently have to ignore) 14:19:26 BTW, the salsa CI team has something to reference the rules at a central place. maybe soemthign we want too? 14:19:49 Beuc: salsa-ci team 14:19:53 Beuc: well, generally, there is a salsa-ci team for that. We even proposed some changes there and they were accepted. 14:20:08 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 But if there is something package specific.... well, it depends. For example lintian checks can be ignored 14:20:33 half-off-topic: did someone figure runes to make salsa-ci work better with elts? 14:20:40 buxy: yes, it is new information and I will add it to the developer documentation 14:21:06 helmut: for stretch it should work good. For Jessie - is on my todo list 14:21:20 gladk: awesome. thanks 14:21:58 any more discussion points on that topic? 14:22:11 #action gladk will complement LTS/ELTS documentation with explanation about git usage 14:22:33 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 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 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 (you can still override per project, by placing the file in the repo) 14:23:35 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 e.g. https://salsa.debian.org/lts-team/packages/git/-/pipelines and https://salsa.debian.org/lts-team/packages/tiff/-/pipelines 14:24:11 Beuc: thanks, I will have a look 14:24:24 #action Move packages.yml and bin/packages-operations somewhere public for usage by any LTS team member (in the sec-tracker?) 14:24:36 We should go forward on the next topics. 14:25:43 #topic long lasting issues in {e,d}la-needed.txt 14:26:21 we are raising this question since last year. Some packages are in the qeue for months 14:26:54 There are some improvements already, but mostly the inflow = outflow, so we have a large backslog 14:27:15 the question is, how can we try to solve this problem within the next few months? 14:27:19 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 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 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 It should be important for all of you too, if you care about the long term viability of the current model. 14:28:56 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 We can certainly triage more as "ignored" if we feel that they are not worth being fixed, or "postponed". 14:30:32 Back in 2021 it worked when I tried to ask for important packages who would take them at the monthly meeting. 14:30:33 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 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 (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 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 Beuc: yes, it is on my task list (find-work) 14:31:46 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 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 helmut: yes, but we have an inflow of CVEs. which should be fixed fast 14:33:28 el_cubano: it is more for ELTS 14:33:55 any more ideas? 14:34:09 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 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 gladk: the next point of the agenda is also a proposal to help with this 14:34:55 bunk: thanks, do we want to go right now through the list? 14:35:01 I think what tobi asked was quite precisely what I asked two meetings ago. that seems recurring 14:36:03 prioritizing is a good idea and it can be done, but we the number of the packages does not decrease 14:36:08 We need to find some way to compute a priority value that combines: age, severity, usage among sponsors 14:36:26 and then let find-work sort by this new value 14:36:38 does anybody want to take this task to create a model for that? 14:37:02 I mean, we need to have some kind of equation, which calculates it 14:37:12 Why not drop all packages from ?la-needed where all of the CVEs are tagged no-dsa in stable? 14:37:21 but then it's also the job of the frontdesk to manage more actively the open task 14:38:18 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 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 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 Why would we, if there're 10 no-dsa CVEs it's usually time to fix them? 14:39:25 not when nobody will fix them in stable 14:39:25 Beuc: because we have a capacity/throughput problem 14:39:36 ta: That's not true in general, in stable no-dsa would ideally be fixed in the next point release. 14:39:57 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 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 ta++ 14:40:36 Unless this has changed, shouldn't the contributor who fixed it in LTS also fix it in stable? 14:40:38 for that, I try to get my fixes also into stable… 14:40:45 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 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 I do that as well (working on that with curl ATM) 14:41:02 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 it doesn't matter if you issue a DSA for it or make a point update. 14:41:52 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 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 helmut: +1 14:42:44 s/jessie/bullseye/ in my previous sentence 14:43:15 ack with helmut 14:43:53 I generally agree with Helmut. But to be sure: at least one "normal" CVE and the package is high prio, right? 14:44:12 We should only remove packages where all CVE are tagged no-dsa in bullseye. And mark them postponed. 14:44:32 At least one normal CVE and the package stays in the backlog. 14:44:41 gladk: we might have to adjust that later, but it seems like a step in the right direction to me. 14:44:51 I Agree 14:45:32 I wouldn't /remove/ the package, maybe just mark it as low-prio with a timestamp 14:46:04 one more field as a meta-information in the notes? 14:46:08 prio? 14:46:21 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 high-mid-low? 14:46:32 helmut: yeah, that would make sense 14:47:01 if we remove the package, it will generate an additional work in the future to add it again 14:47:23 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 I'd say priority would work as well as another list? 14:48:38 ok, if we have more-less consensus, let's document it and move forward 14:48:39 I don't think low-priority packages are a big problem. 14:48:48 we have two more important questions to discuss 14:49:21 IMHO the bigger problem is who would be willing and confident to touch packages like samba. 14:49:41 I've worked on Samba in the past. It is certainly not for the faint of heart 14:49:58 But, I think that package owner proposal might help there ;-) 14:50:22 #topic package owner proposal by Roberto 14:50:43 Oh, wow, how convenient! 14:50:55 Time flies :) 14:51:04 #action prioritize the package in ?la-needed.txt according to no-dsa CVEs. Maybe remove some not important ones (to backlog?) 14:51:30 #topic package owner discussion 14:51:40 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 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 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 it would really help us to make some changes 14:54:22 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 https://lists.debian.org/debian-lts/2023/01/msg00017.html 14:54:45 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 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 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 helmut: no automatic assignment 14:55:27 Beuc: Agreed. 14:55:39 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 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 elapses with no work on the package 14:56:50 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 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 buxy: It works for linux for years to have a fixed owner. 14:57:11 (I mean, an obvious go-to reviewer) 14:57:18 el_cubano: I think pinging is better, but maybe it is just a.... 14:57:25 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 OK, let`s read the mail and the issue one more time and please comment it, when you find time. 14:58:18 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 el_cubano: that might be a logistic problem for contributors. the bandwidth is more or less pre-allocated already. 14:58:33 the time is over 14:58:39 we have one more point 14:59:04 Let's take a few minutes for it anyway. 14:59:23 tobi: given that we are still understaffed, you can most often acquire unassigned hours. might change in future. 14:59:28 #topic security team 14:59:57 can't we ask the maintainer of packages to update in LTS/ELTS and get paid for it? 15:00:00 helmut: yeah, but not the (wall) time I'd need to allocate 15:00:35 should I copy the message here? 15:00:50 gladk: no 15:01:07 ta: might be doable if they can send invoices 15:01:34 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 ta: and then the LTS/ELTS "owner" becomes the coordinator/manager (which presumably takes less time than the actual heavy lifting) 15:02:09 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 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 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 That would also help reduce the backlog problem (though only in the long term) 15:03:33 helmut: +1 15:03:43 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 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 but security team does not only mean to fix issues, but also take part of their other tasks ... 15:05:51 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 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 if the sec team is fine with more members, I would be interested as well 15:06:37 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 in what (important) aspects do their workflow differ? Could we change ours? 15:07:46 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 yes 15:08:33 buxy: I'm doing already so, but I'm feel I'm too fresh 15:09:06 I'm already doing that, so no changes here 15:09:18 Heh and in you are in the team already :) 15:09:18 (but until now it was _always_ make a stable proposes update) 15:09:47 yes, I'd like to help security-team 15:10:38 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 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 Thank you for the time taken for this meeting and see you next month in a videoconf. 15:12:34 #endmeeting