Dennis Jacobfeuerborn wrote:
One example is the policy that patches for packages should first be
submitted and accepted upstream before they make it into Fedora.
That "policy" is only a non-normative guideline (not part of any enforced
Fedora Guidelines or Policies). The decision is purely up to the
maintainer(s) of the affected package.
This works great because that way you can ensure that once features
are
added in Fedora it is unlikely that they have to be removed later again
because they are rejected upstream. It's terrible though if you want to
live on the bleeding edge. Take for example the networking features of
OpenStack that required kernel changes that weren't yet committed
upstream or the fact that Docker required AUFS for a long time. In both
cases Fedora was a terrible platform to develop these technologies
because of its conservative stance.
In both of these examples, the affected package is the kernel. Blame the
kernel maintainers for their strict policies. Those are not Fedora policies.
In the AUFS case, there's additionally the problem that FESCo decided a ban
on separately-packaged kernel modules as a strictly enforced Fedora policy.
At the time this was decided, the understanding was that it should be
possible to get needed modules into the kernel package instead. However, the
kernel maintainers simply vetoed ALL non-upstream kernel modules that came
up do far. They do not build even the modules in the upstream staging tree!
The ban on separate kmod-* packages really needs to be repealed (for modules
with GPLv2-compatible licensing), and the current RPM Fusion kmod v2 system
picked up as a Fedora policy. We allow separate plugin packages for any
other application with a plugin system; I do not see any reason why the
kernel has to be special there.
Kevin Kofler