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.