Remi Perrot wrote: > 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.
If you install a Debian stable system, you are (more or less) guaranteed the system doesn't change its behaviour during its lifetime, except for security updates, corrections for severe problems and license violations. This is quite important if you want to use a system or base a project on it, but don't want to check every month if the system, after an update, still behaves as it should. Even worse, if you have to expect that the system changes, people may not install security updates since this would retroactively creep in other changes that they would not want, hence, leaving their system vulnerable to more problems than it should. >From a technical point, we don't have the infrastructure to build and largely test updates for stable as we have for unstable. Sometimes this badly affects security as well, unfortunately. (Quoted from <http://www.debian.org/security/faq#oldversion>) Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. This is especially true in case of libraries: make sure you never change the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is. This means that moving to a new upstream version is not a good solution, instead the relevant changes should be backported. Generally upstream maintainers are willing to help if needed, if not the Debian security team might be able to help. > 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. Debian stable is like a Cisco machine. You install/purchase it, you configure it, you put it into a corner and forget about it (in case for Debian except for security updates). You don't have to maintain it too actively and can concentrate on the things that are important to you or your business. > 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. Hmm. Did I read this correct as "Hey, since we can't improve the future, let's fiddle with the past."? That's quite a disturbing thought for me. This way, there's not going to be any new releases any time. Hmm, I agree, in such a case something needs to be done with stable, but only in 1-2 years. > 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. You are free to fix the problem and provide fixed packages, even if they won't end up in the stable release. If some people want to use your fixed packages, that's fine. There are backports of KDE, Snort, Apache and Samba as well. The users who would like to use them, are free to use them. They are even maintained since they are maintained by the person who maintains these packages in unstable. This is a great service to our users in addition to the regular release, for those who would like to use them. > 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 question is, if the bug is so important for you, why didn't you fix it a couple of days before? Before the deep freeze? (this is plural you, not only addressed to you, Rémi) Also acknowledging that a stable release contains bugs, is strength not weakness. The particular bug report could even contain instructions on how to fix it or how to work around it. > Reliability growth has a meaning only if we stay in feature freeze, so > we should not change anything about "no new feature" policy. Reliability also means that the behaviour doesn't change, so people can base their tools and work on it. A constantly changing target like unstable won't be able to provide this. Regards, Joey -- Have you ever noticed that "General Public Licence" contains the word "Pub"?
