Hmm, nobody has picked this up. FESCo members: please vote.

-0 to avoid automatic approval.

-0 to avoid automatic approval.

Shouldn't that be a -1 if you want to block auto approval? (And thus tag it for the meeting). -0 seems like we're trying to be too clever with the voting process.

I have concerns about the nature of this proposal, especially creating a co-dependency model for RPM-OSTree based variants with this "layering" thing.

-1

especially creating a co-dependency model for RPM-OSTree based variants with this "layering" thing.

Can you elaborate on this? What's the co-dependency here?

This will be discussed during today's meeting at 17:00 UTC.

0 (temporarily)

I think I like where this is headed, but there's so much in the proposal that it's difficult for me to track it all. A visual representation (maybe a diagram or flow chart?) would help me out a lot.

This was discussed during today's FESCo meeting:
* AGREED: Everybody is to re-read the prosal and vote in the ticket.
* If that fails, we'll vote next week in the meeting.

I think I like where this is headed, but there's so much in the proposal that it's difficult for me to track it all. A visual representation (maybe a diagram or flow chart?) would help me out a lot.

Conceptually, the center of the of things becomes bootable container images - implemented using ostree for now.

Are there any more specific details I can help with? Happy to join a realtime meeting and explain/demo things if that helps!

+1

I am a staff engineer on OpenShift core engineering. We are working on shipping this on OpenShift and taking a hard dependency on the ability to boot and configure the operating system from a container image. We are very interested in landing this in Fedora and derived distributions in a sustainable manner.

• AGREED: Everybody is to re-read the prosal and vote in the ticket.

I'm obviously open to more detailed and nuanced feedback outside of the set of "+1, 0, -1" by the way! It's a big proposal and nothing is "set in stone".

This OpenShift commons lightning talk might help explain some of the motivation behind this - though I'd emphasize from my (OCP developer hat) perspective I also want this functionality to apply to Linux systems in general, not just Kubernetes nodes.

FWIW, I'm +1 to the proposal in general. If we end up having concerns with individual bits of it, we can address those as they come up.

+1

This is a good direction overall and will hopefully improve both CoreOS and Silverblue.

After a week, the vote is (+2,0,-0). I'll leave it up to today's meeting chair to decide if it should be a last minute addition to the agenda, or if we should wait another week for additional voting per the usual policy.

It will wait until next week. The agenda for today is fairly full as it is.

+1 I am still not fully sure I understand the full ramifications of this, but it's definitely a cool direction to go and we can always adjust if needed.

+1 I am still not fully sure I understand the full ramifications of this, but it's definitely a cool direction to go and we can always adjust if needed.

My general worry is that we actually can't.

That said, the three main implications I have derived from this after discussing this with @siosm to get clarity are as follows:

1. Stacking everything on Fedora CoreOS makes subtractive changes ineffective (ie removing packages doesn't save space when building derivatives)
2. We change from using OSTree remotes to OCI registries with the implications therein
3. Dynamic delta fetching of OSTree blobs is replaced with static deltas from OCI image layers

The only issue I have with this is point 1. The rest is meh.

Stacking everything on Fedora CoreOS makes subtractive changes ineffective (ie removing packages doesn't save space when building derivatives)

The plan does not call for stacking things on Fedora CoreOS.

We support deriving new user custom images from these images

This is effectively stacking things.

We support deriving new user custom images from these images

This is effectively stacking things.

But that's only if a user decides they want to build their own thing? I don't think anyone (that I know of) has proposed basing i.e. Silverblue on CoreOS (stacking).

I'm pretty sure it has come up before, which is why I was concerned. If it's not happening as part of this Change or any Change in flight right now, then I'm fine with this.

+1 (with the proviso the statement above is true)

To confirm here: Stacking things on top of Fedora CoreOS has been discussed/suggested in the past but this is not the goal of this change.

The goal of this change is to do the ground work to move from the ostree classic format to containers by default, while keeping each edition build process distinct like they are right now.

Potential unification, de-duplication could happen later but is not part of this change.

After an additional week, the vote is
APPROVED (+4,0,-0)