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(a)fedoraproject.org>
Fedora Project Leader