I want, with this mail, to start a campaign on improving Debian reliability.
Policy on improving stable release are, in my humble opinion, too restrictive and don't give the opportunity to improve Debian quality out of security fix. I think that as release cycle is very long we have to accept fix on all bugs in Stable. I know of two reasons why we are not doing this: The first one is that when we are working on Stable, we are not working on Unstable/Testing and this way we make the release cycle longer. Of course I don't agree, as unfortunately few of us do work on Release Critical Bugs of other packages and even fewer can work on debian-installer. As they are the most critical issues we need to solve for a new release, improving stable will not slow so much Sarge release. The second reason is that it may result more damage than improvement from changing something in Stable. Saying it like this is right, as many things may happen, but by using a good process we may reduce the risk. In the other hand being to much restrictive on improving Stable means that we don't trust ourselves and that there is no alternative between no change at all and being out off control. Can we continue to tell Debian users "thanks for reporting bug on Woody but even if this bug is annoying and fixable it will never be fixed before the next stable release" ? Can we continue to say that the bug is fix in Unstable/Testing but of course theses distribution are known to be less stable than Stable so use it with care ? You also know that back porting package from Unstable becomes harder when Unstable progresses. We also need some collaboration from the BTS and katie/dinstall, to not get a bug closed when a fixed version is uploaded into Unstable, but only marked as being fixed there, so that users can know the bug has already been reported and does impact Stable. Having open bugs on Woody also gives me some bad feelings, as some users trust us to provide them a quality product, but from the moment we switch into deep freeze state only critical or security fixes can be done, so we can roughly say that quality is also freeze. The only help we can provide to users is ad-hoc help, or in other words, maintain unofficial packages. This can now be done by using Alioth, but this stays unofficial and for that to work the user has to trust maintainer instead of trusting the Debian group, and this is weaker. I think we shouldn't provide a new release for this as it will be very hard for most of us to maintain up to 3 releases (Stable, Frozen and Unstable) so fixes on stable should stay in proposed-updates and then migrate smoothly into Stable if they are not known to cause more trouble than improvement. Reliability growth has a meaning only if we stay in feature freeze, so we should not change anything about "no new feature" policy. The next, harder thing to do is to find a way to deal with regressions and their consequences. Maybe we will have to look how deep the changed packages are in the dependency tree. We may also let maintainers quantify the confidence they have on their fixes. I other words, we will have to think about impact analysis. But whatever we choose, staying so rigid on Stable is more and more difficult to justify, so we need to think on how to change this. Regards, Rémi Perrot
