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

231–240 of 245 posts

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

#231

Post by purple_turtle »

DarylZero wrote: post #223
purple_turtle wrote: post #189

Earlier quoted context omitted.

And, additionally, if someone is unwilling to fix known issues in PR - then they will definitely not fix bugs in it after it become merged. So for maintainers merging PRs with known issue is basically promising to fix everything not finished.

To the contrary, a developer is MUCH MORE likely to fix bugs in merged code that has users, than in an unmerged PR. It's the users that give motivation to work on the project. Working on a PR is like working on spec. Working on the development branch gives you direct access to the "payment" of users using your code.

ok, there are two different effects in action:

- creators are more likely to abandon or ignore projects that have low popularity or are completely unused - creators are more likely to be burned out when there are piles of demands, requests, complaints etc

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

#232

Post by purple_turtle »

ReleaseCandidat wrote: post #194
purple_turtle wrote: post #148

Earlier quoted context omitted.

> This _should_ be exactly the type of project where people can get their first OSS programming experience. It is 100% up to maintainer of a given project, they are not obligated to do this. People are 100% free to pursue sky-high reliability and bugfreeness in their project, no matter what it is.

> People are 100% free to pursue sky-high reliability and bugfreeness in their project, no matter what it is. Of course they are. But they should not complain that the only people interested in their project are, well, not super-star programmers but beginners. In other words: they can wait for the other programmer who is almost ;) as perfect as they are. But chances are these people are not interested in the 4535th c…

Well, in this case rant was not published by maintainer.

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

#233

Post by GekkePrutser »

EugeneOZ wrote: post #21
GekkePrutser wrote: post #8

A lot of their comments seem justified though and it looks like you were learning a lot from it as you mentioned it was your first rust merge. Also a lot of the delay was because you didn't have time to work on it as you mentioned in 2019 :) I'm not a developer but I read through the thread to see what it's about. But I think most comments were constructive criticism or just non blocking suggestions even. Though code…

It's the author of 8chan, so libel is not surprising here.

I had no idea about that but his responses to the issues and his blog post are pretty polite and reasonable IMO.

Though like I said I don't agree and I think the devs merging it had justified concerns.

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

#234

Post by DannyBee »

cma wrote: post #215
DannyBee wrote: post #164

Earlier quoted context omitted.

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.

So? Lots of things do. Good programming practice would be to carefully segregate the security parts of it from the non, and keep that part small and carefully thought out.

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

#235

Post by martinhath »

doteka wrote: post #47
rtfeldman wrote: post #28

Posts like this are major contributors to maintainer burnout. Whatever value they have as a signal boost is a rounding error compared to the harm they cause to individuals as well as to the culture as a whole. Please don't ever post things like this. If you're this frustrated that the people who make free things for you aren't donating their time to you in the way you'd prefer, grab a drink with a friend and vent to…

Nope, sorry. Maintainers are not above criticism just like anyone else, and this post did so in a respectful way. It’s a real problem and e.g. the reason we have stopped trying to upstream any fixes to OSS libraries at work - it’s in no way worth the effort to jump through these hoops, take our bugfix or leave it.

> take our bugfix or leave it.

Why do you think people should unconditionally accept code into their own codebase? Your wording also suggests that you think the maintainers are somehow leading you on to doing more work. Have you considered how much work doing proper review is?

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

#236

Post by cryptoboy2283 »

brabel wrote: post #135
cryptoboy2283 wrote: post #74

Earlier quoted context omitted.

Could you share the link to your blog post?

Are you joking? Do you want to join the angry crowd?

Nope, currently learning Rust, really would love to read the articles about best practices & hidden costs

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

#237

Post by yencabulator »

catting a file in kitty can delete files from /tmp [1]. I don't think Kitty's enthusiasm for merging features without thinking about them hard enough is a good way to go either.

[1]: https://github.com/kovidgoyal/kitty/blob/2350952d054bcaf945a...

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

#238

Post by oreally »

mixedCase wrote: post #91
oreally wrote: post #83

Earlier quoted context omitted.

'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias. Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Ge…

That's what code review in a PR is for. Iterate all you need, and people experienced in the codebase will help you point out your mistakes so you can iterate some more until the maintenance burden you're shifting onto someone else is reasonable.

Sure you can do it in a PR. But this assumes that the feature is tested in isolation and not in conjunction with the rest the software. And the software really should be worked on as a whole.

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

#239

Post by couchand »

DannyBee wrote: post #222
abstract_put wrote: post #210

Earlier quoted context omitted.

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 commo…

My bias is from watching a lot of smart people experiment well. I think you are not wrong in the limit, but it's a bit more complex than that: 1. You need to set expectations up front of what it means to contribute. 2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient…

To bring it back to the article, this really seems like one of those "get it in and run away" cases. Or to be a bit more accurate, run away before getting it in...

The author made a number of comments on the PR about how they expected it was almost done while there were still outstanding concerns from maintainers. The author stopped responding to comments when their employer's priorities changed. Someone else volunteered to finish the author's incomplete work, then the author closed the PR, complaining about being tired of seeing it in their PR list.

The maintainers spent a fair amount of effort explaining many (basic Rust) things like the extremely unsound API design of dereferencing a user-supplied raw pointer. They were trying to help.

This just doesn't seem like an individual the maintainers have any reason to trust.

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

#240

Post by couchand »

jszymborski wrote: post #174
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…

I don't think F.Brennan (OP) is making any demands here. He's simply commenting on a pattern of forsaking the good for the perfect in a lot of repositories that, in his opinion, cause them to stagnate. I see no expectations, or demands in this post. Only disappointment at what OP sees as a missed opportunity. OP is a pretty prolific contributor to open-source, and I get that ones purview doesn't extend past ones owns…

This isn't about perfect vs. good, though. The PR as initially written was unsound. The maintainers worked to help point out the deficiencies. The author gave up and wrote a blog post rather than finishing it.
Post reply on HN