On Thu, 2016-09-29 at 16:51 -0600, Chris Murphy wrote:
But I don't think QA clearly understands what cloud image(s) are release blocking, as previously they were just the non-atomic images.
I don't know what's going on with all this crap, but so far as I'm concerned I understand perfectly well what the release blocking images are. It's the ones listed on the release blocking images page which specifically exists for this purpose:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
(we still need to make the canonical version of this a JSON file somewhere and generate the human-readable version from the JSON, but meh, I haven't got around to it yet).
if it doesn't say 'yes' there, it ain't release blocking. Maintaining that thing is the program manager's problem (i.e. jkurik's), not mine, but it does somewhat concern me the number of 'TBD's on there. I don't think the question of what images are 'release blocking' for F25 should be *remotely* live at this point: it should have been decided weeks ago, at least by Alpha release. And so far as I remember it, that's what the protocol was supposed to be, we weren't still supposed to be kicking around 'is it blocking?' discussions at Beta freeze. I'd personally be very unhappy with any attempt to significantly change what that page says right now.
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.
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.
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller mattdm@fedoraproject.org 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.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org
On 09/30/2016 01:11 PM, Adam Miller wrote:
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller mattdm@fedoraproject.org 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.
On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus jberkus@redhat.com wrote:
On 09/30/2016 01:11 PM, Adam Miller wrote:
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller mattdm@fedoraproject.org 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.
josh
[1] https://fedorahosted.org/fesco/ticket/1626 [2] https://meetbot.fedoraproject.org/fedora-meeting/2016-09-30/fesco.2016-09-30...
On 09/30/2016 02:01 PM, Josh Boyer wrote:
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.
Kushal?
Based on my attendence at the Cloud WG meetings, I had the understanding that Atomic was becoming our main deliverable. If that's not true, then I need to pull a whole bunch of changes and put them on ice until Fedora 26.
On Fri, Sep 30, 2016 at 3:31 PM, Josh Berkus jberkus@redhat.com wrote:
On 09/30/2016 02:01 PM, Josh Boyer wrote:
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.
Kushal?
Based on my attendence at the Cloud WG meetings, I had the understanding that Atomic was becoming our main deliverable. If that's not true, then I need to pull a whole bunch of changes and put them on ice until Fedora 26.
What also matters is the understanding of others who needed to understand this. To me it sounds like a baton was dropped. But moving forward...
What does release blocking mean? There are a bunch of QA criteria and test cases that help make sure those criteria are met. There are no atomic host specific criteria or test cases that I'm aware of. I expect QA probably can't provide significant assistance in QAing the atomic qcow2 image for this release. How big of a problem is that? Is there a Fedora policy that requires a default download product to be QA'd somehow, or to be release blocking? Can Cloud WG take the lead QA'ing the atomic qcow2 image? What are the releng implications of it not being release blocking?
For example, during the Fedora 24 cycle there was a neat bug in the compose process that caused some images to fail. It wasn't possible to just do another compose and cherry pick the working ISOs from two different composes (I forget why). Is there anything like that here, or is there sufficiently good isolation between ostree images and other images? What happens if release is a go for everything else, but atomic qcow2 is not working? What I've heard is "fix the problem and remake the image" similar to the current two week cycle. Does releng agree, and will there be time between a Thursday "go" and Tuesday (whatever day it is) "release" to get an atomic qcow2 built and on getfedora? What if there isn't? What if it's a week after release before there's a working one?
If the liabilities there can be sorted out satisfactorily I'd say proceed with Atomic on getfedora.
Next issue is Cloud Base images. Cloud WG needs to decide if these are going to be created and if so how they're going to get linked to and from where. Is there a designed landing page for these already? If not, my thought is have a side bar link to a basic directory listing for them, rather than the fancy landing page that currently exists for Fedora 24 Cloud Base images. And demote the Cloud Base images to non-release blocking. And then whatever contingency for that side bar link if the Cloud Base images aren't available for release day.
On 30/09/16, Josh Berkus wrote:
On 09/30/2016 02:01 PM, Josh Boyer wrote:
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.
Atomic host image is the deliverable for the Atomic WG, which is under 2 week release cycle. We sync up with the official release version at the time of GA, but we continue to be in our 2 week atomic release cycle then on the 6month old GA. This is my understanding about all the work done for 2 Week Atomic.
Now I may be completely wrong to understand our 2 week release cycle process, but this is what I followed for the release-infra work till now.
Kushal
On Tue, Oct 4, 2016 at 6:21 AM, Kushal Das mail@kushaldas.in wrote:
On 30/09/16, Josh Berkus wrote:
On 09/30/2016 02:01 PM, Josh Boyer wrote:
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.
Atomic host image is the deliverable for the Atomic WG, which is under 2 week release cycle. We sync up with the official release version at the time of GA, but we continue to be in our 2 week atomic release cycle then on the 6month old GA. This is my understanding about all the work done for 2 Week Atomic.
Now I may be completely wrong to understand our 2 week release cycle process, but this is what I followed for the release-infra work till now.
This is correct, Fedora Atomic Two-Week Release was meant to allow Fedora Atomic more flexibility in it's release cycle. Part of the initial proposal was to remove it from being directly bound to the standard six month release cycle. If this is something we want to change, that's fine. However, if we do that we need to get buy in from all groups involved in that process instead of just change things out from everyone. Also, people will need to show up to do the work in Fedora QA because there's a lot of it and we can't realistically ask them to take on what is effectively 5 new deliverable artifacts without assistance (ISO, qcow2, raw, vagrant-vbox, vagrant-libvirt).
-AdamM
Kushal
Fedora Cloud Engineer CPython Core Developer https://kushaldas.in https://dgplug.org _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org
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@redhat.com wrote:
On 09/30/2016 01:11 PM, Adam Miller wrote:
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
mattdm@fedoraproject.org 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.
Dennis
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@redhat.com wrote:
On 09/30/2016 01:11 PM, Adam Miller wrote:
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
mattdm@fedoraproject.org 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.
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.
As far as I know the "blocker flag" is the main means of cutting through all of the red tape.
Now, we could discuss alternatives, such as having Atomic Host being able to carry its own overrides temporarily.
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.
And, like I said, this also ties into the F25 cycle getfedora.org redesign. We simply can't go ahead with a redesign which emphasizes Atomic over the cloud base image if F25-base Atomic isn't ready at release time. We'll have to hold that back, and that's something the design team needs to know.
On 4 October 2016 at 13:59, Josh Berkus jberkus@redhat.com 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.
The corollary is that if the people who are supposed to be working and caring for an edition are not doing the work already, making it release blocking doesn't magically fix it. What happens instead is that people who are doing that work on other editions have to add this to their last dash get it across the line.
If people aren't all that interested in a Fedora Cloud or Fedora Atomic it would be better that the resources were spent where they could be concentrated. I say this with the same view towards Fedora Server or Fedora <fill in any arch but x86_64>. If all we are doing is making it so people not really interested in it HAVE to carry it onward then it is a worse failure than saying "we would have been better off in Arch or Madreia or Ubuntu Atomic" because we will have lost all four F's. People won't be having Fun, they won't have Freedom, they won't be Friends because of bitterness, and it will all build up to make sure nothing is 'First'. If that means that all we do is build a couple of desktop distros then so be it.. at least people will be working on something that meets those 4 Fs.
And, like I said, this also ties into the F25 cycle getfedora.org redesign. We simply can't go ahead with a redesign which emphasizes Atomic over the cloud base image if F25-base Atomic isn't ready at release time. We'll have to hold that back, and that's something the design team needs to know.
--
Josh Berkus Project Atomic Red Hat OSAS _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org
On 10/04/2016 11:21 AM, Stephen John Smoogen wrote:
The corollary is that if the people who are supposed to be working and caring for an edition are not doing the work already, making it release blocking doesn't magically fix it. What happens instead is that people who are doing that work on other editions have to add this to their last dash get it across the line.
What this is sounding like is a huge discrepancy between what the Council, PRD group, etc. think we should be doing and what we can actually do.
Given that, I think I should tell the designer to push the design changes back.
On Tue, Oct 04, 2016 at 12:58:05PM -0700, Josh Berkus wrote:
What this is sounding like is a huge discrepancy between what the Council, PRD group, etc. think we should be doing and what we can actually do.
Given that, I think I should tell the designer to push the design changes back.
I don't see how that follows. In the ideal — and I think most likely, since the bugs making F25 not work are being knocked off — case, we'll have Atomic built on F25 at F25 GA date. In the less ideal case, we'll keep shipping the F24-based one, but there's no reason that can't work with the new Atomic-focused design. For that matter, we could launch that _before_ the GA.
On 10/04/2016 01:38 PM, Matthew Miller wrote:
On Tue, Oct 04, 2016 at 12:58:05PM -0700, Josh Berkus wrote:
What this is sounding like is a huge discrepancy between what the Council, PRD group, etc. think we should be doing and what we can actually do.
Given that, I think I should tell the designer to push the design changes back.
I don't see how that follows. In the ideal — and I think most likely, since the bugs making F25 not work are being knocked off — case, we'll have Atomic built on F25 at F25 GA date. In the less ideal case, we'll keep shipping the F24-based one, but there's no reason that can't work with the new Atomic-focused design. For that matter, we could launch that _before_ the GA.
So, I'm looking at this from a user perspective.
* F25 is announced * User goes to getfedora.org, sees new "atomic" icon. * User clicks through * User sees that Atomic is still F24.
From that point, one of two things happens:
1. User files a bug, and we're flooded with "atomic download page not updated" bugs, or
2. user decides that Atomic isn't a real thing and never goes back.
I really don't see a flow that results in the user checking back two weeks later to see if Atomic has been updated yet. Especially since we're dealing with a substantial issue with SELinux and it's not guaranteed that there will be an F25 atomic release 2 weeks later, either.
You are the Project Leader, and you can certainly say "do it anyway". But please understand why I think it's not a great idea.
On Wed, Oct 5, 2016 at 11:57 AM, Josh Berkus jberkus@redhat.com wrote:
On 10/04/2016 01:38 PM, Matthew Miller wrote:
On Tue, Oct 04, 2016 at 12:58:05PM -0700, Josh Berkus wrote:
What this is sounding like is a huge discrepancy between what the Council, PRD group, etc. think we should be doing and what we can actually do.
Given that, I think I should tell the designer to push the design changes back.
I don't see how that follows. In the ideal — and I think most likely, since the bugs making F25 not work are being knocked off — case, we'll have Atomic built on F25 at F25 GA date. In the less ideal case, we'll keep shipping the F24-based one, but there's no reason that can't work with the new Atomic-focused design. For that matter, we could launch that _before_ the GA.
So, I'm looking at this from a user perspective.
- F25 is announced
- User goes to getfedora.org, sees new "atomic" icon.
- User clicks through
- User sees that Atomic is still F24.
From that point, one of two things happens:
- User files a bug, and we're flooded with "atomic download page not
updated" bugs, or
- user decides that Atomic isn't a real thing and never goes back.
I really don't see a flow that results in the user checking back two weeks later to see if Atomic has been updated yet. Especially since we're dealing with a substantial issue with SELinux and it's not guaranteed that there will be an F25 atomic release 2 weeks later, either.
You are the Project Leader, and you can certainly say "do it anyway". But please understand why I think it's not a great idea.
There's roughly 5 weeks to GA to get atomic stuff sorted out, which sounds like there's some padding available.
Option A: Burn the midnight oil and commit to the Atomic landing page and its deliverables.
Option B: Ask design folks if they're willing and able to be prepared with contingency: swap out the planned new Atomic landing page for an updated version of the current Cloud landing page, if Atomic isn't ready by X days before GA.
IF you have to pull the contingency, I think at most anytime even within Fedora 25's life time, you can swap out Cloud for Atomic to underscore the new emphasis.
I think it's right to say instead of pressure cooker May and November, that it's a lighter effort more broadly distributed. I don't see a big problem with a change in branding midstream for a release, but I'm not a marketing type.
On Wed, Oct 05, 2016 at 10:57:49AM -0700, Josh Berkus wrote:
So, I'm looking at this from a user perspective.
- F25 is announced
- User goes to getfedora.org, sees new "atomic" icon.
- User clicks through
- User sees that Atomic is still F24.
From that point, one of two things happens:
- User files a bug, and we're flooded with "atomic download page not
updated" bugs, or
- user decides that Atomic isn't a real thing and never goes back.
I don't think we'd leave the Atomic page with F24 with no explanation. There's _already_ an explanation around the two-week cycle, and that can just be expanded a bit — again, in the case where it doesn't happen to be ready, which isn't necessarily where we're at.
I really don't see a flow that results in the user checking back two weeks later to see if Atomic has been updated yet. Especially since we're dealing with a substantial issue with SELinux and it's not guaranteed that there will be an F25 atomic release 2 weeks later, either.
They shouldn't have to check back; it should be part of the normal flow of updates.
I can't see any situation where "come back in six months!" is a _better_ alternative.
You are the Project Leader, and you can certainly say "do it anyway". But please understand why I think it's not a great idea.
Well, here's some background thinking: new Fedora versions do not appear to be, in general, big drivers of user adoption. There's a spike of downloads the first week of a release, but it's a fraction of the total downloads for a release. And, each release keeps growing in use over its lifecycle until the next comes out. Basically, people are coming for Fedora, and getting whatever version happens to be current.
This is one of the reasons behind dropping unique release names, and shortly after, focusing on the Editions — rather than making a big deal about Schrödinger's Cat vs. Heisenbug, the marketing push should be around Atomic, Workstation, and Server individually.
The release does give us an excuse for PR, but it's my sense that two releases a year is a little overwhelming for that — we are still getting F24 reviews coming in. And, since column inches are (figuratively these days!) limited, generally the press we get is 90% desktop, with only mentions of Atomic and Server, so that benefit is dubious for Atomic anyway.
Current beta release announcement at:
https://fedoraproject.org/wiki/F25_Beta_release_announcement#Fedora_Atomic
Tries to be cautiously optimistic - do not want user frustration from initial attempts, but still want people who have the time to try it out.
On 10/05/2016 10:30 PM, Matthew Miller wrote:
On Wed, Oct 05, 2016 at 10:57:49AM -0700, Josh Berkus wrote:
So, I'm looking at this from a user perspective.
- F25 is announced
- User goes to getfedora.org, sees new "atomic" icon.
- User clicks through
- User sees that Atomic is still F24.
From that point, one of two things happens:
- User files a bug, and we're flooded with "atomic download page not
updated" bugs, or
- user decides that Atomic isn't a real thing and never goes back.
I don't think we'd leave the Atomic page with F24 with no explanation. There's _already_ an explanation around the two-week cycle, and that can just be expanded a bit — again, in the case where it doesn't happen to be ready, which isn't necessarily where we're at.
I really don't see a flow that results in the user checking back two weeks later to see if Atomic has been updated yet. Especially since we're dealing with a substantial issue with SELinux and it's not guaranteed that there will be an F25 atomic release 2 weeks later, either.
They shouldn't have to check back; it should be part of the normal flow of updates.
I can't see any situation where "come back in six months!" is a _better_ alternative.
You are the Project Leader, and you can certainly say "do it anyway". But please understand why I think it's not a great idea.
Well, here's some background thinking: new Fedora versions do not appear to be, in general, big drivers of user adoption. There's a spike of downloads the first week of a release, but it's a fraction of the total downloads for a release. And, each release keeps growing in use over its lifecycle until the next comes out. Basically, people are coming for Fedora, and getting whatever version happens to be current.
This is one of the reasons behind dropping unique release names, and shortly after, focusing on the Editions — rather than making a big deal about Schrödinger's Cat vs. Heisenbug, the marketing push should be around Atomic, Workstation, and Server individually.
The release does give us an excuse for PR, but it's my sense that two releases a year is a little overwhelming for that — we are still getting F24 reviews coming in. And, since column inches are (figuratively these days!) limited, generally the press we get is 90% desktop, with only mentions of Atomic and Server, so that benefit is dubious for Atomic anyway.
On 10/06/2016 07:47 AM, Benson Muite wrote:
Current beta release announcement at:
https://fedoraproject.org/wiki/F25_Beta_release_announcement#Fedora_Atomic
Tries to be cautiously optimistic - do not want user frustration from initial attempts, but still want people who have the time to try it out.
What's the ISO link? I'd like to add it in, but I can't figure out what the stable link is.
On 10/07/2016 11:19 PM, Josh Berkus wrote:
On 10/06/2016 07:47 AM, Benson Muite wrote:
Current beta release announcement at:
https://fedoraproject.org/wiki/F25_Beta_release_announcement#Fedora_Atomic
Tries to be cautiously optimistic - do not want user frustration from initial attempts, but still want people who have the time to try it out.
What's the ISO link? I'd like to add it in, but I can't figure out what the stable link is.
ISO link was not working last time checked, so it was removed. Link was: https://getfedora.org/atomic_iso_latest
Previous message in list indicates that the request below needs to be merged for link to become active: https://pagure.io/fedora-websites/pull-request/43
On Tue, Oct 4, 2016 at 11:59 AM, Josh Berkus jberkus@redhat.com 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.
On Tue, Oct 04, 2016 at 11:13:02AM -0400, Colin Walters wrote:
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.
As far as I know the "blocker flag" is the main means of cutting through all of the red tape.
Yeah, I've been talking about this problem for a while — basically, since Release Blocker is the only big attention-forcing hammer we have, we tend to hit too many things with it. We need a different way.
Now, we could discuss alternatives, such as having Atomic Host being able to carry its own overrides temporarily.
As you know, I'm in favor of this possibility should it come to that.
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.
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller mattdm@fedoraproject.org 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.
Note that the cycle that Matt is mentioning here is Two-Week iterations for Atomic Host so the window to release is relatively rapid compared to the standard ~6 months.
-AdamM
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@lists.fedoraproject.org
-
Adam Miller -
Adam Williamson -
Benson Muite -
Chris Murphy -
Colin Walters -
Dennis Gilmore -
Josh Berkus -
Josh Boyer -
Kushal Das -
Matthew Miller -
Paul W. Frields -
Stephen John Smoogen