[CentOS-devel] Why not a fusion between CentOS and SL?

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.