Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?
The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.
> Every time I stumble upon shitty open source code, am I supposed to fix it?
Your tone suggests that you don't want any part of this, so you continue along that path. I'm not going to convince you to start caring about your fellow men and women.
> But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.
This is an unfair characterization of what happened. Here's another version: The maintainer did not denigrate anyone, he did call the patch "boring" (which isn't really an insult or anything?), worked on his own patch (without closing the previous PR mind you). People immediately starting shitting on the maintainer - within the hour - because the PR had not been merged. Maintainer chose to delete the issue to avoid it devolving into the usual mess. More shitting contest happened here on HN, on Reddit, and elsewhere.
I would like to believe you. But without access to the actual issue in question, I have no reason to trust your account of the events over nindalf's account of the events.
To me, deleting the issue instead of disabling comments or making read-only suggests mens rea on the maintainer that their actions were out of line and regrettable, and don't suggest an effort to de-escalate the situation.
> The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well.
True, but I (and I think the other comments) referred to the top level comment here, which is a guy who just felt the code was smelly and avoided it, without having discovered anything specific.
> Your tone suggests that you don't want any part of this, so you continue along that path.
Been there, done that. The amount of excuses and other bullshit is not worth my time and effort. If the project is on github I still do open issues providing repro or at least a stack trace if possible. But if you have your own bug tracker where I'd need to sign up first (most likely going through email verification) you've lost me. Same for when you start requesting I do a git bisect even though I provided steps to reproduce or start giving excuses for why this isn't an actual bug and I'm holding it wrong. I'll just stop replying immediately.
