Debian calls the latest released version stable; apart from that there are two unreleased branches: unstable where day-to-day development takes place, and testing which is the staging area for the next release. Each version also has a code name dubbed after characters from the movie [Toy Story]?. Currently (September 2001) 2.2 ("potato") is stable, "woody" is in testing. Unstable is always named "sid". |
Debian calls the latest released version stable; apart from that there are two unreleased branches: unstable where day-to-day development takes place, and testing which is the staging area for the next release. Each version also has a code name dubbed after characters from the movie [Toy Story]?. Currently (November 2001) 2.2 ("potato") is stable, "woody" is in testing. Unstable is always named "sid". |
There have also been derivative Linux distributions based on Debian from Stormix?, Corel?, and Progeny. |
There have also been derivative Linux distributions based on Debian from Stormix?, Corel?, and Progeny. |
Debian is also the name of the group of volunteers who mantain, package and distribute the Debian system. The Debian project is supported by donations provided through [Software in the Public Interest]? (http://www.spi-inc.org/), a non-profit organization. |
Debian is also the name of the group of volunteers who maintain, package and distribute the Debian system. The Debian project is supported by donations provided through [Software in the Public Interest]? (http://www.spi-inc.org/), a non-profit organization. |
Debian package life cycleEach Debian package has a maintainer (typically, only one, but occasionally small teams of developers supervise particularly complex pieces of software). It is the maintainer's responsibilty to keep pace with the releases of officially-authored versions of the software (called "upstream"), if any exists, ensure the portability of the package to the machine architectures that Debian supports, to ensure that the package is compliant with Debian technical policy, to fix defects in the package reported by its users (who may include other Debian developers), and author enhancements to the package which make it easier to use, more configurable, more secure, and so forth. Periodically, a package maintainer makes a release of a package by uploading it to the "incoming" directory of the Debian package archive (or an "upload queue" which periodically batch-transmits packages to the incoming directory). At intervals (presently once per day), the incoming directory is scanned by an automated process which ensures that the upload is well-formed (all the requisite files are in place) and that the package bears the digital signature -- produced with OpenPGP?-compatible software -- of a Debian developer. All Debian developers have public keys. Packages are signed for two reasons; 1) to permit unsigned packages, which may have uploaded by hostile outsiders to the project, to be flagged and not processed further; and 2) to permit accountability in the event that a package contains a serious bug, a violation of policy, or malicious code. If the package in incoming is found to be validly signed and well-formed, it is installed into the archive into an area called the "pool". Initially, all package uploads accepted into the archive are only available in the "unstable" suite of packages, which contains the most up-to-date version of each package. However, new code is also untried code, so packages are held in this development/QA area for several days (the exact duration depends on the "urgency" of the upload. To pass from the development/QA area to the "testing" suite -- that is, the group of packages which are candidates for the next release of the Debian distribution -- a package must meet several critera: * it must have been in the QA area for the appropriate length of time; * t must have no "release-critical" bugs filed against it (bugs so serious that they make it unsuitable for release); * it must be compiled for all architectures slated to release; * it must be a package for an architecture that is slated to release (in other words, packages for non-releasing architectures exist only in the development/QA suite, not the release-candidate suite) * it must not depend on versions of any packages which do not meet the above conditions Thus, as you might expect, a release-critical bug in a package on which many packages depend, such as a shared library, may prevent many packages from entering the testing area, because that library is considered deficient. Periodically, the Release Manager, a delegate of the Debian Project Leader (see below), in accordance with guidelines announced to the developers months in advance, decides to make a release. This occurs when all important software is reasonably up-to-date in the release-candidate suite for all architectures for which a release is planned, and when any other goals set by the Release Manager have been met. At that time, all packages in the release-candidate suite become part of the "released" suite. It is possible for a package -- particularly an old, stable, and seldom-updated one -- to belong to more than one suite at the same time. The suites are simply collections of pointers into the package "pool" mentioned above. Project OrganizationThe Debian Project is a volunteer organization with three foundational documents: * [The Debian Social Contract] which defines set of basic principles by which the members conduct themselves; * [The Debian Free Software Guidelines], which clarify what is meant by the term "free software", prominently featured in the Social Contract; * [The Debian Constitution], which describes the organizational structure for formal decision-making within the Project, ande numerates the powers and responsibilies of the Debian Project Leader, the Debian Project Secretary, and the Debian Developers generally. The Debian Developers elect a Project Leader from within their ranks once per year. The Debian Project Leader has several special powers, but his power is not absolute. He can be recalled, or a decision reversed, by a vote of the developers under the General Resolution process. In practice, this is seldom done. (It has been over a year as of this writing since a vote was conducted under the General Resolution procedures, with the exception of the election ballot for Debian Project Leader, which must be held every year.) The Debian Project Leader is empowered to delegate his authority, and several developers are entrusted with special responsibilites as delegates of the Project Leader, such the Debian System Administration team (who possess the root password to the Project's machines), and the Release Manager, who sets goals for the distribution's release, supervises the process, and makes the final decision as to when to release. Many delegates remain in their positions through multiple terms of the Project Leader; the most important positions are held by long-standing and well-trusted members of the Project, and there is little turnover in delegates even when the Project Leader changes. A list of many important positions in the Debian Project is available at [Debian organisation]. Many, but not all, of these positions are delegated by the Project Leader. Developer Recruitment, Motivation, and ResignationThe Debian Project has a steady influx of applicants wishing to become Developers. These applicants must undergo an elaborate vetting process which establishes their identity, motivation, understanding of the Project's goals (embodied in the Social Contract), and technical competence. More information on the "New Maintainer" process is available at [Debian New Maintainer]. Debian Developers join the Project for any number of reasons; some that have been cited in the past include: * a desire to contribute back to the Free Software community (practically all applicants are users of Free Software); * a desire to see some specific software task accomplished (some view the Debian user community as a valuable testing or proving ground for new software); * a desire to make, or keep, Free Software competitive with proprietary alternatives; * a desire to work closely with people that share some of their aptitudes, interests, and goals (there is a very strong sense of community within the Debian Project which some applicants do not experience in their paid jobs); * a simple enjoyment of the iterative process of software development and maintenance (some developers have a nearly obsessive level of dedication to refinement and enhancement of software). Debian Developers may resign their positions at any time by sending notice to the Project membership (or just the Debian System Administrators, if they wish to be discreet). Their accounts are deleted and their cryptographic keys removed from the Project's keyring (which enables package uploads signed by them to be accepted into the archive, see above). |
Debian is well-known for its [package management system]?, apt, which allows a relatively painless upgrade from really old versions of Debian and nearly effortless installs of new packages.
Debian calls the latest released version stable; apart from that there are two unreleased branches: unstable where day-to-day development takes place, and testing which is the staging area for the next release. Each version also has a code name dubbed after characters from the movie [Toy Story]?. Currently (November 2001) 2.2 ("potato") is stable, "woody" is in testing. Unstable is always named "sid".
There have also been derivative Linux distributions based on Debian from Stormix?, Corel?, and Progeny.
Debian is also the name of the group of volunteers who maintain, package and distribute the Debian system. The Debian project is supported by donations provided through [Software in the Public Interest]? (http://www.spi-inc.org/), a non-profit organization.
The name Debian comes from the names of its founder, Ian Murdock, and his wife, Debra. The word "Debian" is thus pronounced as the corresponding syllables of these names are in American English.
Each Debian package has a maintainer (typically, only one, but occasionally small teams of developers supervise particularly complex pieces of software). It is the maintainer's responsibilty to keep pace with the releases of officially-authored versions of the software (called "upstream"), if any exists, ensure the portability of the package to the machine architectures that Debian supports, to ensure that the package is compliant with Debian technical policy, to fix defects in the package reported by its users (who may include other Debian developers), and author enhancements to the package which make it easier to use, more configurable, more secure, and so forth.
Periodically, a package maintainer makes a release of a package by uploading it to the "incoming" directory of the Debian package archive (or an "upload queue" which periodically batch-transmits packages to the incoming directory). At intervals (presently once per day), the incoming directory is scanned by an automated process which ensures that the upload is well-formed (all the requisite files are in place) and that the package bears the digital signature -- produced with OpenPGP?-compatible software -- of a Debian developer. All Debian developers have public keys. Packages are signed for two reasons; 1) to permit unsigned packages, which may have uploaded by hostile outsiders to the project, to be flagged and not processed further; and 2) to permit accountability in the event that a package contains a serious bug, a violation of policy, or malicious code.
If the package in incoming is found to be validly signed and well-formed, it is installed into the archive into an area called the "pool". Initially, all package uploads accepted into the archive are only available in the "unstable" suite of packages, which contains the most up-to-date version of each package. However, new code is also untried code, so packages are held in this development/QA area for several days (the exact duration depends on the "urgency" of the upload.
To pass from the development/QA area to the "testing" suite -- that is, the group of packages which are candidates for the next release of the Debian distribution -- a package must meet several critera:
Thus, as you might expect, a release-critical bug in a package on which many packages depend, such as a shared library, may prevent many packages from entering the testing area, because that library is considered deficient.
Periodically, the Release Manager, a delegate of the Debian Project Leader (see below), in accordance with guidelines announced to the developers months in advance, decides to make a release. This occurs when all important software is reasonably up-to-date in the release-candidate suite for all architectures for which a release is planned, and when any other goals set by the Release Manager have been met. At that time, all packages in the release-candidate suite become part of the "released" suite.
It is possible for a package -- particularly an old, stable, and seldom-updated one -- to belong to more than one suite at the same time. The suites are simply collections of pointers into the package "pool" mentioned above.
The Debian Project is a volunteer organization with three foundational documents:
The Debian Developers elect a Project Leader from within their ranks once per year. The Debian Project Leader has several special powers, but his power is not absolute. He can be recalled, or a decision reversed, by a vote of the developers under the General Resolution process. In practice, this is seldom done. (It has been over a year as of this writing since a vote was conducted under the General Resolution procedures, with the exception of the election ballot for Debian Project Leader, which must be held every year.)
The Debian Project Leader is empowered to delegate his authority, and several developers are entrusted with special responsibilites as delegates of the Project Leader, such the Debian System Administration team (who possess the root password to the Project's machines), and the Release Manager, who sets goals for the distribution's release, supervises the process, and makes the final decision as to when to release. Many delegates remain in their positions through multiple terms of the Project Leader; the most important positions are held by long-standing and well-trusted members of the Project, and there is little turnover in delegates even when the Project Leader changes.
A list of many important positions in the Debian Project is available at [Debian organisation]. Many, but not all, of these positions are delegated by the Project Leader.
The Debian Project has a steady influx of applicants wishing to become Developers. These applicants must undergo an elaborate vetting process which establishes their identity, motivation, understanding of the Project's goals (embodied in the Social Contract), and technical competence. More information on the "New Maintainer" process is available at [Debian New Maintainer].
Debian Developers join the Project for any number of reasons; some that have been cited in the past include:
Debian Developers may resign their positions at any time by sending notice to the Project membership (or just the Debian System Administrators, if they wish to be discreet). Their accounts are deleted and their cryptographic keys removed from the Project's keyring (which enables package uploads signed by them to be accepted into the archive, see above).