On 6/27/22 13:03, Thomas Haller wrote: > On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote: > >> - For "big" users (the datacenter case), changing the policy make >> sense, >> but at the same time, those folks can just insert a policy >> override, >> they're most likely using some ansible/puppet/cheffy thingy. >> - RHEL is more of the "big" case, Fedora is more the "small" case. >> Sometimes RHEL and Fedora have different defaults, sometimes RHEL >> takes years to follow what Fedora does. > > I personally care mostly about RHEL here and to find out what to do. So > if we agree that RHEL is allowed to have a different downstream > behavior than Fedora, I'd be satisfied! RHEL and Fedora *can* deviate, but I think it's valuable for them to have alignment whenever possible. i.e. if they deviate the benefit should outweigh the cost. Optimally we find a default that works best in most cases that we can share. > > >> >> So overall, I think this proposal would make most sense when limited >> to specific types of hardware (bridge and bond?), and also to >> specific >> spins: it's a better fit for CoreOS than Workstation… > > Makes sense. > > I think CoreOS would be tempted to set MACAddressPolicy=none. Thus, a > major Fedora user would go against the distro default. That raises a > question about why Workstation behaves different. But if CoreOS (or > other spins) are allowed to do that, I think Dusty would also be > satisfied. While I agree it's nice to have the flexibility to deviate on just certain variants, I'd much prefer to have the policy set Fedora wide if we can. Every delta is a cost and our goal in Fedora CoreOS is to try to not deviate from Fedora unless it really really benefits the users. The more we deviate over time the more maintenance burden we accumulate. If this change got rejected at the Fedora level I don't know if Fedora CoreOS would pick it up individually. From one perspective it wouldn't make sense: deviating from the rest of Fedora, but from another perspective it would make sense: deviating from our downstream of RHCOS (based on RHEL). Again, I'd really prefer to find a compromise here. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
