On 5/17/20 9:36 AM, Kevin Kofler wrote:
Well, I also see a strong correlation between changes being driven,
requested and/or needed by RHEL and them being accepted by FESCo, even over
predominantly negative community feedback.
I am aware that correlation does not imply causation, but it does make me
wonder where those correlations come from, and in particular, whether
conflicts of interest play a decisive role or whether there is some other
mechanism in play here.
Some of it is a matter of resources. Fedora is a community
distribution, in the sense that anyone with the time and drive to
contribute is able to do so in some capacity. But there's a large
variation in the capacity of any individual contributor to actually make
changes. People who are paid by Red Hat and other companies, or who are
otherwise fortunate enough to be able to dedicate a large amount of
resources to work on Fedora and related technologies, are more likely to
have the time and energy to experiment with and build new tools or
technologies, integrate them into the distribution, and go through the
process of getting those things through the relevant hoops to be part of
the core distribution. And if you're getting paid by a company to do
something, it's usually because it will benefit the company in some way
(those benefits don't always have to be in conflict with the goals of
the distribution, but it's definitely a spectrum).
That tends to explain why Red Hat employees are driving many of the
larger changes to the distribution, and why they tend to be aligned with
the needs of RHEL, but not why they're being accepted by FESCo over
negative community feedback. To explain that, I think we have to look
at the change process itself.
The standard for accepting a change via the Change Process (which I
assume to be the project mission and foundations[1] - I can't find
anything specific about approval criteria in the change process
documentation) is so broad that the bar for saying "no" to a change
proposal is quite high. Unless negative feedback from the community can
make a convincing case that a change is not technically sound (and can't
be rolled back with a contingency plan), doesn't tick all of the process
boxes, or doesn't _somehow_ align with the mission and foundations of
the distribution, there's really no reason for FESCo to block a change.
Rich
[1] https://docs.fedoraproject.org/en-US/project/
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
