On Wed, 2 Dec 2020 at 21:22, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
> >
> > CoreOS is going to be the same only worse, because it's not even built
> > the same way as the rest of Fedora. It's not built by Pungi, we don't
> > get the same messages published when CoreOS builds happen (we don't get
> > messages published at all, IIRC), the metadata for CoreOS builds is not
> > in productmd[2] form like the metadata for Pungi builds, the whole
> > process is entirely different.
> >
>
> Recently messages were added when streams are updated [0][1]. I believe
> that other messages could be added if needed.
Right, I forgot about that, thanks. I've got a ticket lying around here
somewhere to make something actually use them...:)
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
> >
> Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
> next, each stream is released every 2 weeks.
> The Go/No-Go is based on reports coming from each stream, next stream is
> promoted to testing and testing promoted to stable.
> If any blockers are found in next or testing the content will not be
> promoted to stable.
>
> I think it is fairly well explained here[2]
> >
> > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> > the context of how CoreOS is built and released? What set of bits will
> > we be deciding to ship or not ship, and how will that have been decided
> > and communicated? Where will we look to find the test results and
> > criteria on which we would base that decision?
> >
> >
> To maintain a fortnightly cadence there is a strong reliance on CI, every
> build is tested and results are inspected during the release process.
> Currently a release is gated on tests running on AWS, GCP and Openstack,
> these tests are running on a centos-ci jenkins instance which I think
> cannot be access without a centos account (I might be wrong), but yeah
> making these tests and results more transparent could be an improvement.
Right, but - as I think you started to recognize later in your mail -
we're sort of talking at cross-purposes here. You're talking about a
process that has been developed kind of in isolation for building and
releasing a thing which has the name "Fedora CoreOS" but doesn't
actually really integrate much at all with the processes we have for
building and releasing all the other things that make up "Fedora".
Indeed and this was because the current tools and processes were not designed to work
with a Fedora releasing every 2 weeks. Being allowed to think outside of the box
and doing things differently is IMO a good thing and should be encouraged.
This is kind of fine as things stand because the thing with the name
"Fedora CoreOS" isn't considered to be a core fundamental part of the
thing with the name "Fedora". But this Change is about making it that.
Doing that causes all sorts of awkward impedance mismatches. Like,
saying "Fedora CoreOS 34 does not exist" is awkward, because we still
have this kind of institutional concept of a "Fedora release" which is
important to what the thing called "Fedora" is and does.
To the outside
world, there is a strong impression that the thing called "Fedora" is a
product or set of products with a release number that gets released
every six months. The concept of "Fedora 33 release" or "Fedora 34
release" is a strong concept with all these sort of institutional
ripples.
And why cannot we make this evolve ? Is it bad to have a Fedora that has streams instead of versions ?
Promoting FCOS to an edition is the opportunity to communicate about this and say to the outside, hey we
have this new thing in Fedora that has a different model come and check it out.
Fedora has the reputation of leading innovation and doing things first, I would like to think that making Fedora CoreOS an edition would match these values.
Also having a different model allows us to expand and reach out to other types of users.
For years I have heard "I would like to run Fedora on my server, but there is no LTS and I don't want to do a major upgrade every year".
For years I have heard "I would like to run Fedora on my server, but there is no LTS and I don't want to do a major upgrade every year".
Why wouldn't be Fedora CoreOS, a possible answer to that problem ?
I believe that we need to be open to doing things differently and welcome different use cases.
If we want the thing called "Fedora CoreOS" to be a key, fundamental
component of the thing called "Fedora" - which is what making it an
"Edition" is effectively about - we have to deal with those impedance
mismatches.
So in this case, we could, for instance, make "Fedora CoreOS 34" a
'thing' by requiring that the CoreOS stable stream gets bumped at the
same time as the rest of the Fedora "release" happening. That gives us
a nice simple story that fits into our existing way of doing things.
Is this only a story problem ? I am sorry but I really struggle to understand why we cannot have a Fedora Edition that does not release every 6 months.
Would you mind explaining a bit more why it matters so much to be able to say we have a Fedora CoreOS 34 ?
This is more or less what we did with IoT: as things stand, the
situation with IoT is "OK, it's built from a separate compose stream,
but we still expect it to tie into the release cycle. We expect there
to be a release candidate based on the same bits as the mainline
release, with the same release number, that we sign off and release at
the same time."
Of course, that's also the drawback. If we don't want to do that, we
have to resolve the problem some other way, which is quite a
fundamental thing, if you think about it. My point here is that to do
that properly, we have to reconsider the strong idea that "Fedora is a
product that comes out every six months", which is a big job that comes
with quite a lot of consequences. It has consequences, for instance,
for our most important forms of communication to the wider world: how
do we pivot from this simple story that "Fedora is a (set of)
product(s) that come(s) out every six months, look out for our big
Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
this other thing that has three streams which release every two weeks
and roll over according to some completely other schedule"? And so on.
Considering the use cases and target users of Fedora CoreOS I think telling 2 different stories should not be a problem.
IMO this is already happening, I don't think people are confused between for example Fedora Workstation and Fedora CoreOS.
I do see much more confusion around Silverblue, IoT and Fedora CoreOS tho.
I'm not saying these are things that should stop the Change, I'm saying
they're things that *need to be considered as part of implementing the
Change*, and deciding its schedule. What I'd be worried about is if
this Change just amounted to bumping CoreOS up a few hundred pixels on
getfedora.org but otherwise changing nothing, because I think that
would actually cause some quite fundamental problems in terms of how we
think and talk about the thing called "Fedora".
It's true that for a while we called Atomic an edition, but it had most
of the same issues I talk about above and we didn't really resolve
them. I think we sort of got by with that because at that time our
communication wasn't quite as strong or clear and Atomic was more
obviously a thing which wasn't entirely "baked" yet, so people still
didn't consider it "really" a key part of Fedora, it still got
handwaved. I think that was us getting lucky, and we really should have
addressed more of these concerns more strongly then; I also think it's
not a given we'd get away with the same outcome now if we just hung an
"Edition" sign on CoreOS now but otherwise didn't consider any of these
concerns.
> >
> > Are any of these silly questions, which would indicate that our release
> > process is based on assumptions which need to be fundamentally re-
> > examined as part of this Change?
> >
>
> So what defines an Edition ?
Good question! getfedora.org uses the concept, but doesn't define it.
So the authoritative source, I guess, is still
https://fedoraproject.org/wiki/Editions , which says "Fedora Editions
are curated sets of packages, guidelines and configuration, and
artifacts built from those pieces, that address a specific, targeted
use-case. The Editions are the primary Fedora outputs that most Fedora
users are encouraged to use and directed towards through the download
site."
According to the above, it sounds to me that Fedora CoreOS fits the definition.
> I think if we don't want to accept a different
> philosophy about release schedule and release engineering we can just close
> that Change proposal.
That's not the outcome I intended, but rather that if we want CoreOS to
be an "Edition" but we don't want to require it to conform to the
existing "philosophy", as you put it, we need the scope of this Change
to include thinking through all the consequences of that and deciding
what to do about them.
Happy to do that, is your main concern about communication and the story of what is "Fedora" ? or what are the other consequences ?
> How do you consider Rawhide for example ?
Rawhide isn't an edition, which I think should be clear from the
definitions above. Rawhide is sort of the primordial soup from which
Editions and all else eventually emerges, I guess. :P
> >
> > All of this is stuff we could kind of handwave so long as CoreOS wasn't
> > an official Edition; we could *more or less* leave the CoreOS team to
> > decide what a CoreOS release looked like and when it would happen and
> > when it was good enough to ship, and so on.
> >
>
> So this change comes down to Can we have a Fedora Edition that has a
> different workflow ?
More or less, yes - but with a key addition: "...and if so, how?"
I feel that we already have the how, Fedora CoreOS has been releasing fortnightly for more than a year now.
So it is a matter of making more widely known how this is done ?
Thanks for sharing your concerns, I think this is a really good conversation to have.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
