6:16 p.m.
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/...
(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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:35 a.m.
New subject: Cloud and Server Q&A
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(a)fedoraproject.org>
Fedora Project Leader
3:11 p.m.
New subject: Cloud and Server Q&A
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
<mattdm(a)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(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list -- cloud(a)lists.fedoraproject.org
> To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org
3:41 p.m.
New subject: Cloud and Server Q&A
On 09/30/2016 01:11 PM, Adam Miller wrote:
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
<mattdm(a)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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
4:01 p.m.
New subject: Cloud and Server Q&A
On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus <jberkus(a)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(a)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...
4:31 p.m.
New subject: Cloud and Server Q&A
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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
7:02 p.m.
New subject: Cloud and Server Q&A
On Fri, Sep 30, 2016 at 3:31 PM, Josh Berkus <jberkus(a)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.
--
Chris Murphy
6:21 a.m.
New subject: Cloud and Server Q&A
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
--
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org
8:10 a.m.
New subject: Cloud and Server Q&A
On Tue, Oct 4, 2016 at 6:21 AM, Kushal Das <mail(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org
8:14 a.m.
New subject: Cloud and Server Q&A
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(a)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(a)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
8:46 a.m.
New subject: Cloud and Server Q&A
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(a)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(a)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.
--
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
10:13 a.m.
New subject: Cloud and Server Q&A
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.
12:59 p.m.
New subject: Cloud and Server Q&A
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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
1:21 p.m.
New subject: Cloud and Server Q&A
On 4 October 2016 at 13:59, Josh Berkus <jberkus(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
2:58 p.m.
New subject: Cloud and Server Q&A
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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
3:38 p.m.
New subject: Cloud and Server Q&A
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:57 p.m.
New subject: Cloud and Server Q&A
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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
2:04 p.m.
New subject: Cloud and Server Q&A
On Wed, Oct 5, 2016 at 11:57 AM, Josh Berkus <jberkus(a)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:
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.
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.
--
Chris Murphy
2:30 p.m.
New subject: Cloud and Server Q&A
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:
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 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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:47 a.m.
New subject: Cloud and Server Q&A
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:
>
> 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 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.
3:19 p.m.
New subject: Cloud and Server Q&A
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.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
5:07 a.m.
New subject: Cloud and Server Q&A
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
1:43 p.m.
New subject: Cloud and Server Q&A
On Tue, Oct 4, 2016 at 11:59 AM, Josh Berkus <jberkus(a)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.
--
Chris Murphy
3:34 p.m.
New subject: Cloud and Server Q&A
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:32 p.m.
New subject: Cloud and Server Q&A
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
3:12 p.m.
New subject: Cloud and Server Q&A
On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
<mattdm(a)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(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list -- cloud(a)lists.fedoraproject.org
> To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org
1394
days inactive
1404
days old
25 comments
12 participants
participants (12)
-
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