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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux