On Fri, Oct 26, 2018 at 4:43 AM, Christian Dersch
<lupinix.fedora(a)gmail.com> wrote:
I understand the complaint in isolation, but in relation to the
existing processes and release criteria I do not follow. What solution
do you propose?
Right now release criteria explicitly does not block the release even
if all the spins (as they are not release blocking images) fail to
compose. A criterion that says if three or more spins fail to compose,
we block on? Well what if it's only Astronomy? Or what if it's just
our top two most popular spins? It's really not that granular, and
it's also not fair. And as a consequence, blocking means another
compose must be ordered up, which replaces all the images even the
ones that previously tested good. And the compose process has just
enough non-determinism in it, that we have to do sanity testing on all
the images. It's easily a dozen man hours.
There needs to be a recruitment drive to get releng the resources it
needs to decouple the compose outputs.
I haven't looked, but was the RC the first failure for these spins?
Were they succeeding as nightlies and just failed suddenly as RC?
There might be a valid way to carve up a release criterion that says
if there's an RC specific failure to output images that didn't cause
nightlies to fail, then we have to find out what's going on. Something
that acknowledges, hey pretty much all the nightlies had working spins
but then suddenly the RC blew things up, why?
In case of Astronomy all nightlies built fine, the RC one has been canceled for some
reason for x86_64, even the i686 one went fine. The other spins seem to be failing for at
least some days also in nightly. So IMHO two different cases (of couse with same result),
in case of Astronomy the compose itself has an issue, for the other spins there are
dependency issues as it seems.
Having that criterion " if there's an RC specific failure to output images that
didn't cause nightlies to fail, then we have to find out what's going on."
would be really nice.
Greetings,
Christian