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