Server Admins: Why not Fedora?

[Bill Nottingham]

Stephen Gallagher (sgallagh at redhat.com) said: 
>  * Fedora moves too quickly!
>    Historically, Fedora's policy has always been to be among thefirst
>    to ship new technology (whether or not it's ready, but that's another
>    discussion). The problem with tracking rapidly-moving upstreams is
>    that they are not all created equally. Some upstreams (e.g. glibc)
>    obsessively avoid backwards-compatible changes between versions.
>    These are the upstreams that Fedora's current approach works well
>    for. These tend to be the low-level features of the operating system
>    that understand that compatibility == relevance. No one will build
>    atop these systems if they don't have a guarantee that it will
>    continue to work. Other upstreams (e.g. much of the Ruby and Java
>    community) tend to focus more on constant innovation without
>    consideration of backporting. This allows them to make bigger changes
>    much faster, but at the cost of constant churn and difficulty to
>    distribution packaging. These are the systems that normally expect
>    consuming applications to just bundle the exact version of the
>    library known to work. This is where we get into the "Fedora moves
>    too quickly" area of things. Whatever we're shipping in the standard
>    location on-disk tends to be preferred by the applications, and if it
>    isn't the same version that upstream wanted to bundle, all bets are
>    off.

Thre's a corollary/special case of this 'moves too quickly' idea that I've
seen - the rate of change within updates to an existing release.  I've
definitely heard both the amount of our updates, and the level of actual
user-visible change, in our updates stream is a problem for server
administrators - they feel that our releases get less stable over time after
they release.

Bill