Five basic principles for Fedora, from a server perspective.

Bill Nottingham notting at
Thu Sep 2 18:25:24 UTC 2010

seth vidal (skvidal at said: 
> > 2. Avoid Churn at the Core
> > 
> >    It may be that in order to best provide for the typical Fedora user,
> >    frequent updates are a necessity. But Fedora should place extra emphasis
> >    on keeping the base of the operating system from changing within a stable
> >    release.
> >
> >    This makes system changes more auditable, and keeps security and
> >    important bugfix updates from being lost in the noise. It reduces risk
> >    from accidental new bugs or from incompatible version changes.
> Should the churn be avoided BETWEEN releases, too? Ie: f13->f14 should
> we avoid core churn?

That appears to define that there should *never* be core churn. To cherry-pick
examples at random, that means:

- we never add yum?
- we never introduce PAM?
- we never add sssd?
- we never switch to udev?
- we never switch from ipchains to iptables?
- we never switch from ext2 to ext3 to ext4?
- we never switch from sysklogd to rsyslog?

Obviously, some of those are pretty old. But at the time, they were the
same sort of large-scale changes that affect the way the system operates,
affects the commands an administrator might use, and affects the
configuration files that would need to be edited. I understand being averse
to large scale change, but this seems to be
skewing against our listed Foundations:

Features represents our commitment to excellence. The Fedora community
creates many of the technical features that have made Linux powerful,
flexible, and usable for a wide spectrum of  millions  of users,
administrators, and developers worldwide. We recognize the status quo is
worth changing when the potential gain is to empower additional end-users,
or create a more flexible and powerful environment for building new
solutions on the free software we provide.


More information about the server mailing list