Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gist.github.com

Post reply on HN
Print view View original

121–130 of 245 posts

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

#121

Post by whimsicalism »

c7DJTLrn wrote: post #24
ay wrote: post #20

Earlier 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.

Literally this article?

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

#123

Post by ziotom78 »

konart wrote: post #68
hiyer wrote: post #14

I used to use kitty, but its CPU usage was on the higher side on my laptop. I tried alacritty but the lack of tabs (after using kitty for a long time) was a deal-breaker. I'm currently using Wezterm[1], another rust-based terminal, which has tabs. It's worked great for me so far. 1. https://github.com/wez/wezterm

for some reason wezterm is very slow for me. I can see how neovim window is being drawn...

Same for me. I installed it and checked how long it would take to `echo` a million random strings. It was significantly slower than Kitty, so I stuck with the latter. Hope it improves, because I loved the approach!

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

#124

Post by klelatti »

OJFord wrote: post #113
klelatti wrote: post #109

Earlier quoted context omitted.

> 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. It's not about PRs. Read it carefully. It's a comment about 'most programmers' who apparently don't have characteristics that mean they can do anything but produce 'bug ridden garbage'.

The previous sentence was: > The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping. i.e. the context is reviewing (however that's done) contributed code.

Well they could have said 'Most PRs are bug ridden garbage' - stronger than I would use but fair enough.

But no, it's a comment on the characteristics of people contributing to projects.

It's saying that they are not capable of making a quality contribution.

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

#125

Post by nixpulvis »

DoubleFree wrote: post #65

This reminds me of a blog post from Aleksey Kladov: https://matklad.github.io/2021/01/03/two-kinds-of-code-revie... They state that reviews are not only meant to ensure good code, but also good coders. That means mentoring, but also merging the code if it's not perfect. Then, afterwards, when touching the affected part of the code again, cc the original author in a fixup PR. I have first-hand experience with this way…

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 your case. Typically, show your own work. The best review points clearly towards a better result.

Finally, acknowledge your own limitations as a reviewer. We're all human, to pretend otherwise does yourself and others a massive disservice.

(But what do I know. I've been out of the game for a while now.)

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

#126

Post by visarga »

jpe90 wrote: post #90

"The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects. Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager. As a user of something open source you are not thereby entitled to anything at all. You are…

> you are not thereby entitled to anything at all.

well, technically you are entitled to the source code

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

#127

Post by tayo42 »

This is part of what i think is a problem with rust. Where all of these important features are left to volunteers in the community to come up with. A lot contributors seem to be unprofessional or hobbyist/amateurs. Like some of these issues in the pr really aren't "perfectionism". Then this guy trying to make projects look bad seems childish because he isn't that great at programming. Maintaining a open source project and being good at coding aren't really overlapping skills. Two years to merge something seems like a failure on both parts. The maintainers should have said something in the begging and set some expectations too.

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

#128

Post by nixpulvis »

thenoblesunfish wrote: post #79

I use Alacritty exclusively, and knowing that the maintainer is discerning makes me like it even more. I'm getting what I signed up for, which is a project which cares deeply about doing a few things very well. I think that an unstated implication of that ethos is that there will be plenty of things that you would like to do, but upon some amount of investigation don't see how to do well enough, so you don't do them…

I have the utmost respect for Chris.

One thing I've learned from working with him a little bit was that there's a huge importance to both the medium and the timing of the message. Balancing even just IRC and GitHub PR comments is a tough game to play, but it must be played if you want to be successful. Treating PRs like IRC will get you in trouble, while reading IRC like a PR might leave you in the dust. Knowing when to move an argument from IRC to a longer form like a PR or Issue is a critical skill (one I never was very good at).

Chris and team, if you happen to read this. Thanks again for all that you do.

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

#129

Post by the_gipsy »

Welcome to FOSS, where we don’t just merge every single shitty feature by sheer enterprise-momentum. The fact that someone put in the effort, or spent man-hours, or “absolutely needs it ASAP”, does not outweigh the goals of the maintainers.

This is the reason why FOSS survives the test of time so well. At least quite a bit longer than enterprise software, which commonly has to be rewritten next year.

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

#130

Post by Mic92 »

epage wrote: post #108

I've recently left a Rust project and the maintainer's perfectionism was one part. From my observation, the causes tend to be: - Maintainers spread thin, putting more of a burden on contributors - Some projects being critical and needing more attention and some taking themselves too seriously (dealt with a project whose CI took a couple hours for ~60 jobs because they exhaustively tested every combination. - Maintain…

Yep. Second this. I also stopped contributing to rust-nix for the same reason. CI took forever. They wanted changelogs for everything but as soon as another PR was merged it would result in a merge conflict. Whenever I need a libc function not available in rust-nix I just add the abstraction to the project itself - this way I also don't have to care about someone else breaking my code by changing types.
Post reply on HN