#2516 F34 Change: Make Fedora CoreOS a Fedora Edition
Closed: Insufficient data 2 years ago by cverna. Opened 2 years ago by bcotton.

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.

Given where we are in the schedule and the open questions, should we go ahead and consider this as an F35 proposal? Or should it be considered withdrawn and re-submitted later?

I would prefer this to be withdrawn and re-submitted once a concrete proposal is available, rather than automatically retargeting this for Fedora 35. It sounds like there isn't a specific plan yet, based on the notes published after that meeting: https://github.com/coreos/fedora-coreos-tracker/blob/master/docs/20210204_fcos_official_edition.md

I don't mind either way, what is the difference between retargeting and resubmitting tho ?

Not sure if this is a concrete plan but based on the discussion we had during the virtual meetup I have the following actions

  • Work with Fedora QA on having explicit Release Criteria
  • Work with Ben on having a Change proposal system that would allow FCOS to better announce changes happening
  • Sync with @sumantrom to see what needs to happen on the mindshare side.

I don't mind either way, what is the difference between retargeting and resubmitting tho ?

Retargeting keeps this ticket open, with the implication that it would get voted on soon (or at least keep getting pushed out over and over) and be substantially similar to what was already proposed.

Closing and resubmitting indicates that the new proposal needs to go through the process again because it has changed substantially.

Ok so resubmitting sounds like a good idea to me :) so that we can look at the change with a fresh perspective.

Closing the issue and updating the wiki page. @cverna let's schedule a time soon to start thinking about what a change proposal process might look like.

Metadata Update from @cverna:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

2 years ago

Sorry I did not have a strong motivation to work on this last year :-). But since then we have pushed quite a few improvement based on the feedback we have received.

  • We have added a Fedora CoreOS rawhide stream which allow us to be more reactive to new changes and keep up with the next version development.
  • When Fedora 35 GA our Testing stream was already based on F35 content, and we have an open discussion to make this the norm (https://github.com/coreos/fedora-coreos-tracker/issues/1024)
  • We are now releasing FCOS on x86_64 and aarch64 and are exploring ways to support other architecture (mostly limited to available hardware in Fedora's infra)
  • We have moved our build pipeline from the CentOS CI openShift cluster to Fedora's Infrastructure openShift's cluster
  • We have been more involved in the Change process, by reviewing changes and submitting changes too.

I think from the feedback we received, we have left to find out :

  • How we integrate in a new major release Go/NoGo decision (release criteria)
  • Look at ways to adapt the Change Proposal system for an OS which releases on faster cadence than every 6 months.

Login to comment on this ticket.