On Tue, Oct 04, 2016 at 08:14:43AM -0500, Dennis Gilmore wrote: > On Friday, September 30, 2016 5:01:52 PM CDT Josh Boyer wrote: > > On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus <jberkus@xxxxxxxxxx> wrote: > > > On 09/30/2016 01:11 PM, Adam Miller wrote: > > >> On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller > > >> > > >> <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > >>> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote: > > >>>>> think QA clearly understands what cloud image(s) are release blocking, > > >>>>> as previously they were just the non-atomic images. > > >>>> > > >>>> Which images are prominent on the download pages and how much of a > > >>>> relationship there is between that and 'release blocking' status is > > >>>> *also* not my problem, but I'd agree with you (Chris) that it'd be > > >>>> rather strange for the most prominently advertised deliverable for a > > >>>> given product not to be a release-blocking one. > > >>> > > >>> I don't think that Atomic *needs* to be release blocking, because if it > > >>> misses the grand unified release, we have the ability to update it at > > >>> the next cycle, so it's less of a big deal. But if we collectively > > >>> prefer to make sure everything is lined up on the release day... I can > > >>> see arguments for that, too. > > > > > > Well, currently I'm working with the designers on a new page for Atomic > > > F25. So if that's NOT going to be live the day of the F25 release, then > > > it's something we need to know ahead of time. > > > > > > I also really don't like the message Atomic not being ready sends. We > > > will have three branches for GetFedora: Workstation, Server, and Atomic. > > > > > > If Atomic isn't ready the day of the release, it looks pretty bad; > > > > > > that's saying we're ok with only being 2/3 ready, or that despite > > > promoting Atomic to 1st class status we don't really believe it's > > > important. > > So... there is a pretty big disparity between what you just said and > > what FESCo has been told in the past two meetings. Jan has been > > trying to get release blocking deliverables for the Cloud WG (now > > Atomic?) confirmed for a while [1]. Two weeks ago, Kushal confirmed > > the existing base images are release blocking and Atomic is not. That > > was repeated in today's meeting[2] as well: > > > > 16:44:56 <kushal> Cloud base image is the only blocking deliverable. > > 16:44:59 <kushal> Atomic is not. > > > > I realize this WG is in the middle of rebooting itself, but to have > > clearly conflicting information from the WG members is a bit > > concerning. > > > I will note that Atomic is not delivered as part of the relase at all. it is > only delivered as a stable artifact via the two week atomic host release > process. So there is no possible way it can be release blocking, there seems > to be some major confusion and disconnect here. 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. 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. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
