I think having a documented procedure that involves a SIG which hasn't been seen or heard in 4 years doesn't make much sense ;) So I definitely support updating the docs to match current organizational structure.

are there security baseline requirements?

If the spin is built from Fedora packages, and updates when those packages are updated, this should cover basic security maintainance.

What changes are allowed and which, if any, are off-limits

I guess that a spin cannot distribute content that is not allowed in Fedora. Apart from that, I don't think we can come up with any rule. All the stuff that is listed (including modules) should be allowed.

For some reason, I thought we've generally considered Spin-centric changes to be Self-Contained, but that actually seems to be a mixed bag, given the data. I still see value in having those changes announced, but perhaps we should formalize whether or not a spin-local change is "self-contained" by definition or not.

I think having a documented procedure that involves a SIG which hasn't been seen or heard in 4 years doesn't make much sense ;) So I definitely support updating the docs to match current organizational structure.

Yeah, exactly -- this is basically directly under FESCo now.

are there security baseline requirements?

If the spin is built from Fedora packages, and updates when those packages are updated, this should cover basic security maintainance.

I was thinking things like password strength, selinux, packet filtering — are there baseline standards which must be met, or at least should be met without an explicit justification and exception?

What changes are allowed and which, if any, are off-limits

I guess that a spin cannot distribute content that is not allowed in Fedora. Apart from that, I don't think we can come up with any rule. All the stuff that is listed (including modules) should be allowed.

This is my position too, for the record.

I was thinking things like password strength, selinux, packet filtering — are there baseline standards which must be met, or at least should be met without an explicit justification and exception?

We set no limits on password strength (just advistory warnings when it's low), packet filtering already differs by spin (workstation disables the firewall). I'm not sure if any spins disable selinux, but if a spin wanted to do that to experiment with a different mac or just a different approach, I'd consider this entirely reasonable.

I would rather update the docs to describe how to do a spin, and I wouldn't worry about trying to come up with rules, since it's going to be very hard to make them generic enough support the new stuff people come up with but not completely toothless.

I would rather update the docs to describe how to do a spin

FWIW, consolidating and updating the spins docs is on my Taiga Board of Shame. I'm happy to increase its priority from "Real Soon Now" to "Will Actually Get Done at Some Point" if that'd be helpful to the issue at hand.

In the past we did forbid disabling selinux IIRC...

If we want to drop the spins/labs naming, what do we use here? Artifacts? non primary Deliverables?

What If we review new ones as they come in and also allow for re-review of existing ones triggered by request?

I think there should be a line, but I am not sure off hand how to describe it, but I would think we could know it when we see it... of course that makes it harder for new artifacts to know what fesco would approve or not.

I think Solutions should be granted explicit decision making tasks rather than saying whatever you want to do in the Solution is fine. Doing the latter is just enabling forks and we probably don't want that if we want all of these things under the same Fedora branding.

It might be useful to define what makes a system "Fedora" in the first place. Because Solutions are built from Fedora content, that's really just a customization, right? We should be able to define what makes a Fedora system. From that I think it's easy to define a set of rules for Solution changes.

A Solution should be able to make a default change easily. For larger changes, a Solution should first introduce that in to Fedora as a change proposal which adds the change as an option they can then enable in their Solution. Over time, settings with multiple choices will phase out and we'll converge on defaults. This method could make changes a little less volatile.

@dcantrell, I understand where you are coming from with "explicit decision making tasks". But as I said, I don't think such enumeration is possible, because every new spin is going to be something novel and different. Let's go back to the time before ostree: if this ticket was open back then and we were trying to write some rules, I'm pretty sure we would not have been able to write something that encompassed the change to read-only transactional root. Then let's back to the time before ELN: again, I don't think the rules we would write would not be violated again. I imagine that in the future someone might want to do a spin with a different security mechanism replacing selinux. Or to use flatpaks for everything, or to provide a WSL2-compatible image, etc. The goal of Fedora is innovation, and this means breaking barriers, making it very hard to write rules that will apply to the next spin.

Thus, my proposal would be to say:
1. Spins/variants/solutions/whatever must obey the Fedora legal guidelines and community rules.
2. A new variant must be proposed as a System-wide Change, subject to discussion with the community and various stakeholders and approval by FESCo. The change page must describe the motivation for the new variant, governance and ownership, and the differences in design from other variants/spins/editions.
3. Bold and novel variants are encouraged, even if it is not possible to say with certainty at the time of the approval whether they be delivered successfully or if users will find them useful.

Yes, this can be summarized as "we'll know when we see it", but I don't see a different way because of the reasons described in the first paragraph.

Thus, my proposal would be to say:
1. Spins/variants/solutions/whatever must obey the Fedora legal guidelines and community rules.
2. A new variant must be proposed as a System-wide Change, subject to discussion with the community and various stakeholders and approval by FESCo. The change page must describe the motivation for the new variant, governance and ownership, and the differences in design from other variants/spins/editions.
3. Bold and novel variants are encouraged, even if it is not possible to say with certainty at the time of the approval whether they be delivered successfully or if users will find them useful.

For what it's worth, this is essentially the guidance I give to people when they ask about making a new spin, except as Self-Contained Changes (plus coordination with release engineering).

The division into system-wide and not is indeed not very useful in this case. I put "system-wide" because I think a new spin/variant is something that deserves to be prominently displayed at the top of the changes list. OTOH, a new variant/spin does not impact anything else. But as a counter-argument, a contingency plan is still needed. Even if it is "drop the effort if the owners decide so at any time before the final release", it should be said to provide clarity to beta-testers and prospective users. And, as you mentioned, coordination with releng is needed. But it's not terribly important, if you think self-contained is better, I'm fine with that too.

@dcantrell, I understand where you are coming from with "explicit decision making tasks". But as I said, I don't think such enumeration is possible, because every new spin is going to be something novel and different. Let's go back to the time before ostree: if this ticket was open back then and we were trying to write some rules, I'm pretty sure we would not have been able to write something that encompassed the change to read-only transactional root. Then let's back to the time before ELN: again, I don't think the rules we would write would not be violated again. I imagine that in the future someone might want to do a spin with a different security mechanism replacing selinux. Or to use flatpaks for everything, or to provide a WSL2-compatible image, etc. The goal of Fedora is innovation, and this means breaking barriers, making it very hard to write rules that will apply to the next spin.
Thus, my proposal would be to say:
1. Spins/variants/solutions/whatever must obey the Fedora legal guidelines and community rules.
2. A new variant must be proposed as a System-wide Change, subject to discussion with the community and various stakeholders and approval by FESCo. The change page must describe the motivation for the new variant, governance and ownership, and the differences in design from other variants/spins/editions.
3. Bold and novel variants are encouraged, even if it is not possible to say with certainty at the time of the approval whether they be delivered successfully or if users will find them useful.
Yes, this can be summarized as "we'll know when we see it", but I don't see a different way because of the reasons described in the first paragraph.

I agree that it's hard to enumerate a detailed list of what defines a Fedora system, but I feel some line can be drawn. For instance, would we allow a spin to:

• Use the FreeBSD kernel instead of Linux?
• Replace glibc with musl?
• Drop all support for SecureBoot just...because?

My point is we have different categories of what we consider configurable parts of the distribution.

Taking the initial examples by @mattdm:

• The change to nano as the default does not impact me. Changing the default does not mean I have to stop using my preferred editor. What it does mean is that I can continue recommending Fedora to new users and possibly stop telling them how to use vi or emacs when a very small config edit needs to happen on a new install.

• The btrfs change is more concerning to me because while I can choose to not use btrfs, I fear the risk for Fedora. If btrfs begins to cause a lot of problems for users, the project's reputation is at risk. And a default filesystem is harder to change than a default editor.

How can we define "assessing the impact of a change" for spins? Maybe that would be worth defining.

How can we define "assessing the impact of a change" for spins?

How do we define "assessing the impact of a change" for normal Changes? Actually, we don't. https://docs.fedoraproject.org/en-US/program_management/changes_policy/ describes the motivation for the Change process, and expectations for Change owners, and the process in some detail. But it doesn't say how to do evaluation.

Use the FreeBSD kernel instead of Linux?
Replace glibc with musl?
Drop all support for SecureBoot just...because?

At least the first two items have been done in various distributions. Debian had the kfreebsd variant (that never went very far), and there are distros based on musl (alpine, gentoo as an option?, etc). SecureBoot is more of a per-component thing; I assume that there are various distros that simply don't care about so effectively it doesn't work.

I still think it's completely infeasible to prescribe the directions that new spins may create. I think all proposals are at least worth considering, and if they have sufficient justification, we might go in a completely unexpected direction.

How can we define "assessing the impact of a change" for spins?

How do we define "assessing the impact of a change" for normal Changes? Actually, we don't. https://docs.fedoraproject.org/en-US/program_management/changes_policy/ describes the motivation for the Change process, and expectations for Change owners, and the process in some detail. But it doesn't say how to do evaluation.

It's not written down, but I would say there is an unspoken expectation here of what works and what does not. We play a role in the assessment of a change and provide feedback in the change approval process. We could further define that as written rules, but I don't think we need to.

My point was can we provide guidance for spins on making changes. I feel it is worth discussing how far spins should deviate and still be considered Fedora.

Use the FreeBSD kernel instead of Linux?
Replace glibc with musl?
Drop all support for SecureBoot just...because?

At least the first two items have been done in various distributions. Debian had the kfreebsd variant (that never went very far), and there are distros based on musl (alpine, gentoo as an option?, etc). SecureBoot is more of a per-component thing; I assume that there are various distros that simply don't care about so effectively it doesn't work.

I know and that's why I mentioned these examples. We have never pursued them in Fedora, but all are technically possible. If a spin SIG decided to use the FreeBSD kernel, that presents all kinds of hardware support concerns that may or may not be relevant, but at least should be communicated and considered.

For musl, the major concern from my point of view would be that musl and glibc are not 100% ABI compatible. However, both can exist on the same system. If a musl spin wants its users to be able to use all Fedora packages, care has to be taken here.

And SecureBoot is something we have been supporting by default for a long time now. A spin turning that off would impact end users a lot these days, but maybe they know that and don't care.

In any of these cases, would we still be ok calling the spin part of Fedora? I'm honestly asking. Should there be a sub-branding off Fedora for these types of spins? I feel these kinds of changes are in an entirely different category than using a different default desktop. Or bundling a lot of field-specific software.

From my perspective, I would not want to stop any spin that wanted to try the above examples. But I am concerned about perception around the name Fedora and confusion that might occur for any new users.

I still think it's completely infeasible to prescribe the directions that new spins may create. I think all proposals are at least worth considering, and if they have sufficient justification, we might go in a completely unexpected direction.

I don't know, I still think we can categorize types of changes.

I still think we can categorize types of changes.

OK. We clearly disagree on this and I don't think anyone will be convinced by theoretical arguments. If you want to go the route of explicit enumeration, can you make a policy proposal with such a list?

Otherwise, I would take my proposal in https://pagure.io/fesco/issue/2418#comment-667545 and submit it as a PR for fesco-docs and mark it as resolving this ticket.

https://pagure.io/fesco/fesco-docs/pull-request/39

https://pagure.io/fesco/fesco-docs/pull-request/39

I've been +1 in the PR. So was @decathorpe and @ngompa.

Everyone else: please read the draft and vote.

+1 it's a good start and we can always add to it later.

+1

APPROVED (+6, 0, -0)

Announced https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HNYFH3VRR5TNSYTQ6NRGICJO3UDA7SKS/