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.
Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
51–60 of 245 posts
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#52I'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.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#53I 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
Do you need tabs still if you use tmux by default?
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#54Earlier quoted context omitted.
>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 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.
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!”
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#55I 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 redu…
> 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.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#56A 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.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#57I 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
Do you need tabs still if you use tmux by default?
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 :-).
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#58I 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
by reading through the issues in Alacritty you realize that it's optimized for a very specific set of use cases, for example if you're using a tiling window manager you don't miss tabs at all (in fact they are an annoyance)
Or tmux.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#59Posts 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…
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.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#60My 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.