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

201–210 of 245 posts

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

#201

Post by andkon »

DannyBee wrote: post #179
andkon wrote: post #144

Earlier quoted context omitted.

Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems l…

I used to write it in a blog a long time ago, but that website died and i'm just too busy these days ;) Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe. IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tri…

This is really helpful. I love the idea of reaching out on long-running and getting feedback directly - that seems a great qualitative way to get a sense of what's going on, and fits well with my own experience about how to talk to early-stage customers who seem to have some value from a product I've made, but which probably isn't quite meeting people's needs yet. Turns out that's often enough to figure out the biggest, most helpful changes. Thank you!

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

#202

Post by mattgreenrocks »

ReleaseCandidat wrote: post #101
coldtea wrote: post #98

Earlier quoted context omitted.

Isn't that up to the maintainer? A maintainer might not want anybody else working on the code with them even. FOSS license != community project.

Yes of course, that's their decision. What I'm talking about that you can't expect the same contributors to a critical part of infrastructure as to a, well, more or less useless terminal emulator. You can't do the 45327th copy of something (yes, yes, I get it, it's in Rust) and behave like your project is the Linux kernel or the Rust compiler.

> you can't expect the same contributors to...[a] useless terminal emulator

Why not? A terminal emulator is probably one of the most-used apps for a lot of devs.

Plus, "useless things" can become great in time with a relentless focus on quality, understanding what their users need, and a vision for both the product and the implementation. There was a time when Linux wasn't regarded as a "real" OS, too.

Be careful of slamming unpopular projects for being unpopular. It's not a good look.

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

#203

Post by indymike »

Veen wrote: post #180
jeroenhd wrote: post #141

Earlier quoted context omitted.

I agree, but only partially. Anyone doing anything in public opens themselves to criticism, but the criticism has to be well-intentioned and valid. In this case, requirements about code quality and even refusal of code likely to introduce bugs is being called "gatekeeping" which is complete nonsense. If you refuse a merge request for good reason, you don't deserve to get shit on by some salty contributor who doesn't…

> In this case, requirements about code quality and even refusal of code likely to introduce bugs is being called "gatekeeping" which is complete nonsense. I strongly agree with you. I know gatekeeping has negative connotations and has become a sort of generalized boo word in some circles. But I'm glad maintainers act as gate keepers. Some code is crap and some coders aren't very good. Or, at least, their abilities d…

> But I'm glad maintainers act as gate keepers.

Me too, it's kind of the whole point of being a maintainer :-)

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

#204

Post by epage »

Mic92 wrote: post #130
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.

> They wanted changelogs for everything but as soon as another PR was merged it would result in a merge conflict.

I'm tempted to move to fragments that a changelog is generated from to avoid conflicts. I just haven't gotten around to exploring what tooling is out there.

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

#205

Post by indymike »

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.

> People develop confidence and expertise from repeated success at accomplishing things.

This works just as well, and has the benefit of not introducing bugs and security problems: "Thanks! I can merge this if you fix A and B."

BTW - much better to get the flywheel turning in the right direction early. It is very hard to turn a gyro once it starts spinning.

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

#206

Post by joeberon »

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.

It literally looks identical except for the border

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

#207

Post by simion314 »

mendigou wrote: post #149

Off-topic: Someone mentions in the Github comments that Rust has "self-imploded". I get it's a joke, but have there been significant bad events in the last couple of weeks?

Other issue with Rust is that the community is unable to realize that a decent standard library or an endorsed optional library with most used functionality is needed, Rust/cargo is becoming the next node/npm. Some excuses are about "perfectionism" like "we can't add json in standard library because there is a microscopic change we are stupid and do it wrong and then we have to maintain it".

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

#208

Post by SomeCallMeTim »

Etheryte wrote: post #185
DannyBee wrote: post #134

Earlier quoted context omitted.

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to ch…

My personal and very subjective opinion is that it's not my hill to die on. The majority of most things is not good, books, music, business plans, you name it. Open source contributions are the same — and that's okay. Much like I don't have a problem with people who write books I personally don't like, I don't take issue with people whose contributions don't align with what I think is good. I try to focus my energy o…

>The majority of most things is not good

"90% of everything is crap." -- Sturgeon's law [0]

The problem is that once someone has put in the time to create a PR, declining it is never going to feel good for the contributor.

Yes, they can maintain their own fork with their changes. But to be told "this doesn't work for our project," no matter how politely, is often emotionally interpreted as a form of rejection.

Which is what spawns the kind of rant above in the original link.

[0] https://en.wikipedia.org/wiki/Sturgeon%27s_law

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

#209

Post by noisy_boy »

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

I use tilix[0] - it has both tabs and split windows with excellent customization options (accessible via UI). It is quick and I haven't had any issues with it so far.

[0]: https://gnunn1.github.io/tilix-web/

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

#210

Post by abstract_put »

DannyBee wrote: post #186
zozbot234 wrote: post #177

Earlier quoted context omitted.

> 1. Integrate code that is more experimental into the development trunk > 2. Let people discover what is wrong with it > 3. Fix and iterate it This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release. In some cases, it can be acceptable to merge code that's clearly marked as experimental into…

Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them. So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really ra…

Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commons.

I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.

Post reply on HN