> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
