moving to final place
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|||<tablestyle="width: 100%;">~-[:DebianWiki/EditorGuide#translation:Translation(s)]: none-~||<style="text-align: left;">This text is not meant for broad publishing. Please do not modify the footnote formating.||<style="text-align: right;"> (!) [:/Discussion:Discussion]||||||<tablestyle="width: 100%;">~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~||<style="text-align: left;">This text is not meant for broad publishing. Please do not modify the footnote formating.||<style="text-align: right;"> (!) [[/Discussion|Discussion]]|||
This text is not meant for broad publishing. Please do not modify the footnote formating.
Debian 5.0 Lenny release date
The Release Team  has frozen the Testing repository; the focus is now on squashing bugs. At this point, package versions with new functionality or APIs will only be included after careful evaluation.
The bug cleanup effort of all 24 thousand packages can be followed at the dynamic page .
An open invitation to the community to help test and debug Lenny was published  and a new Bug Sprint is scheduled at the end of October  to accelerate the effort.
Eventually, the Release Team, in collaboration with the QA Team , may opt for removing some packages for the release.
The release will happen when the Release Team reaches the conclusion that the distribution is stable, with a minimal number of known significant bugs.
What guarantee is there that high-end hardware (SAN, blades, etc) will work flawlessly with Lenny? Are there regression tests?
The Debian distribution tries not to deviate from upstream kernel for such hardware. Regression tests are performed by the driver developers and/or manufacturers, generally speaking, or by hardware software testing companies, like  or contractors like .
Some sites check and/or list compatibility  or incompatibility .
The Debian Project applies its very best effort to support high-end hardware, but does not guarantee hardware compatibility.
Interaction with the Debian Kernel Team  and Debian Installer Team  via their discussion lists, providing access to hardware, and even contracting Debian Team members for performing specific tests at a defined schedule and/or requirements, are possible solutions to overcoming hardware driver problems may they arise.
The best window of opportunity for such interaction is at the start of a new release development cycle to the time when the kernel version release freezes.
However, bug reports are welcome at any time.
How can I help improve drivers for high-end hardware?
Test and report any bugs to members of the Debian Kernel Team  and the Debian Installer Team .
Provide hardware access to Debian Kernel Team  and Debian Installer Team  members.
Interact with the Teams through their mailing lists.
Contract members and contractors like  for specific, scheduled development.
Contact the upstream kernel developers regarding driver development  with information, or special arrangements like NDAs for chipset internals.
The Debian Project supports and minimally deviates from the supported drivers  in the upstream kernel.
However, since some upstream kernel versions work better with a specific hardware device than others do, feedback is essential to ensure that the kernel we release with supports your hardware specifically.
How much time does Debian take to issue a security update after notification (CVE)?
The Debian Project takes security very seriously, and its Security Team  evaluates each security bug report, CVE alert, and confidential direct contact with the Team, assessing the risk and listing the vulnerable packages  of each release and version. Depending on the severity and the availability of a suitable solution, and update can be released in as little as 75 minutes .
The Debian Project is one of the fastest Linux distributions at releasing security fixes. An example is kernel bug CVE-20008-0600  that took 6 days. The bug that made multiple DNS implementations vulnerable to cache poisoning, VU#800113 , CVE-2008-1447 , which needed a long vendor articulation , was kept confidential until all packages received fixes.
Studies about days-in-risk  exposure are uncommon for Debian, but a survey report completed in 2001  shows that 15% of fixes were released at the same day of the bug report, with an average value of 35 days. The survey, updated in 2003, shows an average value of 13.5 days-in-risk, which is significant progress in only 2 years. As the Debian Project grows more popular, this value may drop even lower.
On July 2008, an article  compared several important incidents and the days-in-risk for four Linux distributions, where one may see that Debian Project ranks among the first in dealing with security vulnerabilities. A competitive study between the detailed Red Hat report  could be done, as the CVE codes are listed, which can be mapped to the DSA codes by an on-line tool .
It is important to consider that the simple measure "days-in-risk" , without severity and vulnerability exposure analysis applied to a given installed system is not complete.
The Debian GNU/Linux distribution has an extremely powerful and flexible package management system, which allows the system administrator to easily and transparently take care of package dependencies, and configure the system to use the minimum amount of packages necessary for the task, limiting exposure to vulnerabilities.
The flexibility and power of the Debian GNU/Linux package management system gives users the ability to install not only lean server configurations, but fully operational desktop systems, workstations, and more complex systems containing any subset of the 24 thousand pre-compiled binary packages available.
The use of Debian tools like debsecan , tiger , the listed set at , rc-alert , and the security tracker , help guide the system administrator.
In order to fully benefit from Debian's vast selection of packages, excellent security, and configuration, it is important to exclusively use Debian's own management tools to configure the system.
Even the /etc configuration files manually edited should be informed to the debconf tool, this way keeping the checksum updated and auditable, and allowing controlled upgrades of these files.
Can I maintain and run older packages at new releases? Are there regression tests?
If a package has left the action scope of Debian Security Team it must be maintained by the in-house sysadmins.
The sysadmin group will need to create a security fix backport from the current stable version to the version it intends to keep running.
Then, the adapted older Debian source package needs to be rebuilt at the current stable distribution release, adapting the library dependencies, helpers and toolchain.
The use of the newer toolchain, debhelpers from build-essential  and updated libraries, will provide some degree of compatibility with the new release.
Notoriously, the development tools lintian , debcheck , piuparts , *help* at identifying conflicts, problems, and non-adherence to Debian Policy in the new environment.
The tools log files must be analyzed, and errors and warnings must be solved carefully.
These tools verify that older Debian source packages have an increased likelihood of divergences and non-compliance with Debian Policy.
In this situation, it may be beneficial to the adaptation porting effort to use the current debian package version for guidance.
As examples, non-compliance with FHS  or system runlevels init.d script policy  are common.
All these Debian resources and tools aim to verify release integrity and consistency of a release, but do not guarantee complete application functionality, which should have its own regression tests available to the packager and sysadmin.