 It's been up to in the last year or so. So Adam didn't want to come up here and give the talk, sorry. It's me instead. So we had some changes in the team. We have a new release manager, new minions doing the work instead of us. And we're going to be talking about the freeze, the timeline that we're looking at, and trying to see if we can make the freeze less than nine months this year. And for that, we're going to need a lot of help from every one of you. So first, the changes in the team. We have new release assistants, Evo and Emilio. I think at the moment, Emilio is doing 99% of the work in the team. And Evo implemented something that has been very useful for us in this cycle, which is automatic removal of packages from testing when they're buggy, which means that at the moment, we don't have as many bugs in testing than in the previous cycles. Nils has agreed to be our new release manager instead of Nils, or instead of Nils. Well done. And we also got rid of the release without kind of role, because some of these people are no longer very much around, and the others, we know what if we have some questions or we think they need to work more. So that's it for the team changes. And we also are looking at a timeline for the freeze. So the next important step is to stop making new library versions go into unstable and testing, so that we can try to freeze with something resembling the same state. We're also going to do a final check on what architectures are going to release. There are a couple that are trying to bootstrap and sit right now. And there's also some issues with the existing one in testing, so that's going to be our final check. We had a meeting with DSA this week, so we're going to wrap that up soon. And then in one month, we're going to ask people to make sure that their package is in good shape in testing and to avoid the rush to upload two days before the freeze with high urgency package, which is a new upstream version or something like that. We are going to, we're probably going to ignore the urgency setting in the package changelogs. And we're also going to look at what the security team tells us about which packages they are not able to support, because they are going to have to live with what we release. So, yeah. And then finally, one month later, we will freeze testing, which means no more automatic migrations of packages from unstable to testing, which means if you need your package, your new package version to go into testing, you will have to go through the Debian release team. That means in two months' time, we will freeze. So what's the status of Jesse at the moment? We have 450 RC bags, something like this. We had 350 a couple of days ago. Then Luke has decided that's not enough, so he started a mastery build of the archive, and that's what happens. But if we look at previous cycles, we would be around 1,000 right now, so it's not too bad. And if those 100 new RC bags, I guess a few of them are already being fixed in unstable, and in two weeks' time, the auto removal tool will decide that, hey, this package has an RC bug, its maintainer hasn't replied to the bug, so we'll remove it. So we should be fine. It will be fine. So that's the RC bug graph for stable testing and unstable for the last year or so. And one thing that is quite clear on this graph is how the automatic removals have helped. They started around here, I'm guessing. So we are pretty close to the number of bugs in stable. We were below the number of bugs in stable until a couple of days ago, yesterday, when Luke has filed 100 bugs. He's not busy enough as DPL. So what's going to be the Frisk policy? First, you can find it on this page, on our website. It will be similar to Whizzy. In the beginning, it will be less strict. And then as the Frisk goes on, we will no longer accept fixes for non-risk critical issues. So obviously, those we very much want. We are also, at least in the beginning, going to accept important bugs for most packages. And translation and documentation updates are probably going to get in as well for at least a while. On the other hand, what will be different from the Whizzy cycle is that because you all know when the Frisk is going to happen, you will need to make sure that new package versions are in testing by November 5th. And there will be no automatic unblocks for packages that are unstable at that point. So make sure that you upload a little bit in advance if you have new versions of things that are not within the Frisk policy. So the auto removals will continue. But we will allow auto remove packages to come back to testing if they are fixed quickly enough, only for the three first months of the Frisk, hoping that by then we will be close enough to release that it's no longer sensible to add new packages. So we're probably not going to remove Collins packages. But everything else is a candidate. For auto removals, we have a cutoff of popularity contests or that kind of things to whether a package can be auto removed or not. But we can also remove packages manually if they are buggy. So please fix your bugs. And if you have spare time, fix everyone else's. So what we're going to ask is to stop introducing new surname bumps in SID from pretty much now, unless you've coordinated this with a release team member. Don't upload packages too unstable if you don't think that it should be in Jesse, because that makes it more difficult to actually get bug fixes in Jesse, either for that package or for its reverse dependencies. So that's not so nice. And please keep fixing RC bugs. Gregor is a bug-fixing machine, but it will be faster if he's not around doing that. And so other things, apart from fixing the existing bugs, is to find new ones by testing upgrades from wheezy on existing systems or on test systems and make sure that the disk upgrade actually works. There's an upgrade reports pseudo package. There's a Debian testing mailing list, which those bugs go to. So please test the disk upgrade. And please, if you want those bugs and re-sign them to the right places, that would be appreciated too. For DI, we also need people testing the installation process on various architectures, on various machines. And there's the installation reports pseudo package that goes to Debian Boots. And yeah, you can also report successful upgrades or successful installation reports. And that makes us more confident that not everything's going wrong completely. We also need release notes for the release. So if there are major changes to your packages or if your package is, let's say, an init system that is a new default and user-visible things that might make sense to document, then please file bugs against the release notes pseudo package, preferably with a paragraph or two text, because the release note editor might not be familiar with your package. So if you can provide some ideas of what to say, that would be helpful. And finally, how to make our lives easier, which hopefully will make the freeze shorter as well, because we will have more time to use your full stuff instead of being stuck doing boring, running around people. So if you need rebuilds for a package or if you need your package removed from Jesse because it's not ready or things like that, leaving a note in the BTS is not enough. I mean, the report against your package. We sometimes read the Debian bugs or C mailing list, but it's not a reliable way to do this. So we have a mailing list. We have a pseudo package. So please file bugs against the release.debian.org pseudo package. So whether it's for transitions or for BNM use or for unblock requests during the freeze for proposed updates, if you want a package removed from testing, that's the way to do it. If you have any questions, you can ask on the Debian Release IRC channel. And now if you have any questions. Can we help the release team for the review process of unblocks? Absolutely. So the unblock request will be posted as bugs against release.debian.org. So if you are lurking around on that list and have a few minutes to spare on reviewing an unblock request and say, OK, I've read this diff, it makes sense to me or I've tested this new version of the package and fixed the bugs and it doesn't break anything, then yeah, by all means. And that will be very helpful as well. Is this on? Yeah. Two things. Request from the CD installer team, especially when you're doing installation reports. If you have a new machine that is UEFI, please absolutely test it in UEFI and tell us everything you find. We'll always find your edge cases. Every firmware is different. We need to know about these, please. Secondly, the UK group, I hesitate to use the word Kapol, bug I just did. The UK Kapol are going to be organizing ABSP, if not two, during the freeze. We'll be announcing that. Competition from other groups trying to close more bugs without necessarily our emming. Well done, Neil. It would be appreciated. Request, removals from testing, those still go via FTP, WNORKZU, the package? And... Or from the archive, I should say. Removals from the archive, that goes through FTP.dbn.org. Okay. Removal of a source package from testing, go through... Release. Release, yeah. Thank you. It's nice to see that you remove, well, old team members. It's nice to see that you remove packages, which are not fit for the release. So why don't you remove proactively ports, which are not fit for the release? I mean, well, I had a question for the past through Debcons, and I think the whole project is wasting a lot of time trying to maintain obsolete ports. So after the last, well, release, we had to maintain S390 spark and IA64 for multiple months. And I think everybody here could have spent time on better tasks. And I think that doesn't have to stop for, well, some architectures, which are still considered release architectures. So we did remove a couple of architectures during this cycle. As you've mentioned, IA64 and Spark, we've also looked at architecture status regularly during the cycle and told the porters and the involved people when we thought that the status was not good. But so far, we haven't had any need to actually remove more architectures. And because when we said, OK, this is not good enough, people have actually worked to improve the port status. So I mean, it might still happen. But I think we've worked better this cycle about doing these checks earlier and more regularly. I know you would like us to remove ports more proactively, but there are no more questions than, yeah. Is there any chance that ARM64 and PPC64 EL are going to be releasing Jesse? Another small chance. There's no decision yet on whether they will get in or not. Steve might be unhappy if ARM64 doesn't make it, but we'll see. Would you have the name of the testy plus one? I don't know if the release managers have made a decision yet. No, probably not. Surely, clearly, it's going to be Zerg. OK, well, thank you, everyone, and please go back to your bug fixing activities.