[CentOS-devel] Why not a fusion between CentOS and SL?
Karanbir Singh
mail-lists at karan.org
Thu Mar 24 20:44:43 UTC 2011
On 03/24/2011 08:23 PM, Lamar Owen wrote:
> If I may ask a CentOS QA process question, then, is what is the QA on making sure that the package that gets pushed to -testing and then to -updates is the latest build of a particular EVR tuple? Just curious, since buildtime seems a reasonable thing to use for that sort of thing. Or, for that matter, that the QA feedback is for the correct build of a particular EVR for a package?
There are three things here that are important :
1) the QA team guys are very wired up to this process - and are very
aware of the fact that packages will change with no EVR change; they are
also aware of the fact that the testing that were doing is from <whats
out there now> => <what we want to put out there > ( as opposed to <what
we tested yesterday> => < what we want to test today> )
2) We only ever sign packages once they are accepted; and only signed
packages are pushed publicly
3) Every package build ( so srpm -> binary rpm conversion ) runs with a
uniq build-tag; the buildtag has no relation to package name-E:VR.arch
or anything like that. Its a purely generated ID. So its still possible
to go back and get stats, logs etc for every build that we did.
irrespective of what we did ( eg: there are lots of things that were
exclusive arch: s390 :D )
None of that probably answers your question. So here is how the 'move to
repo happens'. By hand :) or the system is smart enough to replace all
binary rpms with newer builds if the srpm metadata is the same. So you
can ever only have one <name>.<arch> in the os/repo as output from one
srpm; and their buildid needs to match ( which will handle corner cases
like a subpackage going away etc ); for updates/<arch>/repo there can
only be one name-E:VR.arch from one source rpm; and since the test is
only run when a new set of binaries are output, the latest will always
win[1]
- KB
[1]: this is not always true or the desired result, and needs manual
intervention.
More information about the CentOS-devel
mailing list