Dear all, TL;DR: please give your constructive feedback on the buster release period, see the last paragraph. As the most recent member of the release team [1], I thought it could be a useful exercise to reflect on the release process and share it with you. As such a reflection goes, it should start with the good things. We've announced the freeze timeline well in advance, like the previous release. Most people seem to have been aware (however, more on that below). Although it may not be visible to most, this release cycle has seen much code improvements of the migration software (britney). One of those improvement has been the integration of autopkgtest results. Even with some minor issues still open, the introduction of that has been a success. For the lesser things, let's start with the most striking observation: freezing Debian sucks. One of the unintended results is a major slow down of activity for most Debian developers, while at the same time it creates a lot of busy work for the release team in the form of unblock requests. However, seeing how much last minute changes were uploaded around every deadline, with a significant portion not release quality, I also think that freezing is needed to be able to release quality. In my opinion, we all should work harder to shorten the time after the full freeze, it doesn't need to be so long. Apparently our biggest challenge is communication. The following points mostly boil down to it. One of the things that struck me most is that it seems that a significant portion of our community isn't aware of the freeze, doesn't know the (high level content of the) freeze policy or doesn't care about releasing. Some uploads to unstable during the freeze were disturbing. This was mostly because they caused (build-)depending packages to be blocked while those needed to go into buster. This was because their changes weren't in line with the freeze policy, so they couldn't be unblocked. This required unnecessary extra work to get these depending packages into buster via testing-proposed-updates, which we want to avoid as much as possible due to its drawbacks. We aren't so good in handling unblock requests that are not in line with the freeze policy and require much review work to see if an exception is appropriate. They typically linger without reply in the hope that somebody else takes care of it. We got quite a few unblock request that weren't really appropriate but it's hard to turn people down. And people try, I understand that, but it doesn't make the process nicer for both sides of the bug. On top of that, investigating such cases means that time is taken away from cases that are fully freeze policy compliant, so those will have a delayed response. That isn't a good experience for maintainers that do follow the rules of the freeze policy. Only very late in the release we realized that the golang situation was so bad that it needed a resolution before the release. Although the situation isn't pretty for stable release managers, it's worse for the security archive. It took a while before the release team, the security team and the golang community in Debian where enough aligned. The situation is not OK now (no security support), but we agreed to release buster with the golang ecosystem with the understanding that the situation needs to be fixed early in the bullseye cycle by those involved, or it will be removed from testing. The issues above caused the freeze to take longer than it should have IMHO. So, now you've seen how I have perceived the freeze, do you have anything to add? We're looking for concrete notes and observations that we can use when we think about how to improve the bullseye release. We are currently not looking for ideas that overhaul the process (there is https://wiki.debian.org/ReleaseProposals for that). We also like to prevent big discussions on d-d@l.d.o (as we fear they will drain to much of our energy), so I've set the reply-to of this mail to the release team's e-mail list. All constructive feedback and feedforward is welcome; short ones are preferred. Paul [1] A note on that: the release team needs help. If you want to help, consider joining.
Attachment:
signature.asc
Description: OpenPGP digital signature