On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote: > I'll attempt to give a brief summary here. First you need to understand > that there are three states for a package that has been built with the > hope of being pushed as an update: > * 'candidate': freshly-built packages intended for updates > * 'proposed': bodhi request filed, but not pushed live > * 'live': packages that have been pushed live by rel-eng I first thought that live == stable and proposed = "in testing with request for stable" and candidate = "pending, not in tested, not requested to become testing"? But this does not match the remainder of this e-mail. > So. What we want to do in AutoQA is trigger a test to check dependencies > *before* the package goes live. So we trigger our test when the request > is filed (this is the 'post-bodhi-update' hook in AutoQA, which was > merged a week or two back). > > It should be obvious that the goal of the test is to examine the > proposed updates and hold back the ones whose dependencies are > inconsistent with the packages in the live repos[1]. To phrase it > slightly differently: we want to look at the set of 'proposed' updates > and pass the packages whose dependencies *are* consistent with the live > repos. > Once we're satisfied that depcheck does the right thing, we will > probably set it up to start adding automatic +1 karma from 'autoqa' when > updates pass the automated test suite (depcheck and possibly other tests > - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will > apply to all packages or just critpath packages; it may apply > everywhere, which will make it a bit easier to get to +3 karma for > automated updates. If I interpret the terms live, proposed and candidate as above, the +1 karma will not have any effect on autokarma, because the check is only run after there is a request to push the updates to stable and autokarma does not matter anymore. But if live == testing and proposed == "pending with request to testing", there might still dep breakage happend when not all dependent updates are pushed to stable. Therefore it seems the test needs to run twice, once to avoid breakage in testing and once to avoid breakage in stable. Is this intended or do I miss something? Regards Till
Attachment:
pgpcC6SWtyfrU.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
