 to release matters of testing migration. So the migration to testing. So first, some basics about distribution actually suit. So packages are normally uploaded to a hand-stable. One of the exceptions is, of course, the package is not ready, it's not release quality, you should upload it to an experimenter. After some rough testing on a stable, they normally migrate to the testing. And from time to time, testing is declared stable. And that's what we call release. And, as I said, before, experimental is for packages that are not available for release quality. So we have testing from hand-stable to and migration from hand-stable to testing. And the packages are only considered after a certain amount of time. Considered doesn't mean that they will move after that time. They also have to be extended on all architectures. All release architectures. So that's ARM, AT64, MIMSAL, RPCS, S390, I386, IA64, and I'm at work at work. And at the moment, they also shouldn't have more release-critical bugs and hand-stable than in testing. We are thinking of changing that to, there shouldn't be a new R-C bug in hand-stable. And one of the things that most people don't know, which also is a factor, is that they shouldn't break packages in testing. So when does a package break? Well, if it's not installable anymore. So that can mean that there's a new conflict or that package needs a new version. So if, when the package would transition to testing and the package itself or other packages wouldn't be installable anymore, there would be no transition. Then there is also the migration from testing-proposed updates to testing. All these migrations need manual editing from the release team. So they need to prove. And they also shouldn't break any packages. So even if they are approved manually by the release team and they would break packages in testing, they wouldn't be migrating. So urgency of their float, there's no factor if you have float to trust testing-proposed updates. Only the manual approval and the installability is a factor. So also, being in sync on all release architectures is to manually check by the release team. So a little bit more about these factors. You have the urgency of your float, normally use normal, of course. So that means the package has to wait 10 days and then it's stable before it's considered. Then you have medium, so if you want to transition faster, you use medium. Then high is for packages that are only considered after 2 days. And critical for 0 days. Of course, critical is not to be used, except in really rare circumstances. Then being in sync on all release architectures, so that means they have to be built and only on build teams. But not only built, they also have to be uploaded. And even that is not enough. They have to be installed in the archive. The difference is sometimes you can upload a package and it gets rejected or it doesn't move for all that reason from incoming to the archive. So then it's not in sync. So then, as I said, it shouldn't have more RC drugs and unstable data testing, otherwise it won't migrate. So that means that at least an equal amount of close and new RC drugs. So it can be that you have a new RC drug and you close RC drug. At the moment that we've moved to testing and we are taking off changing that new and testing is no RC drug. So if a package is not in testing and it has to migrate for the first time to testing, it shouldn't have any RC drugs. And of course, it's always better to have less RC drugs and not an equal amount. So not breaking packages and testing, so it's about installability. And one of the things we sometimes see is that packages depend and conflict at the same time on another package. That is of course not installable. And some maintainers do that with meta packages to make sure that the old version is removed and the new is installed. But then you can't install the meta package from scratch. So that is not installable and your package won't. So that also means that all dependencies of the packages should be installable. And for some library transitions, if a library transitions and it has another so many things like that, then of course many packages are not installable with the new version because they can migrate to the new library version. So they should all enter at the same time. So that was in charge like what normally happens when the RISD doesn't end and packages. Of course, the RISD can decide about removing packages from testing. Then we use the removal end, of course. And we can also block packages from entering testing, even if they are already migrated or they already aren't. If some packages are blocked, like say in a freeze or because of due depth or things like that, we can unblock the package. So blocking and unblocking is only about, is actually a new factor. So the four first factors still remain the same. If it's not installed, it won't migrate even if we unblock it. Then we can always force packages into testing. So then the four factors don't count anymore. We just say it has to go to testing no matter what. Because why do we need it in the first place? Because normally there shouldn't be any problem. Well, some packages depend on each other. And if they depend on each other, then at the moment in Brittany, every package is blocked on its own to migrate to testing. So the four criteria need to be checked for each package on its own. So if a package A depends on package B, and package B is not in testing, it can't migrate. But if package B also depends on A, then B can also not migrate. So we need a hint to say they have to move together. We can allow packages that cycle and depend on each other. We can also change the urgency. Well, not really change the urgency, but we can say set age dates. And age dates, then we decide it has to be, like for instance, age dates, age. And then it has to be age dates and unstable before it can reach testing. So we can actually take any number of days. And then there are of course some issues. Like I said before, when library transitions, packages can stick together. And that's even worse if more than one library transition is going on. And packages depend on more than one library that is going to transition. And of course, if they are not built on all architectures, or if there are built-in issues or failed to build from source, but it can really be a pain to have them transition to testing. So then we sometimes force the removal of a package from testing to make sure many other packages can enter testing. And of course, if for some architecture, packages are not being built because of slow built teams or whatever, then the risk of having more and more packages to be, that more and more packages need to enter testing at the same time will be higher. So one of the strategies we use is of course to discover these things too. It's not that difficult to discover them because we have Bjorn who has a nice page to see what packages need to go in and together and why they are not moving to testing at the same time. Of course, we try to avoid these library transitions. So we really want maintainers to inform us if they have uploaded a library transition. The worst case we do with MMR use, but actually that's not the worst case anymore because there are that many uncoordinated uploads that happens a lot. And we try to coordinate with both the maintainers and FTP monsters to make it go more smoothly. So as I said, for the maintainers we really want that there are never packages uploaded into unstable that are not meant for the release. So actually that means don't install and don't upload packages that are not of release quality. Upload them to experimental but not to unstable because they interfere with library migrations that has to migrate to test. And please look at the package migration status before uploading. So that's the same reason otherwise it can interfere with migrations that are almost ready and then there are resets. So then the migration has to wait longer and of course it has to wait longer. There is a bigger high risk of other packages that are also uploaded that make it even more longer. So I do hope that people know more about testing migration and what the issues are. And yeah, he and I are already close. So one thing that I think many people like. One thing that many people seem to sometimes feel is that the FTP masters are trying to stop their packages and they're trying to push them. And I just wanted to kind of undermine this sentiment. It's obvious from your talk that there are ways for the maintainer to bypass the normal testing migration procedure by using the urgency and so forth. So would you agree with me that maintainers ought to talk to you and maybe ask for exceptions and so forth when it seems appropriate? Yes, should. Maintaining should talk to us if there aren't exceptions should. If they misuse the urgency and we see it happening before it's too late, before it's as migrated to testing. Why need packages to wait that long and unstable actually is just to make sure there is some testing of the packages. So if someone might maintainers want to circumvent that by just misusing the urgency, we will of course set the HDAs to 30 or 20 or something like that and talk to the maintainer why he did it. So it's better if the maintainer asks you for an exception than you can be reasonable. So from your talking, it's not really clear to me if been and been and knew is something that you as a release manager of life or not because in the past they used to do not like learn but when library did change in the simple case that there are just like 10 packages depending on each I can as a maintainer do so so so close for them but it could be a waste and I risk to do more mistakes in the so so close. So would like to ask for a review but it's not clear to me if that's something you would like or not? Well, in most cases we do like been and use because mostly many packages have to then rebuild and it's easier but then I use because then the urgency doesn't matter. So if the package is built it can migrate to Tesla. So that's very better for us because it's way shorter waiting time before the packages can migrate. But only of course it's only a rebuild. Sometimes the API changes there's more. And you said experimental is about packages not suitable for next release. If you have lots of packages and stable which are we have which are we have to me ask you like saying not suitable for next release. Do you think they should be rebuilt and have good experiment there or just actually with that? No, I don't think so. Because then our packages should be packages that in the maintenance opinion were suitable for release but he doesn't know about the receiver or something and now he thinks they are not suitable anymore for release. So it's only at upload time that you decide of course. If you say after it has been uploaded it's not suitable anymore for release it's stupid to remove it from unstable and upload it again. And the hook tracking system it should be clear that the package should not be dependent on because there is not suitable for release. One of the issues I've come across in trying to get some of my packages in some of the libraries that I maintain migrating from getting to testing is the buildings. And some of let me call them more esoteric architectures trying to work out who to keep to get another build in for his schedule is a bit of a blackout that's not documented very well. So I maintain the libraries I maintain packages I have access to certain architectures but I don't have access to all the architectures and I find it really difficult to try and work out how do I get a rebuild rescheduled on one of these esoteric architectures. Yeah so well it wasn't really meant to be but at the moment also for rebuilds like kit bags and retries on the buildings you can mail the release team because Foreman also takes care of one of them. But of course he will only use these things if the package is not built for a long time or something like that. It's not like to be misused because sometimes there are just issues with the build team that will be solved by the build team maintainer after some days or some time. Which brings me actually to something that maintenance also should do is like look more often why your package doesn't migrate and because sometimes maintenance don't know that their package failed to build and they don't know that it's just enough to ask for a rebuild or that there is a bug in the package. A couple of years ago I had the great excuses and I don't know what to do and doing that and I guess it's not very much mail to the house and it helps very much with this. So no more questions? Maybe some remarks? No? Okay you can always reach me directly and personally or by email or of course that's how you get to the release team.