xz should be pretty much finished as well, major overhauls like the "ifunc" feature to inject alternate function implementations are not really justified. Beware of busybodies and this whole "the community demands vibrant evolution of the project" thing. xz does its job already!
And being rude/mean is not a plus, it's a minus, but it does seem to correlate strongly with leading a high-quality project. Even if it's not the best way, this person has the guts to say no in unequivocal terms. You might just have to accept the downside of a rude/mean maintainer as a common unwanted side-effect of an effective maintainer. (Linus Torvalds also comes to mind of course.)
It's important to note that rudeness is somewhat up for interpretation. Rejecting a patch because it's full of bugs might be considered rude to some people, but not to me. There are definitely times where Drew rubs me the wrong way, but I know he's good at what he does, and I know he's just as fed up as I am about the nonsense. He doesn't suffer fools, and that can seem rude and mean if, well, you're a fool. (To be clear, he's been totally out of line before, but I know he's been working hard to change that, and I think he's been successful.)
I've made absolutely stupid 'contributions' to open source projects in the past, not out of malice but pure ignorance.
If someone had slapped me down for being an idiot I'd have most definitely found something else to spend my free time on.
Today, I'm not super great at coding but can hunt down segfaults like a truffle pig and submit bug reports (with code) that demonstrates the exact issue if it's something I can't figure out on my own.
xz sees continual improvement to e.g. make it faster. ifuncs are an important part of that. If you want to use the garbage slow version of xz that’s up to you but I don’t think most people would want this.
> xz sees continual improvement to e.g. make it faster.
Yes, that makes sense.
> ifuncs are an important part of that.
No, IFUNCs have absolutely zero performance benefit over regular function pointers for internal functions. If anything, they can limit optimization oppertunities the compiler has with other approaches. The only benefit IFUNCs bring is being able to avoid another indirection when replacing already exported library functions in their entirety. That's what they are there for - different optimized implementations for things like memcpy in glibc.
> Redict is a Finished Product
> Drew is a controversial person
(he's been rude/mean in the past)
xz should be pretty much finished as well, major overhauls like the "ifunc" feature to inject alternate function implementations are not really justified. Beware of busybodies and this whole "the community demands vibrant evolution of the project" thing. xz does its job already!
And being rude/mean is not a plus, it's a minus, but it does seem to correlate strongly with leading a high-quality project. Even if it's not the best way, this person has the guts to say no in unequivocal terms. You might just have to accept the downside of a rude/mean maintainer as a common unwanted side-effect of an effective maintainer. (Linus Torvalds also comes to mind of course.)