On Tue, Jul 4, 2017 at 6:41 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On 07/04/2017 03:46 PM, Adam Williamson wrote: >> On Tue, 2017-07-04 at 09:32 +0200, Christian Dersch wrote: >>> Looks like one compose failed *again* for some mirror issue… This time >>> it is Robotic [1] , but i've seen these random failures several times, >>> also for Astronomy for example. So a new compose should be done here to >>> ensure the Spin gets in properly, >> >> We don't re-spin for non-blocking images as a matter of course. The >> compose process takes far too long for that, unfortunately. >> >> I think nirik said he thought he'd fixed this, but obviously he >> hasn't... > > Yeah, I keep doing things that I think will quash this and then it shows > up again. :( It has been very hard to track down because it's going > through a number of layers... apache to haproxy to varnish to apache. :( > >> Note this only seems to have affected the i386 image. The x86_64 image >> is included in the compose.
So... this prompts a question in my head. I understand we don't block release for non-blocking spins. That is obvious. What is not obvious to me is if we would go back and do a compose later for those spins that are impacted by this. It is one thing to skip a spin if the maintainer has not kept up with the release and is otherwise negligent. It is quite another to tell them "too bad..." if the spin isn't composed for something completely out of their control such as an infrastructure issue. That, to me, would be discounting the work they've done throughout the release to maintain and test their spin. Do we have that ability to do a post-GA compose for those spins in such cases and do we plan to do so? josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
