On Jul 28, 2017, at 11:56 AM, hw <hw at gc-24.de> wrote: > > Matthew Miller wrote: >> On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote: >>> What?s the point of doing this with Fedora? It?s not like bugs >>> were fixed before Fedora is EOL and all reports are forgotten. >> >> Many bugs are fixed in Fedora. Many more bugs are fixed in the >> upstreams. > > Contributions are usually not wanted, despite what all projects tell > you. The main reason contributions are rejected at the level of this mailing list is that they’re being offered at the wrong level. CentOS is really hard to fix directly, because virtually none of the work product of the CentOS maintainers goes into writing or patching the software that is distributed. Fixes need to happen at the upstream levels: RHEL, Fedora, or the individual software project. This list is mainly about using CentOS as we find it today, not about driving its future, because its future is largely driven by the upstreams. If you’ve been trying to get fixes into the upstream software projects, then I can tell you as the lead maintainer of a few open source software projects and contributor to many others, there are many good reasons not to accept random drive-by patches: 1. No license given. This may mean no contributor agreement was signed for projects that require it, or simply no explicit license on the contributed files. The default in the civilized world is full copyright, all rights reserved, so you can’t just put a set of changes online and expect others to merge them into the official source base. 2. ABI breakage. Many projects restrict any change that would break an ABI to major version transitions. 3. API breakage. If the project is a library, you generally can only add new interfaces, not remove or change existing ones, except at major version transitions. 4. Does not build on all target systems, no tests, patch doesn’t apply cleanly to the development branch, bad code formatting, poor variable naming, etc. Some projects will take a half-assed patch and do the finishing work on it for you, but not all will. 5. Philosophy mismatch. If your patch changes how something behaves and that behavior change doesn’t match how the project maintainer wants things to work, you’re probably stuffed. Quite frankly, your opinion doesn’t matter as much as that of the person who designed the system and has been maintaining it for the last N years. As long as that person holds well-regarded opinions, his project is likely to remain unforked, and your contribution will remain disregarded. I can summarize all of the above with, “It’s difficult to work with other people,” but that’s no particular failing of open source software. That’s just people.