#2516 F34 Change: Make Fedora CoreOS a Fedora Edition
Opened 2 months ago by bcotton. Modified 5 days ago

This changes is to promote Fedora CoreOS to Edition status alongside Workstation, Server and IoT.

The Wiki page for the Change is very bare-bones, but since all prerequisites were tracked elsewhere, that's probably to be expected. +1

Given how out of sync Fedora CoreOS is with Fedora itself with no concrete plan to fix this, I do not believe it should be granted Edition status. -1

I would love to see FCOS rise to the edition status. But I think that the current proposal and the answers in the discussion on fedora-devel come up short in answering the question how this new edition will be integrated with the Fedora development and release process. Right now fcos stable is based on F32, fcos testing and fcos next are both based on F33. Questions: first, how much should fcos trail behind the releases of "normal" Fedora, and second, how do we deal with issues which are discovered in fcos and need to be solved by changes outside of fcos itself.

For the first question, the answer is in https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#production-refs, but I'm not convinced this is satisfactory. According to that doc, fcos next will start switching to branched at the point where we are "code complete" and start the beta freeze, which is rather late. At that point, we want early adopters to switch and to do functional testing. But if fcos just switches, it will be a while before it reaches that stage.

The second question is harder. While letting fcos trail behind normal fedora gives additional stability to fcos, it also means that when issues are discovered, normal fedora has already been released and we can't do any breaking changes. A "release-blocking deliverable" means that we have the window to do even significant changes that we wouldn't do after the release. When fcos is promoted to edition status, I would expect fcos to be integrated in this process, i.e. to have a stream which closely follows branched, participates in testing, and can be used to discover any significant issues. It is important for this all to be transparent as with other editions, so that users and packagers who are not closely affiliated with fcos can do meaningful qa.

Maybe fcos next needs to be always based off branched? Should Changes have an explicit evaluation of effect for fcos? Some plan for this is needed. It seems too early to vote while this is being hashed out.

(In some way, I'm restating what @adamwill said in the fedora-devel discussion. I think some clarity about what is being asked was reached, but no actual answers were provided.)

@zbyszek has convinced me. I change my vote to -1 as well, until those problems are addressed. If this is going to be a Fedora Edition, then it needs to align its testing and release process ...

FWIW I also think that concerns that @adamwill rose on the list were not properly addressed yet, but I haven't been following the discussion entirely, so consider me -0 (= abstain, but tend to -1).

First for obvious reasons I am not going to vote on that Change :)

I am working on updating the Change Proposal to add answers to the points raised in the devel-list discussion.

First for obvious reasons I am not going to vote on that Change :)

We had a lengthy discussion about FESCo members voting on their own proposals last year. The short summary is that people find it OK.

Update: we have a fcos rawhide stream now:
(I'd link to the fedora-devel announcement, but lists.fp.o only gives me 500 ;( )
On Tue, 2020-12-22 at 15:22 -0800, Adam Williamson wrote:

Cool, I'll set openQA up to test this stream too.

...well, I will as soon as https://builds.coreos.fedoraproject.org/streams/rawhide.json isn't 403 any more :D

It's still 403 as of today.

Before I'm willing to reconsider my vote, I want to see a concrete proposal of how Fedora CoreOS will align itself to the rest of Fedora in development and release cycles. In my opinion, it is unacceptable to have an edition that lags, because it adds burden and difficulty for ensuring development covers everyone appropriately.

@zbyszek basically the answer to that was "it's expected/intended" and I need to rework the openQA scheduler for that case. which I'll get started on now we're all back at work.

I think we need to wait some more from input from the coreos folks, so I'm not putting this on the meeting agenda.

As an FYI, we are going to have a community meeting about this change early Feb (I ll share the details on devel list once I have them) to enhance the proposal and discuss how FCOS fits within the schedule.

Login to comment on this ticket.