I do think the pendulum has swung a little too far towards perfectionism now. I notice it with static typing in languages too. Some of the discussions about what the "correct" way to encode the problem into the type system are leaning towards insane. Yes, we like software for its own sake and it has the potential to be beautiful, but at the end of the day it is supposed to be there to get things done. It's lovely when you find a design that both meets its specification fully and is completely elegant. But focussing on one thing at the expense of the other isn't going to solve any real problems. An extreme position is rarely a good thing.
Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
31–40 of 245 posts
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#32I have also experienced this frustration and it has turned me away from projects before. There is always some reason to block a PR. However, I found that creating my own open source projects helped me sympathise with maintainers of popular projects. I think of it this way: Say you work at a company and there is a lot of work to do. The bar can be low for accepting PRs because it is assumed that the author will stick…
> The bar can be low for accepting PRs because it is assumed that the author will stick around to fix any issues they caused and you have to deliver so in it goes.
On the other hand it can be high because you’ll be the one on call when it blows up in production, or having to scramble with an emergency security fix.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#33I'm perfectly ok with a maintainer reserving to himself the right to modify or even force-push a PR. If feature-wise the PR has value, but there are other requirements that have to be meet in order for it to be mergeable, I see no problem in the maintainer making his hands dirty. This contributor's work is recognized, and the maintainer can keep growing the project the way he wants.
Not every occasional contributor will become a project member, so it makes no sense to impose too much burden on him. Maybe he only wants an interesting feature added.
Some of them will eventually become interested in becoming regular contributors, and that is even better, but every one should be left freedom of choice.
In my experience as Etherpad maintainer (1.6.5 through 1.8.4) this approach worked very well. For example https://github.com/ether/etherpad-lite/issues/3540 (and the related PR https://github.com/ether/etherpad-lite/pull/3559) where deep changes that went very smooth, not only code wise, but above all wrt the relation with the contributor, who was smart and collaborative.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#34The issue with many open-source projects is that most maintainers are of the philosophy of "let's ship it, we can improve it later" for their own code, while they expect incoming PRs to be perfect, to handle all corner cases, past and future, or else they'll be stuck in limbo, unanswered or picked apart over months, one line at a time, until they ask for a perfect implementation which requires 10x the time investment. All for fixing a bug that might affect people.
I admit I personally have never participated much in open-source development because, even as an experienced software engineer; I've never had many good experiences with merging code into public repositories, unless it's a very small project, where contributions are very welcome, because the level of perfectionism maintainers require from first time contributors kills any enthusiasm one might have even in the smallest of changes.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#35“They don't want to merge my code with unsafe and I can’t prove it's actually safe”. 2 examples extrapolated to the whole community and language. Is there any particular reason to resurrect it from 2020?
It's only two examples given in this post, but I think it's just reasonable to assume there are many more examples the author could give otherwise I doubt they would take the time to write about it... also, if you've been trying to participate in open source Rust projects, you know it's not just these two projects.
Just open the link to PR - the author is arguing that unsafe code should be merged but doesn't mention it in his rant. Skepticism about unsafe code is not perfectionism.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#36I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…
“Gatekeeping” is a requirement for good software. One man’s nitpick is another man’s deeply held value, especially if one is a newb and one is a maintainer and/or has a legitimate long term vision for the project.
Not saying this is the case here but there are two ways to look at it.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#37fwiw i think the last time i rebuilt alacritty was a year ago or more, and i can’t say i’ve felt the burning desire for new features or anything…
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#38The author raises an interesting argument, but I don't see how the "maintainer perfectionism" issue is specific to Rust in particular.
Indeed, the two examples they mention are both related to Rust somehow, but is it enough to generalize to the whole Rust ecosystem?
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#39> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact.
I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct.
This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You can't just call library functions from a multi-threaded context without understanding if they're thread safe or not, if they're reentrant, without using appropriate buffers or handling errno correctly.
Well, you can, of course. But then you have bugs, and crashes, and race conditions.
I don't mean to come off harsh but this is pretty bog standard stuff. Maybe the author is new to all of this, maybe not, but complaining about perfectionism when the issues being raised are almost entirely real actual issues really rubs me the wrong way.
Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years. The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping. The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. I don't think any project maintainer ever wants to accept contributions that make their life harder.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#40Earlier quoted context omitted.
I think a lot of people treat the merge of a PR as their god-given right. Because they spent time on it. But if they spent the time without discussing with the maintainer first, why would they be obliged to merge it ? It is like spending a ton of money on a big, bulky, but useless to a recipient present, giving it to someone and then complaining that they don’t take it - you had spent all this money! The way out of t…
>I think a lot of people treat the merge of a PR as their god-given right I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.
I have seen this “non-zero” times - not common, but it exists.
Some folks are insistent that their PR and their specific problem be addressed by your project, and the effort they put into writing code before discussing it just increases their attachment.