 But, thank you for coming, this is not a presentation, but above, so mostly a team meeting, but also an opportunity for newcomers, if they have any questions about the project, if they are interested in joining. Okay, but then I think we can take a look at the questions that we have already identified. What do you think? I'm not sure if the people understood the first question. Are those who are not part of the LTS team interested in joining? Or are you just interested in the policy of the LTS team and want to watch out? I'm interested in joining maybe the LTS team. Actually, we exchanged emails about that and still need to answer you on that topic. For now, I'm just definitely interested in finding more out, so please go ahead. Okay, internally, I think we need to define a process to dispatch the front desk duties, especially because we need to rotate the front desk and I don't have any week assigned in several months, just because before it was Raphael who assigned the weeks and then kind of tried to do it by ourselves, but it's not very well done, I think. It's not even fair in the distribution, but it was Raphael who wrote it down. I wanted to see how it worked out because it was suggested that I might not have to do it. It's not working well enough, so one of the possibilities might be that the front desk duties include the responsibility to dispatch further weeks and then you see that you don't have enough weeks assigned. For example, each time that you start front desk duties, you look up if you have assigned people for the next two months and if it's not the case, then you either make sure that they register or dispatch using some predefined algorithm. We come back to the initial solution where I do it, but I don't know what you prefer. I can bring the make to anyone who wants to comment. I was finding swapping quite difficult before, so I think whoever assigns them, that's not ideal. Whoever actually does it, it makes a difference to you, but it was like, okay, I've been given this week, can't really do it, trying to swap, no one really replies. I'm actually quite liking the new way of doing it, but I can see how that can leave. If you don't see that mail and you don't keep on top of that, you can have no duty for a couple of months. So instead of assigning whoever checks must just send a new mail and make sure that people sign up, make a proposal. Could we instead put in there, I am not available these weeks, and then either a program or an individual is possible for avoiding assigning people to those the weeks when they're off. Is this something that could work for everybody? Basically, you have to document weeks where you're not available, and then maybe one month before we dispatch them, or two months before. I don't know how far in the future you have visibility on your schedule. Would you like to redistribute the current, the future weeks? Because I think there are only four that are working in the front desk. More people should do it. Yeah, I think. Yes, let's try something like that. So next question. This is required by the security team, by the saboteurs especially. To uniform, synchronize the workflow with the security team, especially to try CVS and five bug reports. So actually there is a separate tag from the security section which shows as a goal which is to bring that week down, but sometimes not having checked the location yet. The goal is to bring that week down. And we usually don't feel about it if it's already closed. But yes, the goal is actually done. Already done? Okay. This is also a suggestion from Salvatore, from the security team. No, no, no, I'm wrong. We were discussing about what to do with some non-DSA issues, because for several reasons they are not, they are tagged non-DSA for stable, but we could fix them in old stable. So one of the problems or one of the conditions is that we don't have a next point release. I don't remember who, but someone suggested that we should have a mechanism to have this kind of, or an equivalent to reuse packages with minor issues periodically, not to fix something minor immediately, but wait a little bit. I think Moritz Moulonhof was suggesting to introduce that concept as well for LTS. It was some days on the LTS mailing list, I think. Yes, his point was to that minor issue should not trigger instant updates, because well, many security administrators will have to deal with it, and it was maybe better to patch them in point release, like for other stuff. I don't think we're ready for that yet, but we could do. At some point it would probably be nice to not have a separate workflow for LTS and usual release, so do actually continue to do point release. I don't think right now is the best time, but actually it makes sense, even more sense now that we're using the security.debian archive, because quite a few tools know only of the main mirror, not perfectly of the security mirror. For instance, our package.debian, he said the aptitude changelog viewing feature, which relies on some service, which is only parsing the main archive and not the security archive. I believe we have a similar limitation with package.debian.org, stuff like that. So it would be useful at some point to consider doing it. I'm not sure right now at the start of the WYSI cycle is the best time to do it, but... In particular, given that I believe that the release team has been somewhat annoyed by the switch to WYSI, because we dropped some architectures before they had the opportunity to merge them back, and it was somewhat painful for them or something like that. But the real question is how do we deal with multiple meanings of Node-DSA, because we tend to follow the Node-DSA from the security team. When the security team tags an update as Node-DSA, we usually do the same, but we must take care when they just do it because they believe it will be fixed in the next point where it is by a maintainer replowed. We should probably fix it by our own and not tag it Node-DSA. So this is maybe some documentation point that we have to improve for whoever is doing front desk duties and triaging. I mean, that's the main question here. And we should try to have more capacity to decide by ourselves the severity of a given CVE. Maybe not all of us are at ease with this process, and maybe not all of us are willing to make hard decisions. But we should try to... It's easier to decide to do some work for something which might not be needed the other way around. So better be conservative in your issue that turns out to be more severe afterwards. I think most of the people are doing it that way. I don't know, but in my opinion the answer is better documentation for front desk people who are doing it. So it would basically mean that we use Node-DSA very sparsely and basically just until we have point releases, right? Because we only have for very, very minor issues we can just ignore them and maybe then we should actually mark it in the change lock anyway. Why we marked it Node-DSA? At the moment it's like when you read the change lock it says it's Node-DSA but probably sometimes you don't know what's the reason. That would sometimes be nice to find out. Actually you can document in the CVE list file between parenthesis the reason. We should do it and you should read the reason why the security team marked it as Node-DSA and when it's only because it will be done in the next point release and it's not enough of a reason for us to mark it as Node-DSA. Anyone else something to say on this topic? Then let's move on. This is not a good one. Something that I've been working on and something that I feel quite excited about trying to minimize the regressions. And I think the DT8 and autofocus test could help a lot on that but we have to write the test and talk it with Antonio. He said that we could make the Cdebian.net also checks for stable and non-stable and other suites and that could be quite useful. Something that we could kind of officially try to spend some time on writing the regression test. This is one of the things that we can do when there are not too many things to fix and really I need it. Yeah, and that's it. So I think that Guido has quite experienced, more experience than me in autofocus test. And I've been spending some time in this month since work sometimes and sometimes it doesn't. But yeah, we need to work on this. It could be cool. Yeah, I basically fully agree. So we should try to work with Antonio to get this basically automated so that we can test things. And it would actually, it would be perfect to have things test before we upload these, right? At the moment like DAPCI is past upload and for us it should actually be before upload. Yeah, one thing is, yeah, kind of have a procedure to build because I use Co-Builder. As far as I know, autofocus test and Co-Builder don't work with each other. So we need to find another way and document it. Yeah, it works in more recent versions and we see it's a bit hard. There is a bug that is still open about that. We could check, but yeah, we could test before uploading. Yeah, so I'm using it with Co-Builder usually, but it doesn't always work. Okay, someone else has something to say. I think it's no objections. Move on. I just wonder how we would move on like working with Antonio to get this going. Sorry? I just wonder how we would work with Antonio to get this going, like integrating old stable into DAPCI. What would be the next step? Yeah, but anyway, there are two different things. Should we start with writing tests first? Yeah, because we could try them locally then with CI. I'm fine with that. Do we have those three packages you mentioned? ZN, Squared, EG, and C. Are they ones that have regressions in the past, all these ideas or they have tests or... Those are packages that I work on in the past that suffer from regressions. Okay. Right now, working on the test for Squared that will help to identify those regressions. Do we have a hit list? That was my case. Okay. But yeah, it could be useful to look in the previous packages, the previous regressions that we have. Yeah. EGWC also has an extensive upstream test suite. So it maybe makes more sense to see whether there are holes in there that should be covered and could be contributed back upstream rather than adding external DAP8 tests. I don't know. What I'm saying is if a package already has test suites that can run or possibly do run at build time, it is perhaps better to extend those rather than adding a completely separate set of tests following DAP8. Yeah, but one thing is even if some packages have the upstream test suite with AutoPKT test, it makes it possible to test them in a running infrastructure. Yeah. And we could try other conditions that are more difficult to have in an upstream. Also for grep, for example, the test suite is quite good. So I'm just using it as an AutoPKT test. Right. Yeah, I see. Sorry? Yeah, okay, I see. I'll take your point. Anyone else? Just move on. The next point was other things to do while we don't have too many packages in the earlier years. You don't know if you have some ideas what to do. Well, I think there are a lot of improvements to do in infrastructure in security tracker, in the tracker, in the automating things that we can do when we trash bugs, and I cannot connect to Gobi. It doesn't automatically open the list view. Sorry? You probably need to open the list view because it doesn't automatically open the list view. Oh, who's writing here? So the first point in the infrastructure that we should really fix is what we discussed a few days ago on the list. We tend to do mistakes while doing updates on packages which are actually no longer supported. It's somewhat of a waste of time, and so it would be good to improve our tools to help the front desk with the trading to mark them immediately as the end of life instead of adding them to the DLA-needed.txt file. There are many other things that could be improved on the security tracker. We have a bug page with wishlist. I'm not sure if it works. I mean, it would be nice to have them down. I'm not sure it must be down on pet time from pet contributors. But some of them probably could, and I have no problem with finding more of them when it makes sense. Well, it's a case-by-case by this, I guess. But if you're looking for ideas of things to do better... Unfortunately, it looks like we're overrun our time slot. Oh, we have two time slots. Oh, we have two? Sorry, never mind. So maybe this is more for people who are not yet in the team. You see other things that would be important for us to do than just fixing packages. Among pet contributors, we have this sort of agreement that when we have dealt with old pending security updates, we have the right to spend time on adding, for instance, step eight test suite for a package which have regular security updates and stuff like that, and generic work on improving the infrastructure. But we don't have so many extra time, but we do have a bit from time to time. So it falls under the things to do other than fixing packages, but only a sort of last resort when we have no package left. That said, I believe it's great if we are able to add the step eight tests while handling security updates because this is our investment that pays off rather quickly. But there's no point in forcing us to do it, but if we have people who are knowledgeable and know how to do this and want to do it, I believe it's fine to do it as part of somewhat regular updates. I have one thing which does not fit directly here on the front desk task. There is work pending which Judith and Thorsten already contribute patches. If you can brought FTP masters again about this sending the mails to the signer of the upload because basically nowadays we still forward the reject and you mails to the respective uploader and yes it's a bit of a work burden which wouldn't be needed if that would be applied. So if you can do someone of you can ask again FTP master, that would be great. What's actually broken though? We have prepared a patch which basically sends that configurable on who you send the accepted and rejected mails because for the security updates it's hard-coded to some security alias and whoever's uploaded does not get any notification of accepted mails. You have to monitor the Debian LTS changes right now to find out if the uploader happened or was accepted and you don't get any reject mails. The security team does and they are now to have to forward. We prepared the patch a few months ago and it's really working and we just need FTP master to apply it. I pinged Ansgar multiple times before the switch but it didn't continue. Maybe you have... I didn't know it was a thing so if you can someone send me something now. Yeah, we'll add the back number into Gobi. All the ideas? Gido, do you want to send something? No. No, I don't want to go over the same thing. Okay. If I said something I don't remember that you could say. So one thing I wonder about is what we're going to do about the case where we fix Weezy and it has a security fixed version and Jesse hasn't for some time because the security team might be overloaded or the next point release might be pretty far away and people updating would basically become a less secure system than they had before. Is this anything we want to worry about and fix Jesse as well? So we don't worry about? Well, I've previously gone and fixed Jesse as well. Or... Yeah, it was about then it was Weezy and Jesse I think if it's not going to be a huge amount of work then we should probably just go ahead and do that. Okay, next point. I wrote this because I think that we didn't contact the maintainers of packages when we were reviewing them and I think it's a good thing to do even if there are minor issues because I think it's good to attract the maintainers to do all this stuff. But I don't know, what do you think if there is a reason to not contact the maintainer? When you say... So the standard... the documented procedure at the moment is you could contact them if you think that a fix is needed. You're saying we should contact them if we decide that it's not here to say it as well. Well, we are forgetting to send those mails. Ah, okay. I don't know if we should change that or we have to still contact the maintainer. I think it's a good thing to do. So we should maybe just be careful in doing it more often. Or maybe all the time. I'm not sure in those two. What do we miss doing? I mean... The official documentation is rather clear that when we create, we should use being contacted a maintainer or whatever. The point is sometimes we are not sending mails to contact the maintainer. Even the documentation says that just because I tried to look for some packages and I found a mail that is sent to the maintainer. It's not an important point. But I think the last weeks those mails were not sent. Well, okay. But then just reply or make a point on the different LTS and whoever is doing with LTS from there should fix their workflow. Yeah, I was just wondering if there was a reason to... Oh, right. Well, I don't think so. Do you know who missed the mail? So you can answer. No, I think it's a mistake. It's a good point actually. We all do mistakes and we should be watching ourselves. I tend to, for instance, check that any upload comes with a DLA. So if someone forgets to send the DLA I'll inform him. It's a shared responsibility we should have together to notify others when they are doing mistakes. I have one comment to the things to do other than fixing packages in DLA needed. It's related to front desk duty. I think Santiago said that he and Moritz are basically peer reviewing things when they change into the tracker and I think it would be good if the front desk person would do that as well. Like basically going through the commits that were made in the CVE list and checking to avoid things that happened recently with what was it, the example you had, Salvador, which Brian figured out. Yes, that was one of the mistakes. I did so pitching. There were, I think, over 20 CVEs in one day and I did check them against the upstream advisory and cross-checked with Red Hat Baxilla then and that information matched but the commit referenced to another CVE so Brian may then found that and corrected the information. So peer review is a good thing. Okay, we have less than 5 minutes left. Yeah. I just want to comment that I've been using Call of Mind for some packages and I think it could be useful, especially if we have another CVE box that we could push the fixes in the repository and wait a little bit if maybe someone else could upload the packages with all the fixes, then it's just that. Maybe we could agree on using more Call of Mind for this kind of stuff. There is already a Debian LTS directory but that's it. So what's the last point? Do you want to apply the security updates in Git repository directly? Yeah. You send patches based on the Git repository, you mean? Or do you plan to push a branch or whatever? I'm doing this for packages where we don't have the right or where they are team-specific and not all Debian developers have the right to push in the Git repositories. So I'm maintaining some packages in the top. The branch for WC is security. I'm maintaining branches for WC security. For packages which are in Call of Mind, so those you actually push, if there are no WC branches, you create one and if there's one, you add new commits on top of it. Okay. This is okay, I would say. Usually packages which are in Call of Mind are there for good reasons so that we can share those. But also for packages that we don't have the right that they're not in Call of Mind, I create a new branch in Call of Mind for that package. This is maybe a waste of space, but I'm not sure. I would just send the three patches ready to be applied with Git IEM or something like that if we duplicate so many repositories we're going to... Well, yeah, that's true. I saw you did it and I was wondering. Okay, we are going out of time, I think. Something else? No? If you want to have a word about the security support, but it's not our primary responsibility. That said, it's a shared responsibility with the security team. I don't know what you wanted to discuss on this. I don't know. Just because it's a shared responsibility and maybe we... Christophe, the original author of it, we saw that the maintenance of it is getting to its limits. So maybe we will be needed to change the language because now it's a script and maybe we will have to write it again and see maybe. But it's something to discuss later, I think. Okay. Okay, then, thanks for coming. Well, maybe last round of questions. If outsiders had some questions after the... Do any of you... No, it's okay. Thank you. Thank you.