introduces some new terminology because its scope is much larger than any community project Red Hat has been involved in before. In addition, Red Hat's official terminology is different for than for our supported products, in order to make some of the distinctions we make more obvious and clear.
The distribution: the package set that is included on the set of ISO images and directory tree blessed by the steering committee and released as . The steering committee sets policies for , and provides the infrastructure to build it.
To distinguish Red Hat Enterprise Linux's formal beta program from the community-based testing of , we will use the term "test" release instead of "beta" release to refer to test releases. There is no attempt to request that Red Hat's business partners (hardware or software) test test or final releases.
To distinguish Red Hat Enterprise Linux's formal support offerings from the community-based updates to , we will use the word "updates" rather than "errata" when referring to newer packages released to fix security holes, fix functionality bugs, and add new, additional functionality relative to a release of . (Please keep in mind that is not a supported product of Red Hat.) These updates will be available as part of for two to three months after the release of the next version of ; that is; updates for 1 will be provided for two to three months after the release of 2, and so forth.
are sets of packages that augment but do not replace component packages. These packages, like all packages that are part of , must conform to the legal requirements of the project and conform to the policies.
"" is a category that applies to multiple repositories. For example, someone might wish to build a set of packages for high performance computing use and call it " HPC"; it would be one of the .
Packages in must be built entirely from software meeting the open source guidelines; furthermore, packages in must be buildable only using software which is in or . need to be kept roughly up to date with releases and must be signed with the package's key rather than the Fedora key. Packages in are expected to release updates to fix security issues.
Red Hat will provide build systems, CVS repositories, ftp and web services, and possibly other facilities needed by the packages.
Packages in should avoid conflicts with other packages in to the fullest extent possible. Packages in must not conflict with packages in . It is possible to have many packages under the umbrella of a single project.
The technical committee is responsible for accepting packages into based on the technical merits of the package and the proposed package's maintainer.
"" refers to package fixes submitted for old versions of core packages or old releases (releases that have been superceded by a newer release more than 2-3 months before) of by people on an adhoc basis.
Packages in are controlled by their respective package maintainers and are subject to the acceptable use policies of the project. Packages in can be maintained by anyone who agrees to the project's policies and procedures. The steering committee can be asked to provide guidance, but has no power to remove legacy packages or material within legacy packages. However, legal issues or not following project guidelines may cause packages to lose their "" status.
Packages in must be built entirely from software meeting the open source guidelines and must be signed with the package's key rather than the Fedora key.
Red Hat will provide mailing lists and possibly other facilities needed by the packages.
"Third Party" refers to packages which are not in any of the previously mentioned categories (, , , or ).
Red Hat will not be providing any facilities for these projects and we take no responsibility for the content of third party packages. Third party packages may include virtually anything, including software that is not open source.
displayFooter('$Date: 2005/03/30 17:47:23 $'); ?>