On 05/06/2011 03:01 PM, Johnny Hughes wrote:
On 05/06/2011 02:47 PM, Mike Doroshenko wrote:
On 05/06/2011 12:49 AM, Bill McGonigle wrote:
target-1) tree's to QA
What does /target-1) tree's to QA/ mean? I know QA stands for Quality Assurance, but /tree's to Quality Assurance/ still doesn't make sense to me.
If you look on mirror.centos.org, what we consider a "Tree" is the 5.6 directory or the 4.8 directory.
In this particular case, we are saying that we will get all the RPMs (built) in the 6.0 to QA to look at.
They will be installable as RPMs from the directory (ie, like the updates directory).
We may have network installable boot images at that point, but we will not have a full set of installable / bootable ISOs.
Once we run several sets of tests in QA with many kinds of installs (or updating over other installs for other than the .0 releases) and once we fix issues found with these RPMS, then we will generate the actual install ISOs and test those.
Some of the tests that we run in this stage (where we have all the RPMs, but not necessarily an installable distro) is:
1. All the RPMs seemed to install properly on a running system.
2. That the dynamic libraries linked by all the libraries/binaries are the same as upstream.
3. That the file list of every RPM we produced is identical to the file list of every RPM from upstream.
4. That the trees contain the correct versions of all files (the same ones on the .0 isos from upstream). We want to make sure the updates go into the updates directory.
5. That the comps.xml (compilation) file has the correct groups in it. Upstream has several different versions of their codebase that they sell for different amounts ... ie: a. Server b. Workstation c. Desktop
CentOS has no need for the segregation, our product is free and contains all the packages (and yum install groups, etc.) from all of those combined.
We also remove several packages (all the RHN items, for example, since CentOS is not allowed to update from RHN, etc.)
This requires us to take the applicable portions of several comps files and build a combined comps file that allows you to install Servers, Desktops, Workstations, etc.
6. In the case of 6.0 specifically, there is an "optional" channel that contains many of the -devel (development) files needed to build things. We also have no need for that, but we need to get the items in that channel integrated into our distribution and comps files.
Once we get all of these things done and tested, then we can generate a set of real ISOs and test the install groups, etc.