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

[Dennis Jacobfeuerborn]

On 23.03.2014 03:45, Kevin Kofler wrote:
> 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.

But not every change can be implemented purely as a module.

This is precisely why I think the "one package to rule them all policy" 
should be changed for Fedora products. That way you can have the current 
kernel package policies for the regular kernel that all products by 
default use but the products that have specific needs can deliver their 
own kernel package with the required patches. As a result these products 
obviously also carry the responsibility for any problems that result 
from these changes.

That would allow products to act as incubators for new ideas and 
technologies and when these things have matured may everntually be 
folded into the core of Fedora.

Regards,
   Dennis