Rust maintainer perfectionism, or, the tragedy of Alacritty (2020) • Hacker News Board

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#211

Post by kopipe » Fri, Nov 26, 2021, 5:11 PM UTC

Hello—

I'm the author of this post, I did not intend for it to receive wide circulation, and only have shared it in the past year with a few friends and MFEK users to explain my views on forking in Rust, why MFEK relies on so many vendorized crates etc.

I added some more recent commentary to the comments of the Gist: https://gist.github.com/ctrlcctrlv/978b3ee4f55d4b4ec415a985e...

I have also updated the Gist itself with a note:

> I did not submit this to Hacker News and did not intend that this post would have high circulation but have no real problem with it being there or with it having such. I have [more recent comments below](https://gist.github.com/ctrlcctrlv/978b3ee4f55d4b4ec415a985e...). This post is from January 2020 and predates the Modular Font Editor K (MFEK) project.

Cheers.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#212

Post by setpatchaddress » Fri, Nov 26, 2021, 5:14 PM UTC

speed_spread wrote: post #143

akagusu wrote: post #2

And the honeymoon is over.

This isn't specific to Rust. PRs are hard, people want different things, nothing is free, etc.

This, so much. I maintain corporate, closed-source components which are central to my org’s mission and have to request radical changes on PRs submitted by other teams on a frequent basis. It’s really not “perfectionism” to avoid introducing serious maintenance issues and bugs long-term.

This is like jwz’s interaction with the emacs team decades ago — the story was that the emacs team was being unreasonable about merging some changes jwz/Lucid wanted. If you actually read the correspondence, turns out jwz wasn’t listening to review feedback. The feedback was completely technically reasonable from a maintainer’s perspective and jwz/Lucid just wanted the code merged without consideration for the emacs team’s future plans.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#213

Post by SomeCallMeTim » Fri, Nov 26, 2021, 5:20 PM UTC

khalladay wrote: post #171

bluedino wrote: post #142

Earlier quoted context omitted.

It's a harsh reality. The best team can't be welcoming to sub-par players. At least not on game day.

This is a weird stance to take. Software development is not sports. There is no "game day," and the best teams I've worked on have managed to treat folks with respect while still maintaining a high degree of quality. You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk…

>You can treat people kindly without having to agree with their opinions, or taking their PRs.

I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good.

So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting.

The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor.

So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#214

Post by stormbrew » Fri, Nov 26, 2021, 5:21 PM UTC

jasode wrote: post #182

stormbrew wrote: post #169

Earlier quoted context omitted.

.. Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through and it would still seem like there were no barriers. This is just survivorship bias.

>Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that…

While that's true, do you think maybe a few things have changed about the nature of coding or open source in the intervening 30 years?

Anyways, I'll ignore for the moment that your argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant, because either way it doesn't hold water.

Even by 1995 Linux was already on its way to becoming a juggernaut, so the window of time in which Linux was "small" is pretty short in the grand scheme of things, and I think a convincing argument could be made that of the "free OS for x86 machines" projects that existed in the early 90s, linux was actually the easiest to contribute to for various reasons. I think it's actually likely to be an example of the opposite of what you're suggesting, which seems to be that "friction causes no harm". We might all be using something derived from 386BSD or Mach (perhaps even HURD!) if that were the case.

In other words, I don't think "Linux in 1991" is a substitute for an argument about "Alacritty in 2021". There is very little in common between these two projects or circumstances.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#215

Post by cma » Fri, Nov 26, 2021, 5:29 PM UTC

DannyBee wrote: post #164

zozbot234 wrote: post #151

Earlier quoted context omitted.

"Accepting" a pull request means merging it, and broken code should not be merged. By all means feel free to propose improvements to the PR, then merge it. And if achieving a reasonably well-defined standard of correctness (i.e. avoiding complete and utter breakage) is not feasible, the PR should be scaled back until it becomes so. Start with the minimum useful change, then expand on it.

Broken is a very loaded word. So i don't agree with this as written. If by broken you mean "does not compile or pass tests", then fine, sure. If by broken you mean "there are likely some hard issues in there", then no, i don't agree. I've watched plenty of really good software where the dev process amounts to: 1. Integrate code that is more experimental into the development trunk 2. Let people discover what is wrong…

A terminal emulator has security implications.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#216

Post by akio » Fri, Nov 26, 2021, 5:31 PM UTC

chrismorgan wrote: post #117

antihero wrote: post #51

Ha, trying to get Alacritty to have a native-feel icon for macOS which had basically zero drawbacks and most other applications do was met with a straight up NOPE. Not up for debate, people supplied the assets and I even made a PR, nope, closed. Even though it was in a directory full of platform specific stuff (Alacritty.app resources), it was decided that it couldn't differ from the other icons, so Alacritty has to…

[Edit: I wrote some stuff earlier based on other PRs that were done even worse, before I found #3926, so I’ve deleted that other stuff as unlikely to be what’s referred to.] I’m guessing this is about https://github.com/alacritty/alacritty/issues/3926 . I can well understand this being knocked back; as a non-user of macOS I would knock it back too. The main proposed option is frankly a fairly poor reimplementation of…

> The main proposed option is frankly a fairly poor reimplementation of the logo and loses too much of the character of the original logo.

As the designer of the original Alacrity icon[0], the icon proposed in your linked #3926 is close to how I would design the icon for macOS today (although I prefer semanser's version in #4726[1]).

I respect chrisduerr and the talent and monumental effort he's put into maintaining Alacrity over the past couple years, but shutting down the macOS icon proposals—which do not increase the maintenance burden of Alacritty and are obviously strongly desired by Alacrity's macOS users—is not reasonable.

[0]: https://github.com/alacritty/alacritty/issues/285#issuecomme...

[1]: https://github.com/alacritty/alacritty/pull/4726#issuecommen...

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#217

Post by akagusu » Fri, Nov 26, 2021, 5:33 PM UTC

speed_spread wrote: post #143

akagusu wrote: post #2

And the honeymoon is over.

This isn't specific to Rust. PRs are hard, people want different things, nothing is free, etc.

It is not specific to Rust of course, and it happens all time with open or closed source software, but it get interesting when people start to rant in public.

It is like marriage. Everything is fine in the honeymoon, even when it is not, but after that, things start to get a little messy.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#218

Post by nixpulvis » Fri, Nov 26, 2021, 5:36 PM UTC

bluesnowmonkey wrote: post #184

nixpulvis wrote: post #125

Earlier quoted context omitted.

Why not simply have the discussion in the review itself? Must we merge everything, just so people feel empowered? It's chaos to have to constantly revert and/or refactor everything. People should be empowered not by the merge, but by the progress. They key, from what I've seen, is to facilitate useful conversation. Keep comments relevant and people will learn. Avoid politicking, while still providing evidence for you…

> Must we merge everything, just so people feel empowered? Sort of, yes. People develop confidence and expertise from repeated success at accomplishing things. Success creates confidence creates more success. You have to give people room to get that flywheel spinning for themselves.

I can tell you from recent experience, merging something only to have it reverted later is a net confidence loss.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#219

Post by ccchapman » Fri, Nov 26, 2021, 5:37 PM UTC

Massive respect to the Alacritty team for holding true to keeping it the most reliable and performant terminal emulator. It is my daily driver and I am grateful for the high degree of care held within its community.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#220

Post by jasode » Fri, Nov 26, 2021, 5:42 PM UTC

stormbrew wrote: post #214

jasode wrote: post #182

Earlier quoted context omitted.

>Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that…

While that's true, do you think maybe a few things have changed about the nature of coding or open source in the intervening 30 years ? Anyways, I'll ignore for the moment that your argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant, because either way it doesn't hold water. Even by 1995 Lin…

> argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant,

No, my argument was about the entire timeline of Linux kernel which was a continuation of gp's (xyzzy_plugh) example when he wrote: >Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years.

I just picked one random example from the last 20 years that happened to be from 2014. It could have been any of the hundreds of harsh messages in the USENET archives of 1990s of Linus and others berating people. Linus's tone was even more hostile before 2014.

> what you're suggesting, which seems to be that "friction causes no harm".

I'm not suggesting that at all. Instead, I'm pointing out that the gp's mental model of new & incompetent programmers not "attempting to contribute" because of an unwelcoming atmosphere is not correct. The Linux kernel has always had newbies attempt to contribute bad code even when it was a "toy project" compared to Alacritty.

To put it another way using a reverse perspective from gp (klelatti): A project that publicly advertises its dismissive attitude towards incompetent programmers also _attracts_ a certain subset of programmers who think they can meet the high bar to contribute. This counterintuitive reverse psychology does not seem to be included in his mental model.