The Continuous Release ( CR ) Repository
The continuous release ( CR ) repository makes generally available packages that will appear in the next point release of CentOS, on a testing and hotfix basis until formally released.
2. The Issue
At a point release stage, new sources have been released by the upstream vendor, but binary updates are not formally issued as complete until the ISOs are ready (e.g., here, during the 5.8 release build process ). This entails, in part building the updated RPMs with any needed patches; solving installer issues that crop up in anaconda; verification by the QA group of content; the delay while mirrors synchronize sufficiently to handle the update load; and finally formal release of a new point release.
For new major releases (i.e., the .0 point release), there is not a prior point release in the major release series which may need security issues addressed, and so no need for streaming out 6.0 series updates before 6.0 itself was formally released; however for existing installs of a given major release, some administrators may desire, after review of announced updates from the upstream vendor, updates sooner than the complete CentOS point release rebuild process formerly permitted.
3. A Resolution
System administrators who choose to opt-in to this process can access the newly built packages, as soon as they are exported from the build system. They are less comprehensively reviewed in the QA validation stage (Note: "Less comprehensively" does not mean no QA testing ... it just means less than the full release). At this stage the packages are NOT announced via the regular channels ( mailing lists, etc). The announcements take place only when the packages land in their corresponding /os or /updates repository. The binary process of production of the packages is the same as with any other packages released by CentOS, but they may not be capable of being assembled into an integrated ISO yet, for the reasons noted above.
We will try to get the most important security updates out this way while we work on packages with issues and getting the ISOs built and tested.
This "CR Repo" will likely have a few more build issues than you would see in the main CentOS trees, but it should be fully usable in almost all cases. If you are concerned about the slight increased risk of a badly built package because of the lesser QA then you can test prior to full deployment.
Other resolutions also exist, such as performing local rebuilds of the generally available SRPMs into binary RPMs, on a bespoke and one off basis to address specific CVE's. The SRPM rebuild process is documented on a general basis in this wiki.
Usage of the CR repository is entirely optional to a system administrator, and is based on their express actions to opt-in: one has to explicitly install a centos-specific package named centos-release-cr. Once installed it will provide the information needed by yum to access the packages.
The centos-release-cr rpm is now part of the Extras repository. By default, it can be installed using the command:
yum install centos-release-cr
The CR repository will be empty and ignored until packages are placed in it at point release roll-over time. It will be emptied once the new point release is complete, but you can remain with the CR repository enabled if you so choose. This will allow you to be set up to receive CR updates for the next point release roll-over cycle.
RPMs released into the centos-cr repository are announced at the centos-cr-announce list. The plan is that CR packages will also be re-announced into the main centos-announce list when the rpms are released into the next CentOS release. If you setup or use the centos-cr repository, please also subscribe to the centos-cr-announce list. Optionally, you may wish to setup a mail filter to permit identification of emails based on the List-ID in the headers, which should be of an invariant form.