AutoQA: distro congestion?

[Michael Schwendt]

On Mon, 18 Apr 2011 12:57:55 +0200, AB wrote:

> On Mon, 2011-04-18 at 04:35 -0400, Kamil Paral wrote:
> > > I built two sets of security updates for f13/f14/f15 and autoqa
> > > rejected
> > > the f13/f14 packages. It looks like autoqa is waiting for the
> > packages
> > > to be properly pushed to f<N+1> stable before green-lighting the
> > > matching package for f<N>. 
> > 
> > I suppose you're talking about upgradepath test. Yes, that's exactly
> > its behavior. 
> 
> This seems wrong to me. If I as a packager create an upgrade in bodhi,
> autoqa should consider what is present in f<N+1> not only as stable
> package but also as proposed upgrade. It should then impose a constraint
> that the upgrade for f<N> can only be pushed to stable if f<N+1> is
> pushed to stable at the same time (or obviously independently before). 
> 
> Seeing a failed upgradepath test comment at least gives me the wrong
> feeling on what is going on.

That is also going too far.

The upgradepath check ought to stay informative and should not impose any
constraints on the packagers. Consider it an early-warning system plus a
way to educate packagers. Once the packager has learned about the violated
upgradepath, it's up to the packager to decide whether to delay the
upgrade of f<N> and work on an upgrade of f<N+1> first. It should be
possible to update f<N> before f<N+1>, possibly via karma automatism or
for a security-fix that's ready for f<N> but needs a revised build for
f<N+1>. Let's not mess too much with a packager's work-flow.