Warren Young wrote:
On Jul 28, 2017, at 11:56 AM, hw <hw@xxxxxxxx> 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.
Sometimes a mailing list is just the right place. It´s not like you could stuff
everything into bug reports or feature requests.
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.
Another reason is that nobody cares about fixing something. It doesn´t matter
what the reasons are.
All the projects asking for help on the one hand and experiencing that attempts to
contribute are encountered with unkindness on the other is a contradiction.
So why bother, and knowing that the asking for help is nothing but a fake brought up
for unknown reasons makes me even less inclinded to do anything because it is dishonest.
They´d better just say they don´t want help. They are doing what they are doing
for their own reasons, and they will do whatever they see fit. Why should I bother
anyone with contributions.
BTW, the default of full copyright may exist somewhere on paper, like so many other
things. Since it´s impossible to claim it, the default is of course not to give out
anything I don´t want others to use.
The projects you´re involved with, are any of them asking for help? If so, why do
they ask, and how do they take it?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
