-----BEGIN PGP SIGNED MESSAGE-----
One of the oft-repeated statements about Fedora is that it's "not good
for running a server". Clearly, as we embark upon a mission to change
that fundamental belief, we need to start addressing the problems that
make Fedora unsuitable to so many people.
I propose that a good place to start here is to carefully enumerate
the reasons people elect not to use Fedora in their server
environments. Let's start by gathering the surface problems (in some
cases, the cargo-cult explanations) and look into what is the real
underlying problem and how we can fix it with the Fedora Server offering.
To get us started:
* 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