#206: Update bodhi to enforce Package Update Acceptance policy
------------------------+--------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component: production | Resolution:
Keywords: | Blocked By:
Blocking: |
------------------------+--------------------------------------------------
Comment (by kparal):
Replying to [comment:5 tflink]:
> 1. Depcheck needs to be re-written.
Another option would be to have a whitelist of failures that are
ignored. I'm not sure that's the best idea, but it would solve the
biggest
problem that you brought up.
Another thought would be to re-think depcheck. I haven't had the chance
to try it out yet due to slight incompatibility with Fedora but EDOS
(currently used by debian) is an interesting and very different approach
to what we're trying to do with depcheck. [
http://arxiv.org/abs/0811.3620
A paper describing the process is available here]
Any time I read "Installability is an NP-complete problem" I wonder
whether I'm the best person to deal with it. I'd much rather convince more
knowledgeable people (yum/rpm people) to write this test for us.
> 4. I think deeper integration of Bodhi and our ResultsDB is
required.
As we were discussing a long time ago, in order to produce trustworthy
results we need to operate on package sets, not individual packages. We
can say "if you push this set of packages to stable, it won't break". If
one of those packages is unpushed, the whole set must be invalidated and
new results must be computed. We can't really achieve that just with Bodhi
comments. It needs development on our side and on Bodhi side. Releng team
must then push just the package set as indicated by Bodhi, nothing more,
nothing less.
I'm not quite sure I follow you on this one. Yeah, it would be great to
have better integration between ResultsDB and Bodhi but I'm not sure
it's
a requirement to start enforcing the update plan. We probably need better
integration between AutoQA as a whole and Bodhi but I'm not sure how
ResultsDB fits in to making sure that an update is re-tested after
modification.
I might have over-complicated that one, I'm not sure now. I supposed that
sometimes it could be necessary for Bodhi to ask ResultsDB about the very
current results, instead of relying on AutoQA-provided comments (that
might go obsolete after some package is unpushed/edited). It might be the
case, it might not. I'd have to think more about it.
> Our solution would be currently half-baked at best. Our
dependency
checking is not good enough, and our upgradepath checking is good enough,
but misses the infrastructure to make updates pushing reliable.
Well, when do we think that AutoQA would be good enough to start
enforcing? I realize that there isn't a good answer to that question -
I'm
more wondering if we should try to come up with a better answer instead of
just "real soon now".
I believe that depends on the priority we give it. How important is for us
to go to enforcing mode? Can we gain more by having informational results
for now (that might not be as perfect as in enforcing mode) and spend our
time elsewhere? That kind of questions.
--
Ticket URL: <
https://fedorahosted.org/autoqa/ticket/206#comment:7>
AutoQA <
http://autoqa.fedorahosted.org>
Automated QA project