Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)(gist.github.com)
gist.github.com
Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
https://gist.github.com/ctrlcctrlv/978b3ee4f55d4b4ec415a985e01cb1c9
244 comments
I actually have experience with this specific code. I recently fixed a bug in a function that his PR also touches: https://github.com/nix-rust/nix/pull/1521
And I have a PR to fix problems in another Rust wrapper of the same libc functions: https://github.com/uutils/coreutils/pull/2653
It's hard to get right. Skimming the PR, the feedback looks reasonable.
And I have a PR to fix problems in another Rust wrapper of the same libc functions: https://github.com/uutils/coreutils/pull/2653
It's hard to get right. Skimming the PR, the feedback looks reasonable.
> 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.
Whether or not you are right on this issue is this really the way to generalise about current / potential contributors?
Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
Edit: I’m making no point about quality or otherwise of contributions or whether maintainers should accept them. Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.
Whether or not you are right on this issue is this really the way to generalise about current / potential contributors?
Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
Edit: I’m making no point about quality or otherwise of contributions or whether maintainers should accept them. Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.
I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time.
I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed.
And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.
I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed.
And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.
> You need at least one of the three: patience, skill, experience.
I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there.
His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"
I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there.
His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"
> bug ridden garbage
> expect to be treated kindly
Do you see why the first might make someone doubt the second?
> expect to be treated kindly
Do you see why the first might make someone doubt the second?
I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors.
If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage.
It takes time and patience to refine it into something good. It doesn't mean you shouldn't try.
If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best.
Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade.
If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage.
It takes time and patience to refine it into something good. It doesn't mean you shouldn't try.
If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best.
Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade.
If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.
Sometimes honesty and truth can hurt. Sometimes you have to accept that and move on. Alternatively you can coddle people so that they think every thing that they do is wonderful and a gift to all of mankind. Or you can take offence at honest criticism everything and ... well here we are. Word policing, and overbearing nicety as form of karma currency are not good things. Adults sometimes call each other not nice names. The world is not a cosy blanket left in the sun covered with kittens.
> Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind
Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
This really describes quite well why Rust is such a joyful language to work in. You might still write garbage, but the compiler constrains the types of garbage you can write to a much smaller subset.
Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved.
If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors.
But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions.
A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way.
Rust offers all of these.
Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved.
If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors.
But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions.
A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way.
Rust offers all of these.
>Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind
Or an accurate depiction of reality.
Or an accurate depiction of reality.
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. 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.
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.
'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. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
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.
Because you want to be able to make high quality contributions, you want to learn?
If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine.
Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?
If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine.
Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?
> bug ridden garbage
This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
I don't know about you, but I think I'm capable of polite conversation with someone whom I believe to be talking nonsense; or being friendly in discussing something I think is no good.
(In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they want in, and surely they'd see the problem, I don't think it looks like gate-keeping pedantry? (NB the repo was unmaintained, I was recently added as a collaborator, so older issues/PRs with no maintainer response aren't a counter-example, I'm just in the process of sorting through them.))
The author of that comment was talking to us about low quality PRs, not a specific one, to an author of one, nor in feedback comments on one.
(In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they want in, and surely they'd see the problem, I don't think it looks like gate-keeping pedantry? (NB the repo was unmaintained, I was recently added as a collaborator, so older issues/PRs with no maintainer response aren't a counter-example, I'm just in the process of sorting through them.))
The author of that comment was talking to us about low quality PRs, not a specific one, to an author of one, nor in feedback comments on one.
> 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'.
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.
> 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.
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.
It's saying they are not capable of making a quality contribution without criticism/review.
Your reply here is some serious pedantry, you're essentially arguing that the output of most programmers is totally disconnected from the abilities of most programmers.
Really, what other relevant external indicators of the abilities of a given programmer does anyone have access to besides the code they output?
Your reply here is some serious pedantry, you're essentially arguing that the output of most programmers is totally disconnected from the abilities of most programmers.
Really, what other relevant external indicators of the abilities of a given programmer does anyone have access to besides the code they output?
1. Your PR is bug ridden garbage.
2. You don't have the patience, skills or experience to write anything other than bug ridden garbage.
Not pedantry at all so see a big distinction between these two statements.
In fact almost a textbook study of how to / how not to give feedback.
2. You don't have the patience, skills or experience to write anything other than bug ridden garbage.
Not pedantry at all so see a big distinction between these two statements.
In fact almost a textbook study of how to / how not to give feedback.
Those are both hypothetical statements directed at an author, which nobody here has done or advocated doing.
And regarding 2, the original was a general statement about the existence and prevalence of (low) skill; not an indictment against any specific author of 'garbage' who may (or may not) be capable of better.
And regarding 2, the original was a general statement about the existence and prevalence of (low) skill; not an indictment against any specific author of 'garbage' who may (or may not) be capable of better.
> It's saying that they are not capable of making a quality contribution.
But isn't that true? At least not right away, which is why the code gets reviewed. I'm pretty sure everyone writes bug ridden garbage, unless they're not already intimately familiar with the codebase already.
But isn't that true? At least not right away, which is why the code gets reviewed. I'm pretty sure everyone writes bug ridden garbage, unless they're not already intimately familiar with the codebase already.
The feedback can be very constructive despite the language.
Or even because of it - as this kind of language can mean "I wont sugarcoat it, I'll say it like it is".
It's up to the receiver of that feedback to be able to see this.
Or even because of it - as this kind of language can mean "I wont sugarcoat it, I'll say it like it is".
It's up to the receiver of that feedback to be able to see this.
Yes, that sounds like it is going to be completely constructive and straightforward discussion.
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, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the maintainers, both in reviewing the contribution and then later on maintaining it. If the contribution is good, it offsets those costs, but oftentimes it is not the case. Don't get me wrong, there are countless brilliant people out there who are doing great work more or less for free in the way of contributing. I'm also very grateful for good contributions. Those contributions are the exception though, not the norm.
[0] https://en.wikipedia.org/wiki/Greek_gift_sacrifice
[0] https://en.wikipedia.org/wiki/Greek_gift_sacrifice
A lot of disgruntled contributors also forget that beyond code quality, projects have opinions, and their PRs opinions may be incompatible... We need to be grateful even when maintainers disagree with us, because opinion soup makes for bloated, unfocused, buggy, crappy software.
Perhaps this part explains all the commotion around rust... being a popular new language with strong opinions, but today there is a lot of entitlement going on in software communities, assuming that it makes sense to integrate inclusivity to such a degree that it's actually incompatible with what makes a cohesive opinionated project.
Perhaps this part explains all the commotion around rust... being a popular new language with strong opinions, but today there is a lot of entitlement going on in software communities, assuming that it makes sense to integrate inclusivity to such a degree that it's actually incompatible with what makes a cohesive opinionated project.
> but today there is a lot of entitlement going on in software communities
I'd generalise it: There is a lot of entitlement going on right now.
I'd generalise it: There is a lot of entitlement going on right now.
"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 change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try?
I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.
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 change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try?
I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.
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 like time well spent for everyone.
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 like time well spent for everyone.
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 tried anything specifically.
In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement.
Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;)
But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people.
There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people
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 tried anything specifically.
In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement.
Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;)
But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people.
There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people
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!
A lot of the time making a contribution that actually helps means fixing something foundational rather than bolting on another quick bug fix.
That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.
A lot of contributions to open source are simply worth what you paid for them, which is nothing.
Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.
That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.
A lot of contributions to open source are simply worth what you paid for them, which is nothing.
Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.
I often encounter foundational or complex issues (incorrect memory management, deep complexity) when trying to diagnose crashes in open-source apps. And I get frustrated trying to understand deep complexity is frustrating, and maintainers (who haven't looked into the crashes so far, and in one case fixed an earlier crash based on me debugging it for them) don't take it kindly when I complain about the unmanageable complexity and poor stability of these apps. What should I do in this case? Take a break then keep trying? Slow down debugging and spend more time reading and taking notes? Abandon the project, and switch to using/contributing to codebases I find simpler/more cohesive and easier to understand?
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 on the ones that I find good, or at least the ones that look like they might end up being good. To perhaps put the same idea another way, if someone wants to put in the effort for making a change, it's their choice to do so. It is also their choice whether they take the time to do it well. If they didn't want to put in the work, it doesn't bother me, it's their time.
>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
"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
I think that's a fine viewpoint, and one i take with many projects, and try to be clear upfront - IE "this is a thing i'm not going to spend a lot of energy on. If you give me stuff that works well, i'll integrate it. If not, i won't".
I would also agree you are going to get some amount of crap no matter what. But, i would say if you want this to be different, it's not entirely on other people. Even with the best of intent, you can't expect contributors or teams or processes to behave magically just because they should. You usually need to motivate/incentivize or train the behaviors you want, and iterate the processes and your approach until you are getting what you want.
I would also agree you are going to get some amount of crap no matter what. But, i would say if you want this to be different, it's not entirely on other people. Even with the best of intent, you can't expect contributors or teams or processes to behave magically just because they should. You usually need to motivate/incentivize or train the behaviors you want, and iterate the processes and your approach until you are getting what you want.
The fact is, most people can't write bug free code, that is also maintainable. It's a skill that takes years to hone. Even someone that is smart enough to understand all possible code paths and can prove it is bug free, doesn't automatically mean the code is written in a way that is easy to maintain.
Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right.
Please remember, the bar has been set this high by successful projects.
One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.)
That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.
Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right.
Please remember, the bar has been set this high by successful projects.
One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.)
That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.
While the comment was overgeneralizing, the code will be rejected (actually, it won't even be rejected in a final way, just feedback will be given about how provide a better version that has chances to be integrated) if the code has actual problems (or at least perceived problems in the eye of the maintainer but in some case we are talking about concrete actual correctness problems that are not a matter of opinion but of pure logic), not just if there is an hypothetical risk that problems would be found if the code was reviewed.
The efforts are mostly irrelevant if the result has serious problems.
And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough.
So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.
The efforts are mostly irrelevant if the result has serious problems.
And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough.
So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.
>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? [...] Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.
I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (scare quotes) to bad code.
So even though Linus Torvalds and his trusted lieutenants constantly complain about terrible buggy code that wastes their time, Linux still attracts new contributors (and this means more "bug ridden garbage").
EDIT add specific example... I think this 2014 Linus Torvalds complaint about programmer's bad code from has the "unwelcoming atmosphere" you probably wouldn't like : http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
... and yet people keep attempting to contribute to the Linux kernel project.
I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (scare quotes) to bad code.
So even though Linus Torvalds and his trusted lieutenants constantly complain about terrible buggy code that wastes their time, Linux still attracts new contributors (and this means more "bug ridden garbage").
EDIT add specific example... I think this 2014 Linus Torvalds complaint about programmer's bad code from has the "unwelcoming atmosphere" you probably wouldn't like : http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
... and yet people keep attempting to contribute to the Linux kernel project.
.. 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 atmosphere of harsh critique has been there from the beginning.
And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?"
Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.
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 atmosphere of harsh critique has been there from the beginning.
And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?"
Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.
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.
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.
> 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.
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.
Linux hasn't been a "toy project" compared to alacritty since maybe like.. 1992? I got my first CD-ROM with linux on it (yggdrasil) in 1993 or 1994. The scale difference here is so massive, even going back quite far.
I think you're really underestimating the rapidity with which linux grew, as well as the pure cachet that linux (or any project associated with Linus, like git) has and has had for most of its existence that makes it fundamentally different in terms of motivation and appeal from basically any other OSS project.
I think you're really underestimating the rapidity with which linux grew, as well as the pure cachet that linux (or any project associated with Linus, like git) has and has had for most of its existence that makes it fundamentally different in terms of motivation and appeal from basically any other OSS project.
"Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?"
Because if they pass the bar knowing what it is then they also know that they're part of the club of developers who have the "patience, skill or experience to write half-decent code that isn't bug-ridden garbage."
Because if they pass the bar knowing what it is then they also know that they're part of the club of developers who have the "patience, skill or experience to write half-decent code that isn't bug-ridden garbage."
Since you edited:
I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to.
I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.
I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to.
I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.
'Most programmers / contributors can only produce bug ridden garbage. Not you obviously!'
Can you see the issue here?
Can you see the issue here?
>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
Isn't the parent's whole point to discourage them from contributing?
Isn't the parent's whole point to discourage them from contributing?
> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright.
Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive.
Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.
I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright.
Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive.
Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.
I think this is well put.
If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.
If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.
I think I often see this disconnect, with developers on either one side or the other, and usually the distinguishing factor has to do with what their experiences have been. If you've ever maintained, like, anything - not even necessarily open source but even something at work (with users obviously) - for a significant period of time, long enough to see how a project evolves over time, you'd just... understand.
People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said.
So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was.
Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that.
Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself.
I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.
People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said.
So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was.
Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that.
Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself.
I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.
There's a chap named Linus, who is rather well-known for being a tough PR reviewer...
I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required.
For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.
I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required.
For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.
> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
Because they are adults with enough emotional maturity to not require constant encouragement in every aspect of life.
It's one thing to make negative, targeted statements against an individual contributor. It's another to make a likely true, slightly negative outlook about the quality of contributions on average. Potential contributors should be responsible for maintaining their own emotional equilibrium in such a case, in my opinion.
Because they are adults with enough emotional maturity to not require constant encouragement in every aspect of life.
It's one thing to make negative, targeted statements against an individual contributor. It's another to make a likely true, slightly negative outlook about the quality of contributions on average. Potential contributors should be responsible for maintaining their own emotional equilibrium in such a case, in my opinion.
Yeah this is an open-source problem.
Contributions are very often scratch-my-own-itch bugfixes that don't consider other users or the project at large.
It is easier in projects that are greenfield where there's few existing users and a more cowboy attitude toward getting any code accepted to move the project forward.
In mature projects that have lots of complicated requirements and external APIs that can't be broken it becomes extremely hard for external contributors to be successful because contributing becomes something that resembles actual $DAYJOB work that people get paid for. Which is a lot of sitting around for hours thinking of ways that the simple and obvious solution is poor and needs to get tweaked, then hours of sadness over breaking existing tests and refactoring the whole idea until you boil it down to something which is often quite a lot of work and may fix many problems outside of the initial scope of the issue, spread over multiple pull requests.
That is what software development in a mature codebase looks like, and its not something that is fun and something that people usually want to get paid to do.
Contributions are very often scratch-my-own-itch bugfixes that don't consider other users or the project at large.
It is easier in projects that are greenfield where there's few existing users and a more cowboy attitude toward getting any code accepted to move the project forward.
In mature projects that have lots of complicated requirements and external APIs that can't be broken it becomes extremely hard for external contributors to be successful because contributing becomes something that resembles actual $DAYJOB work that people get paid for. Which is a lot of sitting around for hours thinking of ways that the simple and obvious solution is poor and needs to get tweaked, then hours of sadness over breaking existing tests and refactoring the whole idea until you boil it down to something which is often quite a lot of work and may fix many problems outside of the initial scope of the issue, spread over multiple pull requests.
That is what software development in a mature codebase looks like, and its not something that is fun and something that people usually want to get paid to do.
Speaking as a historically pedantic person, correctness is often a form of perfectionism. Just gussied up.
Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions.
Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not a rocket ship.
I'm not suggesting you should just have totally bug ridden code, but if you are putting people through years of in-PR iteration on a thing to achieve "correctness", either 1. Close it because you won't get what you want 2. Accept it and improve it prior to release.
I'd point out: If it is really this hard for reasonable programmers to get it "correct", do you really think the people on the other side of the PR are so good at programming that they are getting it all right too?
Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions.
Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not a rocket ship.
I'm not suggesting you should just have totally bug ridden code, but if you are putting people through years of in-PR iteration on a thing to achieve "correctness", either 1. Close it because you won't get what you want 2. Accept it and improve it prior to release.
I'd point out: If it is really this hard for reasonable programmers to get it "correct", do you really think the people on the other side of the PR are so good at programming that they are getting it all right too?
"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 with it
3. Fix and iterate it
4. Release.
The approach on some open source projects amount to:
1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process
2. Integrate code (or sometimes just give up and throw it away!)
3. Discover there were bugs in it anyway, because no code is perfect. Fix them.
4. Release
I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse.
One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc.
The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)
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 with it
3. Fix and iterate it
4. Release.
The approach on some open source projects amount to:
1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process
2. Integrate code (or sometimes just give up and throw it away!)
3. Discover there were bugs in it anyway, because no code is perfect. Fix them.
4. Release
I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse.
One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc.
The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)
> 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 the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.
> 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 the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.
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 rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :)
One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that.
I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).
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 rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :)
One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that.
I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).
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.
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.
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. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively).
But we often suck at training people at things they aren't used to. Training goes a long way. etc
Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :)
I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not.
I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"
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. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively).
But we often suck at training people at things they aren't used to. Training goes a long way. etc
Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :)
I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not.
I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"
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.
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.
Quoting woodruffw:
> The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code.
I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.).
To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.)
On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions.
Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.
> The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code.
I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.).
To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.)
On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions.
Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.
Is it a valid reason to ignore known and found problems?
Pointing out back-tics got me worst - adding those or changing it take less time than making a comment on PR for it. Especially pointing out each place ... reviewer could spend his time on much more interesting things.
If an upstream maintainer prioritizes a clean commit log in pull requests, to enable merge-commits (like I do), then if the maintainer wants to fix formatting, they have to amend commits by the PR author and force-push to the PR author's branch. I'm not sure if "Allow edits by maintainers" allows force-pushing or not, and I don't know if it's considered bad manners to force-push to a feature branch you don't own, in someone else's repository.
> Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years.
Yes. But we are talking about a terminal emulator. And not even about one bundled with a DE (or OS). This _should_ be exactly the type of project where people can get their first OSS programming experience.
Yes. But we are talking about a terminal emulator. And not even about one bundled with a DE (or OS). This _should_ be exactly the type of project where people can get their first OSS programming experience.
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.
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.
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.
> behave like your project is the Linux kernel or the Rust compiler
Yes, misleading claims about project importance would be a bad idea.
But decisions like
> This _should_ be exactly the type of project where people can get their first OSS programming
is up to maintainers, not up to random people not running this projects
Yes, misleading claims about project importance would be a bad idea.
But decisions like
> This _should_ be exactly the type of project where people can get their first OSS programming
is up to maintainers, not up to random people not running this projects
Uh, kinda feel like you can do anything you want for a project you maintain.
> 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.
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 copy of $TOOL (if they were, they would probably write that themselves - that's why there existed 4534 versions of $TOOL).
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 copy of $TOOL (if they were, they would probably write that themselves - that's why there existed 4534 versions of $TOOL).
Well, in this case rant was not published by maintainer.
From a quick skim of the PRs, it looks like OP was using CString everywhere, and messing with pointers in unsafe blocks, called from safe blocks of code.
Generally speaking, these 2 things alone are basic errors when coding proper Rust. There were also many minor issues with the PRs that it seems the maintainers attempted to work through with OP.
Unfortunately learning the basics of a language like Rust is hard. Learning how to write correct Rust is even harder (and sometimes impossible without the right background knowledge). Learning how a project expects PRs to be designed and formatted is less technical, but takes dedication and time.
These PRs are riddled with things that are just straight incorrect.
Also, generally you are right about beginners starting with easier projects like this, but as many others in these comments have stated, the general bar is not low. Projects decide how to manage PRs. Nobody is stopping you from creating a terminal emulator in Rust that caters to beginners in Open Source. My guess is that the project would not be as good as Alacritty.
Also, the maintainers of any open source project don't owe you or anyone (including contributors) anything.
Generally speaking, these 2 things alone are basic errors when coding proper Rust. There were also many minor issues with the PRs that it seems the maintainers attempted to work through with OP.
Unfortunately learning the basics of a language like Rust is hard. Learning how to write correct Rust is even harder (and sometimes impossible without the right background knowledge). Learning how a project expects PRs to be designed and formatted is less technical, but takes dedication and time.
These PRs are riddled with things that are just straight incorrect.
Also, generally you are right about beginners starting with easier projects like this, but as many others in these comments have stated, the general bar is not low. Projects decide how to manage PRs. Nobody is stopping you from creating a terminal emulator in Rust that caters to beginners in Open Source. My guess is that the project would not be as good as Alacritty.
Also, the maintainers of any open source project don't owe you or anyone (including contributors) anything.
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...
[1]: https://github.com/kovidgoyal/kitty/blob/2350952d054bcaf945a...
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.
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.
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.
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.
Yeah theres so many issues popping out of the rust community and projects I didn't think that would happen. Guess I have a lot to learn
Ah! The “classic” ligature issue. Have been following that for a while. Kind of given up hope that there will ever be any support for it.
Edit: punctuation
Edit: punctuation
> The “classic” ligature issue.
We try to make our terminals do things no terminal (remember those boxes with a CRT that used to be in a room, then became ubiquitous enough to end up on our desks) ever did, or considered doing. Do I enjoy being able to partition a window without needing tmux? Yes. Do I like text reflowing when I resize the window? Sure. Do I find Tektronix mode useful? No. Do I find it fun? Of course!
We all are passionate about some thing or another (I, for instance, maintain an IBM 3278-2-like terminal font), but I have to agree that, when someone says my suggestion for adding smooth scrolling or double width/height attributes to VTE (I promised to add Tek support to it, but, like so many other side projects, I didn't have the time to start it) is niche or, worse, a Terrible Idea, they are not doing that out of cruelty, but from a position of "I'll have to maintain this idea only you like forever", and, in their place, I'd probably do the same (as I have in the past with `pip-chill` (another thing I maintain), when I think an idea is not great).
OTOH, from the other side, I'd love to see https://github.com/urwid/urwid/pull/434 merged :-(
And, of course, having https://github.com/htop-dev/htop/pull/736 shot down was disappointing, but understandable.
We try to make our terminals do things no terminal (remember those boxes with a CRT that used to be in a room, then became ubiquitous enough to end up on our desks) ever did, or considered doing. Do I enjoy being able to partition a window without needing tmux? Yes. Do I like text reflowing when I resize the window? Sure. Do I find Tektronix mode useful? No. Do I find it fun? Of course!
We all are passionate about some thing or another (I, for instance, maintain an IBM 3278-2-like terminal font), but I have to agree that, when someone says my suggestion for adding smooth scrolling or double width/height attributes to VTE (I promised to add Tek support to it, but, like so many other side projects, I didn't have the time to start it) is niche or, worse, a Terrible Idea, they are not doing that out of cruelty, but from a position of "I'll have to maintain this idea only you like forever", and, in their place, I'd probably do the same (as I have in the past with `pip-chill` (another thing I maintain), when I think an idea is not great).
OTOH, from the other side, I'd love to see https://github.com/urwid/urwid/pull/434 merged :-(
And, of course, having https://github.com/htop-dev/htop/pull/736 shot down was disappointing, but understandable.
Absolutely! And the ligatures is definitely a nice-to-have, not a must. I really enjoy Alacritty and use it every day. The performance is amazing!
Indeed. I also switched to Kitty a long time ago. While I personally would like a tty with less features overall, this one was absolutely a deal breaker for me.
There is also Wezterm which does have support for ligatures https://github.com/wez/wezterm
I 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 reduces the number of branches - if I see it as worth changing I'll do it myself after the merge. I'm not looking for all the reasons why it can't be merged, I'm looking for the minimum changes needed to make it comply with the codebase's existing standards.
This post also highlights one of the reasons I fell out of love with Rust. There's too many ways to do things.
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 reduces the number of branches - if I see it as worth changing I'll do it myself after the merge. I'm not looking for all the reasons why it can't be merged, I'm looking for the minimum changes needed to make it comply with the codebase's existing standards.
This post also highlights one of the reasons I fell out of love with Rust. There's too many ways to do things.
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 this is to be more proactive and discuss first and then get to coding. Oh, and be prepared you would need to code an approach different from what you wanted.
And there is absolutely no shame in forking the repo, doing the changes you could not get merged, and keeping it around for your own/your org use.
It is all about tradeoffs.
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 this is to be more proactive and discuss first and then get to coding. Oh, and be prepared you would need to code an approach different from what you wanted.
And there is absolutely no shame in forking the repo, doing the changes you could not get merged, and keeping it around for your own/your org use.
It is all about tradeoffs.
>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'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 am judging it by the comments.
I have been on both sides of this situation over the years, but it was never too extreme.
On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author.
On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better.
Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve.
The freedom with open source always should go both ways.
I have been on both sides of this situation over the years, but it was never too extreme.
On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author.
On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better.
Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve.
The freedom with open source always should go both ways.
I've run into this myself: a contributor submitted a pull request that didn't follow a bunch of guidelines, and the changes they introduced were very different from the rest of the code in the same file. I asked them to keep things consistent with the existing code, and they basically argued "This fixes the problem, so you must merge it".
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.
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.
The analogy that popped up in my head reading these threads is someone buying expensive and bulky yet useless for the recipient gift and then being upset when it is rejected.
“But i paid a lot for it!”
“But i paid a lot for it!”
Literally this article?
> if I see it as worth changing I'll do it myself after the merge.
100% agree! Someone unfamiliar with the code base takes the time to make a change that improves something, for free and without asking for anything in return... I always try to take it as it is, only asking for changes that are really necessary to avoid bugs or serious problems, then I normally go and do a post-merge cleanup to try to keep things organized in the way I want (which is hard for outsiders to do themselves).
> There's too many ways to do things.
Exactly! That's why Rust PR reviews are always dangerously close to descending into nit-pick shit shows - there's ALWAYS a 0.1% nicer way to write something, you can always change it to make it 2% more efficient, or to avoid allocating as much memory, or avoid using explicit lifetimes, or avoid dynamic dispatch.... the list goes on.
100% agree! Someone unfamiliar with the code base takes the time to make a change that improves something, for free and without asking for anything in return... I always try to take it as it is, only asking for changes that are really necessary to avoid bugs or serious problems, then I normally go and do a post-merge cleanup to try to keep things organized in the way I want (which is hard for outsiders to do themselves).
> There's too many ways to do things.
Exactly! That's why Rust PR reviews are always dangerously close to descending into nit-pick shit shows - there's ALWAYS a 0.1% nicer way to write something, you can always change it to make it 2% more efficient, or to avoid allocating as much memory, or avoid using explicit lifetimes, or avoid dynamic dispatch.... the list goes on.
> I think many developers treat PRs as an opportunity to gatekeep
Well, it is your project or your team's project. It is entirely legitimate gatekeeping.
Questioning that is the bad side of the "social coding" touted by Github. IMO "social-anything" is like the Force in SW, it is easy to fall for its dark side if you don't keep your emotions in check.
Well, it is your project or your team's project. It is entirely legitimate gatekeeping.
Questioning that is the bad side of the "social coding" touted by Github. IMO "social-anything" is like the Force in SW, it is easy to fall for its dark side if you don't keep your emotions in check.
> I think many developers treat PRs as an opportunity to gatekeep.
An open-source maintainer should be gate-keeping the project.
Open source is great in that it enables many people to suggest improvements, but the PRs should be viewed as a proposal for collaboration.
Not all PRs are created equal. Far from it. They span a very wide range of quality. Letting every PR into the project will quickly accumulate a lot of technical debt and place even more burden on the maintainers to do further work to undo the backwards steps of the bad PRs.
When keeping quality high (or even just average), gatekeeping isn't inherently a bad thing.
An open-source maintainer should be gate-keeping the project.
Open source is great in that it enables many people to suggest improvements, but the PRs should be viewed as a proposal for collaboration.
Not all PRs are created equal. Far from it. They span a very wide range of quality. Letting every PR into the project will quickly accumulate a lot of technical debt and place even more burden on the maintainers to do further work to undo the backwards steps of the bad PRs.
When keeping quality high (or even just average), gatekeeping isn't inherently a bad thing.
The whole point of PRs is to gatekeep. They are there to enforce that the change is consistent with the owner's standards.
“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.
Not saying this is the case here but there are two ways to look at it.
What about adding it to the PR yourself? Why should it be the same person creating/fixing the PR?
I'm assuming you mean't "why shouldn't". Because a lot of critique in programming is a matter of personal opinion and I see it as impolite to block somebody else's hard work because it doesn't look the way the reviewer wants. Of course, it's a different matter if the code is insecure or something but I really don't care about the extremely fine implementation details.
I understand the point of view of the author, but at the same time I appreciate how simple and not bloated Alacritty is, there is great software out there but terribly bloated with features that become useful only in edge cases.
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 quality seems to be a higher goal than in most projects I know, that's kinda admirable too. I can imagine your side too though, it's frustrating to be working on something and not seeing it go forward.
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 quality seems to be a higher goal than in most projects I know, that's kinda admirable too. I can imagine your side too though, it's frustrating to be working on something and not seeing it go forward.
Totally agree: the issues raised are not just cosmetic -- several of them address fundamental thread safety issues that appear to be lost on the author.
It's the author of 8chan, so libel is not surprising here.
Bennan has since repudiated 8chan and has fought for it to be taken offline. Let's not judge him too harshly.
No, he didn't fight for it. He sold that site - that’s all. When he had the power to stop GamerGate imageboards - he didn't. When he could remove boards with CP - he didn't. What I wrote is far from “judging him too harshly” :)
He only apologized for not removing the shooter's manifests. He didn't apologize for GamerGate, CP, racism, neo-nazism, and other terrible things. His words about the 8chan shutdown - “I was not even that upset about that” [1]. You can’t call it “fighting”.
[1] https://jacobinmag.com/2021/04/fredrick-brennan-8chan-intern...
He only apologized for not removing the shooter's manifests. He didn't apologize for GamerGate, CP, racism, neo-nazism, and other terrible things. His words about the 8chan shutdown - “I was not even that upset about that” [1]. You can’t call it “fighting”.
[1] https://jacobinmag.com/2021/04/fredrick-brennan-8chan-intern...
hey thanks for posting a link to the interview since it gives much more perspective
Very convenient to do so when it is no longer lining pockets.
[deleted]
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.
Though like I said I don't agree and I think the devs merging it had justified concerns.
I wrote a blog post showing how Rust performance can be pretty terrible when you write code like you would in other languages (something people recommend to beginners to avoid having to deal with advanced concepts in Rust)... big mistake: I am pretty sure several dozen "Rustaceans" felt the need to write to me explaining how terrible my code was, how it could be much faster if I just did x and y (which were true, but beyond the point I was trying to make), how I didn't know even basic CompSci (well, I do, I managed to get a degree and work in this field for nearly two decades, but I disgress)... it was a pretty harsh experience, and I am now much more conservative with talking about my Rust code publicly as a result!
It's a double-edged sword. Rust gives all the tools to make really performant software and tries to keep inefficient operations visible.
But in many situations doing it the "proper" way requires a deep understanding of the type system and a lot of experience so you can tell the compiler what you're trying to do. Most things just aren't performance critical enough to warrant a day of experimentation, and many features don't really need generics and all the syntax overhead that comes with them.
When you combine that with perfectionists it can probably get annoying. It's sad this is common enough to drive people away, because I think Rust is a great language and using it "well enough" is the first step to learning how to do it better. Imho it's not realistic to expect everyone to really understand all aspects of traits, lifetimes etc. because those can get really tricky really quick and not every behaviour of the compiler is consistent in those areas.
When you combine that with perfectionists it can probably get annoying. It's sad this is common enough to drive people away, because I think Rust is a great language and using it "well enough" is the first step to learning how to do it better. Imho it's not realistic to expect everyone to really understand all aspects of traits, lifetimes etc. because those can get really tricky really quick and not every behaviour of the compiler is consistent in those areas.
I don't have any first-hand experience with this topic, but it seems reasonable that Rust has a special attraction for perfectionists. So many features to play with to get the most efficient, memory-safe etc. code...
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
[deleted](1)
I 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 around to fix any issues they caused and you have to deliver so in it goes. However, a maintainer of an OS project first of all probably does not have the same problem you are trying to solve AND they may not trust that you will stick around to fix any problems your code may cause in the future. On the other hand they want you to contribute because this makes the project more popular and there is a chance that you will become a maintainer yourself. It's a balancing act.
This is why it is important for a channel of communication to be opened between all those interested in the project (a chat group) to grow rapport.
This is why it is important for a channel of communication to be opened between all those interested in the project (a chat group) to grow rapport.
> 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.
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.
A PR is a gift and a burden.
A gift of someone else's effort to contribute and push something forward.
A burden because once received, future maintainance of the gift is really on the one who received the gift.
It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other animals stacked up behind this one?
I don't think it's constructive to paint the approver as gatekeeping, or perfectionist. What does that achieve? Surely it's better to meet halfway on the gift exchange, thank you for the PR but it does need to be house-trained and socialised, etc.
A gift of someone else's effort to contribute and push something forward.
A burden because once received, future maintainance of the gift is really on the one who received the gift.
It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other animals stacked up behind this one?
I don't think it's constructive to paint the approver as gatekeeping, or perfectionist. What does that achieve? Surely it's better to meet halfway on the gift exchange, thank you for the PR but it does need to be house-trained and socialised, etc.
"Open source: the gift that keeps on taking."
(Earliest use I can find here – https://twitter.com/devbisme/status/1017520086096207874 – but perhaps goes back much further.)
(Earliest use I can find here – https://twitter.com/devbisme/status/1017520086096207874 – but perhaps goes back much further.)
The problem is when contributors view their contributions as a gift rather than a starting point for collaboration.
Rejecting a gift is quite a rude gesture. Rejection a PR contribution until it receives further iteration after some thoughtful feedback is anything but a rude gesture.
I think this mindset that open source maintainers are obligated to accept PRs as gifts is the source of much of this frustration. The PR should be a starting point for further discussion, iteration, and collaboration, not a one-way gift that places a burden on the maintainer to satisfy the wants of the contributor.
Rejecting a gift is quite a rude gesture. Rejection a PR contribution until it receives further iteration after some thoughtful feedback is anything but a rude gesture.
I think this mindset that open source maintainers are obligated to accept PRs as gifts is the source of much of this frustration. The PR should be a starting point for further discussion, iteration, and collaboration, not a one-way gift that places a burden on the maintainer to satisfy the wants of the contributor.
[deleted]
[deleted]
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
1. https://github.com/wez/wezterm
Do you need tabs still if you use tmux by default?
My favorite way to use tmux or et is with tabs in iTerm2.
Just moved to kitty from iterm2 a few weeks ago.
Started with alacritty, but without tab support, was a deal-breaker for me.
I use tabs in kitty with tmux on each tab. Each tab is a context in my environment (dev/services/ansible/terraform/etc).
Started with alacritty, but without tab support, was a deal-breaker for me.
I use tabs in kitty with tmux on each tab. Each tab is a context in my environment (dev/services/ansible/terraform/etc).
No. I used to use tmux extensively when I was doing a lot of remote shell work, but I don't do that any more. For local work I'd still use tmux if there was no other option, but kitty spoiled me :-).
I prefer a tab for each machine, including local, and then each tab has a tmux or ssh + tmux.
Yes, Kitty is too resource hungry for my taste as well. And the Alacritty devs outright refuse ligature support because all existing implementations are too low quality in their opinion.
So now I'm just using st with a ligature patch. Not perfect and rather slow when dumping a lot of text to stdout, but it's otherwise snappy and does everything I need.
So now I'm just using st with a ligature patch. Not perfect and rather slow when dumping a lot of text to stdout, but it's otherwise snappy and does everything I need.
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/
[0]: https://gnunn1.github.io/tilix-web/
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!
“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?
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.
As a free software maintainer, I have high standards for quality because (a) I like it that way, and liking it is why I do it for free, and (b) if your PR sucks, chances are I'm the one who has to write the docs, fix the bugs, and deal with the design consequences forever.
If you disagree with maintainer priorities, just fork it! Merge whatever you want, advertise your fork in the unmerged PRs' comments, see what happens. Nobody will be offended; the license specifically encourages this.
Maybe you'll find you're just better at this maintainer thing and the world now contains better software, or maybe after a few years you'll find that you understand their perspective.
If you disagree with maintainer priorities, just fork it! Merge whatever you want, advertise your fork in the unmerged PRs' comments, see what happens. Nobody will be offended; the license specifically encourages this.
Maybe you'll find you're just better at this maintainer thing and the world now contains better software, or maybe after a few years you'll find that you understand their perspective.
While it can be frustrating I think it's fair to say that it's up to maintainers or project owners to decide what fits into the vision of their project, and therefore contributing a change (particularly a feature addition and not a bug fix) does come with the sizeable risk that it's not actually what the maintainers want and will therefore be rejected.
Of course, if it's too strict then people will stop contributing entirely. But if it isn't stright enough then the project can suffer from bloat and a lack of a unifying vision.
This becomes less of an issue if there's some level of expectation management involved. e.g. here is what we would like contributions for, here are things that we won't, and if you're unsure about any of it, open an issue about it before investing all your time and effort.
Of course, if it's too strict then people will stop contributing entirely. But if it isn't stright enough then the project can suffer from bloat and a lack of a unifying vision.
This becomes less of an issue if there's some level of expectation management involved. e.g. here is what we would like contributions for, here are things that we won't, and if you're unsure about any of it, open an issue about it before investing all your time and effort.
No opinions from me on Rust pacing/contribution standards in general, or `alacritty` specifically.
But from sidelines, I find it ironic that a project whose name is a play on the word 'alacrity', meaning "cheerful readiness, promptness, or willingness", is earning criticism for its plodding perfectionism & willingness to say 'no'.
(Maybe users/contributors are subconsciously applying a higher standard via the connotations of its name?)
But from sidelines, I find it ironic that a project whose name is a play on the word 'alacrity', meaning "cheerful readiness, promptness, or willingness", is earning criticism for its plodding perfectionism & willingness to say 'no'.
(Maybe users/contributors are subconsciously applying a higher standard via the connotations of its name?)
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 them in private instead.
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 them in private instead.
As I maintainter myself, I completely disagree. It's a fair complaint that everyone contributing to open source will eventually suffer from.
> Please don't ever post things like this.
What the hell, is this against any HN policy? Or you think no one should post their point of view here if it's against yours?
EDIT: I think it's important to note that burnout is a result of you having an issue within yourself (at least in the context of voluntary projects), it's not something others do to you... you can choose to ignore all pull requests, for example, or say in your README that you won't accept any (I've done that myself to projects I wanted to keep in a certain "permanent" state for reasons). If you choose to engage in discussions, that's your call.
> Please don't ever post things like this.
What the hell, is this against any HN policy? Or you think no one should post their point of view here if it's against yours?
EDIT: I think it's important to note that burnout is a result of you having an issue within yourself (at least in the context of voluntary projects), it's not something others do to you... you can choose to ignore all pull requests, for example, or say in your README that you won't accept any (I've done that myself to projects I wanted to keep in a certain "permanent" state for reasons). If you choose to engage in discussions, that's your call.
> I think it's important to note that burnout is a result of you having an issue within yourself
I think this is an oversimplification. You can be perfectly happy with yourself, but if your environment creates a neverending treadmill of situations that drains your soul, you will get burnout if you cannot find any mechanism to cope with it, to avoid it or to deal with it.
And in open source we are each others environment. If you have 100 well researched issues written in a friendly tone you will certainly feel a different motivation to tackle that backlog than if it are 100 toxic spitting well-researched issues. The same goes for how we talk about each other in public. If you think a PR should have been merged, just talk to the maintainers in a non-public setting (Chat or whatever) and explain why you want it merged, what you would be willing to do for it and how they could see this happen. If they still don't like to do it, just fork it and do it yourself.
I think this is an oversimplification. You can be perfectly happy with yourself, but if your environment creates a neverending treadmill of situations that drains your soul, you will get burnout if you cannot find any mechanism to cope with it, to avoid it or to deal with it.
And in open source we are each others environment. If you have 100 well researched issues written in a friendly tone you will certainly feel a different motivation to tackle that backlog than if it are 100 toxic spitting well-researched issues. The same goes for how we talk about each other in public. If you think a PR should have been merged, just talk to the maintainers in a non-public setting (Chat or whatever) and explain why you want it merged, what you would be willing to do for it and how they could see this happen. If they still don't like to do it, just fork it and do it yourself.
> you will get burnout if you cannot find any mechanism to cope with it, to avoid it or to deal with it.
I agree with you it's more complicated than that, but you seem to be supporting my point by saying this :)
... you will get burnout if --> *you* cannot find a way to cope... --> *you* cannot deal with it.
It's like offense... it must be taken to work... I know, I know... sometimes you cannot avoid taking it and bringing it with you because you care about others thinking you should be offended, or that they feel offended on your behalf even (with seems to be a common feeling today), but I find it great that the English language uses the term "take offense", as it is so accurate: if you don't take it, it simply evaporates, no one can offend you and force you to take offense if you choose to not do it.
Same with burnout.
I agree with you it's more complicated than that, but you seem to be supporting my point by saying this :)
... you will get burnout if --> *you* cannot find a way to cope... --> *you* cannot deal with it.
It's like offense... it must be taken to work... I know, I know... sometimes you cannot avoid taking it and bringing it with you because you care about others thinking you should be offended, or that they feel offended on your behalf even (with seems to be a common feeling today), but I find it great that the English language uses the term "take offense", as it is so accurate: if you don't take it, it simply evaporates, no one can offend you and force you to take offense if you choose to not do it.
Same with burnout.
The world does not owe maintainers protection from negative feedback. They are not high priests of open source whose behaviour is above criticism because they "make free things". It sucks to be criticized, even as politely as in the gist, but it's part of being an adult operating alongside other adults in a complex domain where disagreement is inevitable.
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 want to bring their PR up to your standards. This article seems to indicate that any PR intended to be helpful must be merged, whatever the cost in maintenance, because otherwise you're gatekeeping.
If you refuse a PR for bad reasons ("I don't accept contributions from Chile because I had a bad holiday there once" and more racist/sexist variants thereof) then you definitely deserve criticism. What's happening here isn't really criticism, though, it's childish ranting about other people not putting in enough free work for the author and how that is somehow damaging to the volunteers, disguised behind polite words.
I think the world owes maintainers no protection from real, useful negative feedback, but a lot of negative feedback is just people being angry that they don't get their way. In a civil internet, that kind of behaviour has no place being called "criticism" and being assumed to just be par for the course of open source.
I've decided I never want to be an open source maintainer exactly because of the entitled people who write these articles, and I don't think I'm the only one being pushed away from open source for this reason.
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 want to bring their PR up to your standards. This article seems to indicate that any PR intended to be helpful must be merged, whatever the cost in maintenance, because otherwise you're gatekeeping.
If you refuse a PR for bad reasons ("I don't accept contributions from Chile because I had a bad holiday there once" and more racist/sexist variants thereof) then you definitely deserve criticism. What's happening here isn't really criticism, though, it's childish ranting about other people not putting in enough free work for the author and how that is somehow damaging to the volunteers, disguised behind polite words.
I think the world owes maintainers no protection from real, useful negative feedback, but a lot of negative feedback is just people being angry that they don't get their way. In a civil internet, that kind of behaviour has no place being called "criticism" and being assumed to just be par for the course of open source.
I've decided I never want to be an open source maintainer exactly because of the entitled people who write these articles, and I don't think I'm the only one being pushed away from open source for this reason.
> 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 don't match their ambitions. Someone has to keep low-quality work out of open source projects, and it's not a job I would want.
Nevertheless, quis custodiet ipsos custodes? The real problem with gate-keeping is when the gate-keepers aren't accountable. Criticism is one of the ways we can keep them accountable.
It's the same many areas. I want engineering schools and guilds to gate-keep so bridges don't fall down when I'm driving across them. I want news and book editors to gate-keep so I don't have to wade through acres of dross to find worthwhile content. And I want maintainers to gate-keep so open source software works when I need it.
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 don't match their ambitions. Someone has to keep low-quality work out of open source projects, and it's not a job I would want.
Nevertheless, quis custodiet ipsos custodes? The real problem with gate-keeping is when the gate-keepers aren't accountable. Criticism is one of the ways we can keep them accountable.
It's the same many areas. I want engineering schools and guilds to gate-keep so bridges don't fall down when I'm driving across them. I want news and book editors to gate-keep so I don't have to wade through acres of dross to find worthwhile content. And I want maintainers to gate-keep so open source software works when I need it.
> But I'm glad maintainers act as gate keepers.
Me too, it's kind of the whole point of being a maintainer :-)
Me too, it's kind of the whole point of being a maintainer :-)
> Posts like this are major contributors to maintainer burnout.
Lack of contributors also causes maintainer burnout. The best way I know to have zero help is to treat a contributor poorly. Sometimes it cannot be helped, for example, when a contributor sends unusable code or a contribution forces a decision the maintainer isn't ready to make. Most scorned contributors will do exactly what Frederick did in this case, vent and then find a similar project to contribute to. In this case the similar project is Kitty, which is a fantastic piece of software.
> Please don't ever post things like this.
Asking people to shut up, not matter how politely you do it, rarely works. The problem will remain, and people will still complain about it.
Lack of contributors also causes maintainer burnout. The best way I know to have zero help is to treat a contributor poorly. Sometimes it cannot be helped, for example, when a contributor sends unusable code or a contribution forces a decision the maintainer isn't ready to make. Most scorned contributors will do exactly what Frederick did in this case, vent and then find a similar project to contribute to. In this case the similar project is Kitty, which is a fantastic piece of software.
> Please don't ever post things like this.
Asking people to shut up, not matter how politely you do it, rarely works. The problem will remain, and people will still complain about it.
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?
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?
Maintainer attitudes like this are major contributors to maintainer burnout. A look through the linked PR is about 50/50 solid technical criticism and nitpicky bikeshedding.
The Rust community seems toxic, in the Wikipedian way of being unwelcoming and unfriendly without ever dropping into incivility.
The Rust community seems toxic, in the Wikipedian way of being unwelcoming and unfriendly without ever dropping into incivility.
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.
I'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.
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.
The 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.
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.
It's easier to understand the future consequences and limitations of code you wrote yourself.
The main challenge in open-source is communication.
The main challenge in open-source is communication.
fwiw 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…
The 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?
Indeed, the two examples they mention are both related to Rust somehow, but is it enough to generalize to the whole Rust ecosystem?
The Rust library ecosystem is small but they tend to be high quality IME; this is a drawback of it I suppose.
mgaunard(1)
The "Art of Rejecting pull requests" is hard.
read more:
"Polite Technology
This is a book about the social interactions and situations that are the underpinnings of the open source world. It's about how humans collaboratively create software."
https://polite.technology/preview
read more:
"Polite Technology
This is a book about the social interactions and situations that are the underpinnings of the open source world. It's about how humans collaboratively create software."
https://polite.technology/preview
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 stick out like a sore thumb on the dock unless you manually patch it each time.
[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 logo and loses too much of the character of the original logo. A more conservative adjustment might stand a better chance. (chrisduerr also quibbles over the idea of maintaining different icon graphics for different platforms, but I suspect this may be more a further complaint about something that he’s otherwise already not happy with: that if the proposed icon was actually true to the Alacritty logo he wouldn’t object so much, though it’s still not an entirely unreasonable complaint—Apple are probably going to change their style in another year or two anyway.)
Admittedly the current icon isn’t great, because it’s taking the full width available to it, where native square icons look to go for 10% border on each side. I imagine you might have much more success just fixing the icon’s scaling (e.g. down to 90%—because it’s not square, 80% would probably be too far).
You could also try adjusting the aspect ratio just a bit, slightly squarer, but leaving everything else the same—that’d be about as conservative as you could get while still varying it for macOS. That’d make it a fair test of the idea whether chrisduerr is actively against having different source icons for different platforms.
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 logo and loses too much of the character of the original logo. A more conservative adjustment might stand a better chance. (chrisduerr also quibbles over the idea of maintaining different icon graphics for different platforms, but I suspect this may be more a further complaint about something that he’s otherwise already not happy with: that if the proposed icon was actually true to the Alacritty logo he wouldn’t object so much, though it’s still not an entirely unreasonable complaint—Apple are probably going to change their style in another year or two anyway.)
Admittedly the current icon isn’t great, because it’s taking the full width available to it, where native square icons look to go for 10% border on each side. I imagine you might have much more success just fixing the icon’s scaling (e.g. down to 90%—because it’s not square, 80% would probably be too far).
You could also try adjusting the aspect ratio just a bit, slightly squarer, but leaving everything else the same—that’d be about as conservative as you could get while still varying it for macOS. That’d make it a fair test of the idea whether chrisduerr is actively against having different source icons for different platforms.
> 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...
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...
There's a similar thing with Kitty, which has a pretty bad looking icon that has sentimental value for the maintainer. The maintainer has expressed that they have no interest in changing the icon.
I simply made my own[0] and replaced it on my machine, easy enough and I fully respect the maintainer's position. It takes 30 seconds to replace the icon with an alternative, in fact you can probably automate it if you wish.
0: https://github.com/k0nserv/kitty-icon
I simply made my own[0] and replaced it on my machine, easy enough and I fully respect the maintainer's position. It takes 30 seconds to replace the icon with an alternative, in fact you can probably automate it if you wish.
0: https://github.com/k0nserv/kitty-icon
How many other non-apple apps “stick out like a sore thumb”?
On my dock:
Finder, Slack: Squircle
Chrome, VS Code: Logo in a white squircle
Alacritty, IntelliJ, Firefox, Obsidian: Unusual shaped logos
VPN: Circle
Webex: Squircle, but scaled wrong (different border radius and aspect ratio)
So only about half are squircles, and one of them is not the OS X squircle.
Finder, Slack: Squircle
Chrome, VS Code: Logo in a white squircle
Alacritty, IntelliJ, Firefox, Obsidian: Unusual shaped logos
VPN: Circle
Webex: Squircle, but scaled wrong (different border radius and aspect ratio)
So only about half are squircles, and one of them is not the OS X squircle.
Exactly, so mostly only Apple apps have been redesigned.
Currently the only other ones are Firefox and Focusrite Control.
This is frustrating because it is a change that has no other impact aside from making your users happier. The justification for not merging that is nonsense.
You don't have to agree with the justification, but calling it "nonsense" seems a bit unfair. The github threads are a bit long and with several different points made, but my reading of the bottom line is: "this is not the official icon, it should not be in tree"
It increases complexity of future maintenance, no change is costless.
I've noticed the same. For example, for Rust embedded Hardware Abstraction Libraries, I had to abandon the existing ones and start a new one: The existing ones were missing features, had bugs etc. I initially attempted to fix them with PRs, but couldn't get anything merged due to complaints such as those in the article! It's as if the maintainers would rather have a sparse debate over the course of months trying to get things perfect than fix the problem or add the feature. If you don't like the code style of the PR, just do the fix yourself. It would be a lot easier than arguing!
It was easier to start fresh than get PRs merged. This happened even for clean kill bug fixes.
For my own projects, my bar for merging is "Does this improve the project". If there's a code style issue I don't like, I'll merge, then make the change myself after. If it's an idea I don't like, or determine is out of scope, I'll state clearly that I have no intent to merge it.
Sometimes these are an issue of available maintainer time. Eg, the maintainer may be busy, and doesn't want to dedicate time to a project. So, you end up in code-style debates, where response take weeks etc. It's mismatched expectations between maintainers and users. Or if the maintainer doesn't have time to test or evaluate a change in all cases, a conservative call is to not take the risk of unforseen consequences.
Overall: I also agree with the points others here make about the owner-maintenance burden of PRs, no obligation to merge code you don't agree with, validity of safety concerns etc. It means you need to treat these on a case-by-case basis. In the case I outlined above, it would have been preferable not to fragment the embedded Rust OSS community by introducing a fresh HAL, but I had to to meet project requirements.
It was easier to start fresh than get PRs merged. This happened even for clean kill bug fixes.
For my own projects, my bar for merging is "Does this improve the project". If there's a code style issue I don't like, I'll merge, then make the change myself after. If it's an idea I don't like, or determine is out of scope, I'll state clearly that I have no intent to merge it.
Sometimes these are an issue of available maintainer time. Eg, the maintainer may be busy, and doesn't want to dedicate time to a project. So, you end up in code-style debates, where response take weeks etc. It's mismatched expectations between maintainers and users. Or if the maintainer doesn't have time to test or evaluate a change in all cases, a conservative call is to not take the risk of unforseen consequences.
Overall: I also agree with the points others here make about the owner-maintenance burden of PRs, no obligation to merge code you don't agree with, validity of safety concerns etc. It means you need to treat these on a case-by-case basis. In the case I outlined above, it would have been preferable not to fragment the embedded Rust OSS community by introducing a fresh HAL, but I had to to meet project requirements.
A suggestion for anyone using gist.github.com for messages like this: please put the date of writing prominently near the top, as the platform won't do it for you in the way something designed for blogging would.
My first commit to a fairly big opensource project is still not merged. The project is very beginner friendly but the project maintainers wanted my commit in a certain way as per their standards. It was not even the actual code but the commenting and variable names that needed to be changed. I had to re-review it many times before it was ready for merge. It took almost 2 to 3 months with some long time gap before I made perfect submission. In this process it seemed crazy to me why anyone will be looking through all this code made by a beginner with so many mistakes and patiently guiding them through it for free of cost. It made me appreciate their work more. Even though it isn’t merged yet I still got to learn a lot in this process.
Btw the PR didn’t get merged yet because we need to fetch data using an api of another source which is poorly documented.
Btw the PR didn’t get merged yet because we need to fetch data using an api of another source which is poorly documented.
I very much appreciate that Rust crates aim a little bit higher. I think it’s a different story for apps where shortcuts are a good idea.
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 of reviewing and I really like it.
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 of reviewing and I really like it.
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.)
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.)
> 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.
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.
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.
I can tell you from recent experience, merging something only to have it reverted later is a net confidence loss.
If it's "not perfect" but still logically correct and useful to the project, then by all means feel free to merge and refactor it later. But broken code that will introduce bugs/defects should not be merged.
[deleted]
I feel the pull of perfectionism in my own Rust project [1]. Rust itself sets such a high standard of bending tradeoffs, trying to meet competing goals (and to some extent succeeding), that I feel like my own library project needs to meet that same standard of perfection. I fear I might have made more progress toward my actual goal by now if I had gone with C++.
[1]: https://github.com/AccessKit/accesskit
[1]: https://github.com/AccessKit/accesskit
Neither the PR, nor the linked issue, goes to any effort to explain what the work is and why it is needed. PRs should always have a carefully written intro, unless they are doing something totally trivial. For a new feature, the PR intro should explain the background and why the feature is justified, a high level overview of the code changes, and how correctness has been established. 30 minutes writing a PR is not much, especially if you've been working on something for more than one day. If your company doesn't have that culture, your company should change.
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 and move on to devote your precious time and energy to other things related to your code, which remains an enjoyable place to work. That looks like the story of that ligatures PR.
In this camp, my tty needs are simple. Alacritty is simple- and works well.
IMO core maintainers call the shots on what to accept and what not to. As others have mentioned, if you don't like it- fork and build your own.
IMO core maintainers call the shots on what to accept and what not to. As others have mentioned, if you don't like it- fork and build your own.
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.
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.
I agree with this as well. I use Alacritty all day, every day for work. It does exactly what I need and is very fast and stable.
This smells a lot of the classic "Worse is Better" discussion [0]. Back then, it was Scheme people insisting on correctness and C people insisting on pragmatism. It's no surprise to me that Rust, a language with a heavy focus on correctness, attracts the correctness-over-pragmatism crowd.
The author is a "worse is better" programmer who finds themselves surrounded by "the right thing" people. I think the addendum the author adds a year later in the top comment is the right insight: fork away. This keeps the "the right thing" people happily obsessed with getting everything right, without the author being blocked on moving faster.
[0] https://dreamsongs.com/RiseOfWorseIsBetter.html (1991)
The author is a "worse is better" programmer who finds themselves surrounded by "the right thing" people. I think the addendum the author adds a year later in the top comment is the right insight: fork away. This keeps the "the right thing" people happily obsessed with getting everything right, without the author being blocked on moving faster.
[0] https://dreamsongs.com/RiseOfWorseIsBetter.html (1991)
I've found Rust programmers to be eminently pragmatic. The economics of bugs have been clear for decades: it is orders of magnitude more expensive to find and fix bugs after they've been shipped.
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.
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.
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
- 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
"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 not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.
Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement."
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
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 not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.
Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement."
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
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 projects, but it certainly affords perspective. I hardly think any of the comments in this post are anything OP or any project maintainer should take personally or as undue pressure. It's simply well-trodden commentary [0].
[0] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
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 projects, but it certainly affords perspective. I hardly think any of the comments in this post are anything OP or any project maintainer should take personally or as undue pressure. It's simply well-trodden commentary [0].
[0] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
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.
> you are not thereby entitled to anything at all.
well, technically you are entitled to the source code
well, technically you are entitled to the source code
Rich Hickey is spot on...as always.
>Let's look at another project, alacritty. Don't we all remember it? It was supposed to bring Rust to the mainstream Linux desktop. It was supposed to be the new standard tty. It was supposed to be a revolution, shaking the foundations of the Earth
No, it was just supposed to be one of the many projects with ambitious goals, that more often than not, go nowhere, and are abandoned a few years down the line...
If you've been on the scene long enough, you've seen thousands like Allacrity: editors, shells, terminals, DEs, new languages, etc.
No, it was just supposed to be one of the many projects with ambitious goals, that more often than not, go nowhere, and are abandoned a few years down the line...
If you've been on the scene long enough, you've seen thousands like Allacrity: editors, shells, terminals, DEs, new languages, etc.
You sound like you speak from experience.
What makes for a project's success then?
Is it the leadership? The raw motivation?
How do you facilitate interest?
Where are the developers and productive users coming together to talk?
I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust. When I look around and compare tools, mostly, I see nothing but the same song and dance.
What makes for a project's success then?
Is it the leadership? The raw motivation?
How do you facilitate interest?
Where are the developers and productive users coming together to talk?
I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust. When I look around and compare tools, mostly, I see nothing but the same song and dance.
>What makes for a project's success then?
I've seen a few factors play an important role:
(a) dev's persistence - many projects come with grandiose goals, go some of the way, but the dev loses interest after 1 year or so and abandons them.
(b) good marketing - many project are good and maintained well, but just don't market themselves nicely. A nice landing page, examples, documentation, screenshots, and even some superficial stuff like a nice logo and icon, all play quite a role in the success of one FOSS over another. It's not enough to welcome users/contributors, you also need to make yourself known well.
(c) solving a unique need (this is not necessary - e.g. you can be "just another editor" and do well - but it's a big bonus if you have that.
>I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust.
About Rust yes. It has proven itself, shipped code in major companies, got books, wide adoption, even interest from Microsoft, Facebook, and others.
Allacrity, I'm not so sure. A lot of big early claims, but still nothing special to write home about.
It's also that Rust solved a real problem (memory safe, close to the metal, modern language), whereas Allacrity is just one of many terminals.
And nobody really thought "what I need is a secure terminal" - as if terminals are a big security issue. A faster terminal sure, but there are several plenty fast terminals, with GPU support and everything.
I've seen a few factors play an important role:
(a) dev's persistence - many projects come with grandiose goals, go some of the way, but the dev loses interest after 1 year or so and abandons them.
(b) good marketing - many project are good and maintained well, but just don't market themselves nicely. A nice landing page, examples, documentation, screenshots, and even some superficial stuff like a nice logo and icon, all play quite a role in the success of one FOSS over another. It's not enough to welcome users/contributors, you also need to make yourself known well.
(c) solving a unique need (this is not necessary - e.g. you can be "just another editor" and do well - but it's a big bonus if you have that.
>I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust.
About Rust yes. It has proven itself, shipped code in major companies, got books, wide adoption, even interest from Microsoft, Facebook, and others.
Allacrity, I'm not so sure. A lot of big early claims, but still nothing special to write home about.
It's also that Rust solved a real problem (memory safe, close to the metal, modern language), whereas Allacrity is just one of many terminals.
And nobody really thought "what I need is a secure terminal" - as if terminals are a big security issue. A faster terminal sure, but there are several plenty fast terminals, with GPU support and everything.
(2020)
I was for, a period, a contributor to Alacritty and I'm still a daily user. The fact remains that it's a wonderful tool. Far better than most, yet still flawed in a number of ways. Both on the user side and within the codebase itself.
That said, I couldn't keep up with the arguments and decisions, while also balancing my own (disintegrating) life. I feel that we are all suffering from the effects of others far too heavily these days, so much so that good projects like this are labeled a "tragedy". That is completely unfair blame. The tragedy is not of Alacritty, it's of us. It's our fault we haven't fixed the issues. It's our fault all the comments and messages are loaded with unnecessary emotion. Well... it's at least partially our fault. Sometimes it's true that the squeaky wheel gets the grease. Sometimes it's also true that dark powers work against us. Still we must look at our own part in the equation.
Personally, reflecting on this post from the start of 2020, it's hard to think of anything but my own failings in the last years. But that too is not fair. It's something I must simply work to improve; like always. Leaving the world a better place than where I found it. I know there are amazing developers still working hard on important issues. It kills me that I'm not helping as I could be. It kills me that I'm often stuck, fixing bullshit issues and wasting time on things that are out of my control. But that's how it is now, and that's how it's been too, just perhaps to a lesser degree for a time, when everything clicked.
Perfection and correctness and idealism are lofty goals. But realism and practice are required while on the hunt. Maybe one day a new puzzle piece will be found, snuggling seamlessly into place. But until then, (we try and we fail)*.
Don't throw the baby out with the bath water. I beg you.
That said, I couldn't keep up with the arguments and decisions, while also balancing my own (disintegrating) life. I feel that we are all suffering from the effects of others far too heavily these days, so much so that good projects like this are labeled a "tragedy". That is completely unfair blame. The tragedy is not of Alacritty, it's of us. It's our fault we haven't fixed the issues. It's our fault all the comments and messages are loaded with unnecessary emotion. Well... it's at least partially our fault. Sometimes it's true that the squeaky wheel gets the grease. Sometimes it's also true that dark powers work against us. Still we must look at our own part in the equation.
Personally, reflecting on this post from the start of 2020, it's hard to think of anything but my own failings in the last years. But that too is not fair. It's something I must simply work to improve; like always. Leaving the world a better place than where I found it. I know there are amazing developers still working hard on important issues. It kills me that I'm not helping as I could be. It kills me that I'm often stuck, fixing bullshit issues and wasting time on things that are out of my control. But that's how it is now, and that's how it's been too, just perhaps to a lesser degree for a time, when everything clicked.
Perfection and correctness and idealism are lofty goals. But realism and practice are required while on the hunt. Maybe one day a new puzzle piece will be found, snuggling seamlessly into place. But until then, (we try and we fail)*.
Don't throw the baby out with the bath water. I beg you.
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.
- Maintainers who haven't learned to distinguish the important from unimportant.
- Contributors who don't realize their PR is a white eleplant (burdensome gift)
- Contributors who jump in with a PR without first seeing if it aligns with the project.
Most of this happens everywhere. Probably the more unique aspects to Rust are being spread thin, precedence of high quality crates, and that Rust gives a level of control that is addictive and effects other parts of projects.
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.
- Maintainers who haven't learned to distinguish the important from unimportant.
- Contributors who don't realize their PR is a white eleplant (burdensome gift)
- Contributors who jump in with a PR without first seeing if it aligns with the project.
Most of this happens everywhere. Probably the more unique aspects to Rust are being spread thin, precedence of high quality crates, and that Rust gives a level of control that is addictive and effects other parts of projects.
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.
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.
Common theme in open source: contributor doesn't agree with maintainer feedback, becomes petty, takes ball and goes home. Most of the time this is solved by patience and leaving ego at the door. Or forking.
Open-source maintainers should merge everything that _I_ consider reasonable, because _I_ know better than them!
If they don't, I'll call it a tragedy.
If they don't, I'll call it a tragedy.
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.
It looks to me that the maintainers straight up don't think the feature is important. But the author seems to miss the fact that by making a PR he is actually creating a burden for the maintainers. They are not in anyway obliged to merge it or even look at it. If he actually cared and wanted to contribute he would look for bugs not for new features. The way I see it new feature development is a right to be earned in a codebase you can't show up and expect people to review the code and merge it because it would look great in your cv or because it takes care of that one use case you care about.
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.
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.
[deleted]
Ah, Alacritty. Reminds me of one this issue which I created a few months ago.
https://github.com/alacritty/alacritty/issues/4731
EDIT: I used it for a while in Windows before I switched to Linux where I use Kitty
https://github.com/alacritty/alacritty/issues/4731
EDIT: I used it for a while in Windows before I switched to Linux where I use Kitty
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?
https://news.ycombinator.com/item?id=29306845 "Rust Moderation Team Resigns" ?
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".
[deleted]
just fork and change whatever you need and build it. that's the magic of open source.
if someday your own personal fork gets enough attention and the use case you implemented is solid enough, it'll pick up steam and will possibly get merged (or not) into upstream.
but still, you are free to change and peruse whatever you see fit. you got a lot of work done for yourself for no effort at all. time to put in your own.
if someday your own personal fork gets enough attention and the use case you implemented is solid enough, it'll pick up steam and will possibly get merged (or not) into upstream.
but still, you are free to change and peruse whatever you see fit. you got a lot of work done for yourself for no effort at all. time to put in your own.
I think open source should be like genetics: if you want a mutation that’s not going to be part of a project, fork it.
If it’s important enough of a feature people will adopt it and it will coexist with the original project.
If that convinces the original authors of the importance of a feature, you can merge and make the world beautiful again.
If something is important to me but I have requirements that differ from the maintainers I usually maintain a fork even if I’m the only user of it.
Sometimes it attracts people with similar needs and they build on top of my changes.
Discussions in open source are a lot more discursive and mutually respecting when you’re offering to donate your work to the project because it helped fulfill a need that you had yourself, not only because it gave you a reason to invest time into it but also because you don’t usually invest time into things without a clear reason you needed that feature.
If it’s important enough of a feature people will adopt it and it will coexist with the original project.
If that convinces the original authors of the importance of a feature, you can merge and make the world beautiful again.
If something is important to me but I have requirements that differ from the maintainers I usually maintain a fork even if I’m the only user of it.
Sometimes it attracts people with similar needs and they build on top of my changes.
Discussions in open source are a lot more discursive and mutually respecting when you’re offering to donate your work to the project because it helped fulfill a need that you had yourself, not only because it gave you a reason to invest time into it but also because you don’t usually invest time into things without a clear reason you needed that feature.
This post fails to speak to me on two fronts:
* The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various *nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. The author unfortunately chose a particularly messy and bug-prone corner of the POSIX APIs to wrap, and ran into a correspondingly intensive review process. I've merged simpler wrappers[1][2] with no fuss.
* Alacritty seems to work just fine. I switched to it about two months ago, after using nothing but (heavily customized) rxvt-unicode for a decade. Maybe it's because I don't use ligatures or images in my terminals (I thought we were talking about non-"toy" functionality!), but I haven't found myself wanting for anything beyond what Alacritty already does. And the scrollback seems to work nicely. To summarize: where's the tragedy?
[1]: https://github.com/nix-rust/nix/pull/1342
[2]: https://github.com/nix-rust/nix/pull/1331
* The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various *nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. The author unfortunately chose a particularly messy and bug-prone corner of the POSIX APIs to wrap, and ran into a correspondingly intensive review process. I've merged simpler wrappers[1][2] with no fuss.
* Alacritty seems to work just fine. I switched to it about two months ago, after using nothing but (heavily customized) rxvt-unicode for a decade. Maybe it's because I don't use ligatures or images in my terminals (I thought we were talking about non-"toy" functionality!), but I haven't found myself wanting for anything beyond what Alacritty already does. And the scrollback seems to work nicely. To summarize: where's the tragedy?
[1]: https://github.com/nix-rust/nix/pull/1342
[2]: https://github.com/nix-rust/nix/pull/1331
Some background, the author is Fredrick Brennan, the creator of 8chan.
I think merged or not merged is not the problem here.
It's about learning from each other, so it's a win-win.
It's fine that your first PR doesn't get merged, just learn from other (reviews) and go on with next PRs. Just never give up.
It's about learning from each other, so it's a win-win.
It's fine that your first PR doesn't get merged, just learn from other (reviews) and go on with next PRs. Just never give up.
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.
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.
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.
> If you feel like the goals of Kitty are more aligned with your personal preferences, why not support Kitty, it's a great terminal emulator.
For what it's worth, I think this is an incredibly healthy attitude for a project maintainer to take. There are a lot of ways to go wrong managing a software project, and this attitude is a good way to avoid a big subset of common mistakes. It comes with downsides, of course, but it's important to think about the upsides too.
For what it's worth, I think this is an incredibly healthy attitude for a project maintainer to take. There are a lot of ways to go wrong managing a software project, and this attitude is a good way to avoid a big subset of common mistakes. It comes with downsides, of course, but it's important to think about the upsides too.
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.