What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Kevin Kofler]

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