On Tue, Oct 04, 2016 at 09:46:44AM -0400, Paul W. Frields wrote: > We need to be clear on the difference between considering it important > for Atomic images to be ready on release day, and being "release > blockers." The latter has a very specific meaning as Adam W can > attest. Being a deliverable is not the same as being release > blocking. This seems like a problem of vocabulary. Agreed that it's a terminology problem. Things like "catastrophic infrastructure failure and the getfedora.org website totally doesn't work" would block the release, but not, as far as I know, be a "release blocker". (Or some similar example.) This is in some ways similar to that. > 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. That's what "release blocking" > means. If it's not ready, the release doesn't go out. This was an > overwhelming point in having that two week cycle -- to give more > flexiblity vs. the standard Fedora release. > > Does this mean we shouldn't strive to have Atomic images ready > day-and-date on GA? No. We missed this narrowly in F24, as I recall, > and we should avoid repeating that, if at all possible. But let's not > undermine a major dimension of the two-week release by confusing the > release-blocker definition. As we get into the Grand World of Modularity, there's going to be more and more stuff like this. If the base runtime is updating on a one month cycle, and GNOME updating whenever the upstream x.y.1 is ready, and server roles all coming out as each is updated... a "release" is more a line in the sand than anything else. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
