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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
