On Wed, 19 May 2021 at 13:55, Neal Gompa <ngomp...@gmail.com> wrote: > On Wed, May 19, 2021 at 2:45 AM Clement Verna <cve...@fedoraproject.org> > wrote: > > > > > > > > On Wed, 19 May 2021 at 06:50, Tomasz Torcz <to...@pipebreaker.pl> wrote: > >> > >> Dnia Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe napisał(a): > >> > Over the next two days we're rolling out the first Fedora 34 based > >> > Fedora CoreOS into the `stable` stream. > >> > > >> > - systemd-resolved is still enabled but not used yet [1] > >> > >> This was Fedora 33 feature. > >> > >> > - Move to cgroup v2 by default [5]. > >> > >> This was Fedora 31 feature. > >> > >> I was wondering: Fedora CoreOS actively undoes distribution-wide > >> changes (at least the two above, I remember lagging with iptables-nft > >> around Fedora 32). End user may confused, seeing the list of changes > >> for the release X, but receiving only few of them with edition CoreOS X. > >> > >> Should such divergence be allowed? Should Fedora CoreOS use the same > >> version number while not containing all the changes from main Fedora > Linux? > > > > > > I think this is the fundamental difference here, Fedora CoreOS does not > have a version number. It has 3 streams, stable, testing and next, these > streams are based on a version of Fedora Linux but that should just be a > detail that most end users should not have to care about. > > Another difference is that Fedora CoreOS has automatic updates and if we > want our users to trust these automatic updates we need them to be rock > solid. This leads to Fedora CoreOS being more conservative on how changes > are rolled out to users, taking the example rolling out cgroups v2 in the > Fedora 31 time frame would have broken all users that are using Docker to > run their containers and this was not acceptable :-). > > > > If some users are getting confused and get curious about why there are > these differences and learn more about how Fedora CoreOS works, that's a > good thing IMO :-) > > No. This is a cop-out and a bad answer.
The reason this happened is > because Fedora CoreOS historically has not participated in the > development of Fedora Linux, including the Changes process, and > generally rolled back features instead of adapting with them during > the development cycle. > I don't think it is fair to say that FCOS is not participating in the Change process. FCOS is following closely the Change Proposals [0][1][2][3]. I agree that we could do a better job at submitting Change Proposals and that's something we should improve on. One thing I have a hard time to understand tho, if what happens when a Change proposals breaks FCOS (like cgroups v2 for example) ? Should that just be rejected ? AFAIK not all changes are adopted by every Editions or Spins. What is in your opinion the correct way forward ? > > It's not like making changes and breaking upgrades is acceptable in > Fedora Linux either. Breaking or non backward compatible changes are acceptable in Fedora Linux tho between major version bump. Again here the cgroups v2 is a good example, folks using Docker had to perform some manual steps to switch back to cgroups v1 to keep using their workflow working. This is fine when you have a major version bump but this does not happen in FCOS. > It's just that the Fedora CoreOS WG has not > participated in the main development process and rolled back changes > instead of adapting to them, which has frustrated pretty much > everyone. The containers team in particular was extremely unhappy to > find out cgroup v1 was still used in FCOS. I was pretty cheesed off > when I discovered the sqlite rpmdb feature was rolled back in FCOS. > > In general, I'm not pleased with how Fedora CoreOS does this. > Hopefully they will do better in the future. > [0] - https://github.com/coreos/fedora-coreos-tracker/issues/372 [1] - https://github.com/coreos/fedora-coreos-tracker/issues/609 [2] - https://github.com/coreos/fedora-coreos-tracker/issues/704 [3] - https://github.com/coreos/fedora-coreos-tracker/issues/824 > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
