On Fri, Oct 26, 2018 at 4:43 AM, Christian Dersch <lupinix.fedora@xxxxxxxxx> wrote: > On 25/10/2018 20:58, Ben Cotton wrote: >> >> The Fedora 29 Final RC1.2 compose [1] is GO and will to be shipped >> live on Tuesday, October 30, 2018. >> >> For more information please check the Go/No-Go meeting minutes [2] or logs >> [3]. >> >> Thank you to everyone who has worked on this release. >> >> [1] http://dl.fedoraproject.org/pub/alt/stage/29_RC-1.2/ >> [2] >> https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-25/f29-final-go_no_go-meeting.2018-10-25-17.03.html >> [3] >> https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-25/f29-final-go_no_go-meeting.2018-10-25-17.03.log.html >> > > Is there any reason why > https://koji.fedoraproject.org/koji/taskinfo?taskID=30445005 has been > canceled? I don't see any obvious reason in the logs and I really want the > Astronomy Spin to be shipped… Normally that spin builds fine, see latest > daily build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30453015 > > In addition I want to note that we have many broken spins like the Python > Classroom and Design. I'm not sure whether it is a good idea to ignore this, > also for marketing reasons :( 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? -- Chris Murphy _______________________________________________ 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
