|
|
|
|
|
|
by jcranmer
851 days ago
|
|
|
There was a talk a long time ago (sorry, can't credit it) where the speaker pointed out that some contributors end up providing net negative value to the project: the value of their contributions is outweighed by the amount of time spent interacting with them in bug reports or the like. There are two reports in this thread of the contributor here derailing a conversation with something irrelevant. Another report is of him providing low benefit/high noise patches. If you start reading the mailing list posts linked up thread, his contributions to X.org seem to be veering in this direction too: the most recent idea is to... replace include guards with #pragma once. He was called out for this by the X.org maintainers (see https://lists.x.org/archives/xorg-devel/2024-February/059159...). |
|
|
> Looking at this particular thing, what problem are you trying to solve? The existing header files already have the protection in place where it matters. And I don't expect why software that's mostly just in maintenance mode would see a lot of new header files being added.
Quite a few of his changes seemed to me to have the motivation of "I like it better this way and think you should adopt my sense of taste". If you expressed interest in becoming a maintainer of one of our not-so-well-maintained components, then sure, go nuts. But changing a bunch of stuff to your style in code that I have to continue to maintain? No thanks.
It wasn't all like this; one MR I recall changed the names of a bunch of constants so they'd be consistent with each other and what they were for (e.g. prefixing things in a certain way depending on if they were configuration key names, default values, etc.). That I do think was useful. Unfortunately I think that particular MR ended up not working out, because he never talked to me about his ideas in the first place, and I had a branch I'd been working on for a few weeks that, when merged, made his work full of merge conflicts and ultimately not as necessary anymore. And that was part of the issue: if he would have discussed the changes with me beforehand, I would have said "sure, that sounds useful, but you might want to wait a week or so until I merge this feature branch, which is going to change a lot of the code you're going to touch". But... nope, he wanted to lone-ranger it.