On Tue, Oct 4, 2016 at 11:59 AM, Josh Berkus <jberkus@xxxxxxxxxx> wrote: > On 10/04/2016 08:13 AM, Colin Walters wrote: >> >> On Tue, Oct 4, 2016, at 09:46 AM, Paul W. Frields wrote: >>> > >>> > I think mattdm would agree we don't want to potentially, >>> > *indefinitely* block a six-month release with a deliverable that can >>> > be fixed and re-released in two weeks. >> It's not that simple - this is a messy topic. What I think this >> is about isn't delaying or blocking - it's *prioritization*. If >> an issue comes up in Anaconda or systemd or whatever >> that affects the "next AH", we need those teams to priortize >> those fixes the same as they do for Workstation or Server. > > Yes, this is exactly the problem I'm raising. We've had an issue with > F25-base Atomic not booting for a couple weeks now, and until the last > couple of days, nobody has been working on it. It seems to be a simple > fact of the Fedora release cycle that if something isn't > release-blocking, it doesn't get done. This isn't new, it's an issue > which has plagued Fedora Atomic for, as far as I can tell, its entire > existence. Perhaps in some cases, but it's not always true. Spins get done even though they're not release blocking. The issue with release blocking status is it compels the expert in the particular area of failure to become involved. And that is a limited resource. Possibly a big part of the reason for Atomic failures is there's a lack of documentation across the board, both ostree stuff as well as releng's processes, and then when ostree failures happen the logs are often lacking in such detail that a Tarot card reader might have a better chance of guessing what's going on than the logs indicate. This makes it difficult to get contributors involved. And makes it damn near impossible any of them would want to become even intermediately competent - it's a heavy investment. -- Chris Murphy _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
