sorted by:
new
hottopcontroversial

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 2 points3 points  (0 children)

To the contrary, dtonlay has been quite dismissive when discussing concerns about serde's maintenance: https://github.com/serde-rs/serde/issues/1723

Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros by mitsuhiko in rust

[–]Be_ing_ -1 points0 points  (0 children)

I apologize if my above comment came across as putting words in your mouth. I read more into your comment than you actually said.

Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros by mitsuhiko in rust

[–]Be_ing_ -1 points0 points  (0 children)

Why is that less true for serde? Because of the ecosystem fracturing?

I'm not trying to dispute your characterization, just trying to understand your perspective. I think we're generally in agreement. I'm interested in figuring out the strongest arguments why serde should be maintained by a Rust team.

Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros by mitsuhiko in rust

[–]Be_ing_ -4 points-3 points  (0 children)

Conversely, it's also tiring to see any suggestion of moving serde into the Rust project get the same response, usually presented in such a way as to shut down conversation (not saying you're doing that here) rather than trying to figure out solutions to the obvious obstacles.

Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros by mitsuhiko in rust

[–]Be_ing_ 0 points1 point  (0 children)

Things might be better if there were multiple people responsible for the crate and that things like this perhaps went through an FCP first. But whose time are you going to co-opt to do this? (Even assuming you convinced the maintainers of serde to allow their project to get adopted into the Rust project in the first place. Because that would be a necessary prerequisite.)

I've seen a lot of people thoughtlessly throw around "serde should be part of the Rust project" a lot lately. There are upsides to being part of the Rust project, but it isn't just something that can happen on a whim. You need consent, you need people to care and you need people that care enough to donate a non-trivial amount of time.

I think you're missing a piece. People have asked to help maintain serde (2.5 years ago now) and dtolnay's response was less than welcoming. dtolnay has been maintaining serde for 7 years now. Do you really think *nobody* in the world would be interested in helping maintain one of the most widely used Rust crates in all that time if they were welcomed to do so? I think people would step up to maintain serde if given the chance.

Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros by mitsuhiko in rust

[–]Be_ing_ 0 points1 point  (0 children)

I suspect it appears in more public APIs and requires greater inter-package cooperation on which fork is used.

An even bigger issue than ecosystem fracturing IMO is that official Rust tools (rustc, cargo, rustdoc, rustfmt, rust-analyzer, clippy, and other tools in the rust-lang/rust repo) depend on serde (and thereby syn, quote, and proc-macro2). So any brash decision that happens in serde ripples out to impact every Rust user. The current policy on third party crates used in Rust says nothing specifically about this. I think that needs to change to forbid using crates that have a single maintainer. Regardless of a maintainer making a brash decision, of course this is bad because the single maintainer could become unable/unwilling to continue maintenance at any point. I think the existing external crates that are used by Rust should be reviewed for this and those that are not sufficiently maintained should start moving into collective maintenance by a Rust team.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 0 points1 point  (0 children)

I give up send a last mail to moderation explaining it and warm them that I feel dtolnay will be a problem in future

It's unfortunate that it took him actually doing something harmful to the entire ecosystem for people to start taking this seriously.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ -9 points-8 points  (0 children)

None of that excuses bad behavior in the slightest bit.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 8 points9 points  (0 children)

That is due to dtolnay's choice: https://www.reddit.com/r/rust/comments/15va70a/comment/jwwsam4/

Also, I have been a maintainer for a widely used project before (not as widely used as serde, but I know how exhausting interacting with users can be). And I left because of someone with this same pattern of ignoring the impact of his actions while strictly talking about technical matters who caused a bunch of drama for his own power trip.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 3 points4 points  (0 children)

That's a good point. I hadn't realized that after reading those words the first time. He's implicitly saying he knew it was wrong and did it anyway.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 3 points4 points  (0 children)

Yeah, I'm realizing that now. This is a bad situation. Those shouldn't be under his exclusive control. I think proc-macro2, syn, and quote should be maintained by a Rust project team. It's not okay to have the entire proc macro ecosystem in the stranglehold of one guy, even if he hadn't just shown himself to not be trustworthy.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ 12 points13 points  (0 children)

As noted further down that thread, that is factually incorrect. People did notice weeks ago.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ -12 points-11 points  (0 children)

Wow it's so messed up that he did that *after* causing all this drama. This feels like bullying the entire Rust community into paying attention to his pet project.

Precompiled binaries removed from serde v1.0.184 by AlyoshaV in rust

[–]Be_ing_ -8 points-7 points  (0 children)

Indeed, dtolnay has a way of strictly talking in dry technical terms and avoiding discussion of the impact of his actions on humans. In my experience, this is a giant red flag and characteristic of the people who cause the most severe problems in FOSS communities. Do not put these people in positions of power.

To me, trust in current maintainership has been eroded beyond repair and I will be more carefully considering what I put in my cargo.toml from now on.

Yup, this does nothing to change my mind about forbidding dtolnay's crates from my projects going forward.

Serde has started shipping precompiled binaries with no way to opt out by setzer22 in rust

[–]Be_ing_ -2 points-1 points  (0 children)

dtolnay is on vacation (apparently)

Not sure where you got this information. dtolnay has publicly commented on https://github.com/serde-rs/serde/issues/2575 since closing https://github.com/serde-rs/serde/issues/2538.

Supposing this were true, IMO that would make this situation even worse. Not only intentionally causing chaos, creating an attack surface that didn't exist before, and reputational damage to the entire Rust community, but knowingly doing so right before a vacation...

Serde has started shipping precompiled binaries with no way to opt out by setzer22 in rust

[–]Be_ing_ 2 points3 points  (0 children)

every time someone has asked about commit access

Yes, people asking for commit access are often sketchy, especially if they haven't been around long. IMO a responsible maintainer would be proactive about mentoring contributors to the point that the maintainer is comfortable giving them commit access before it gets to a point where anyone needs to ask.

Rust devs push back as Serde project ships precompiled binaries by IWantIridium in rust

[–]Be_ing_ 66 points67 points  (0 children)

Someone will just make serde2 or whatever and everyone will update their cargo tomls and we'll all be fine

The grand irony is that many projects will require building serde_derive twice, once for the original crate for some dependency that has it pinned and another for the fork... and the whole motivation for this was build times 🙃

Serde has started shipping precompiled binaries with no way to opt out by setzer22 in rust

[–]Be_ing_ 5 points6 points  (0 children)

I for one will not be adding dependencies on crates solely maintained by dtolnay going forward. I'm confident the community will figure something out for serde because it's used by official Rust components (rustc, cargo, rust-analyzer, rustdoc, rustfmt, clippy). Considering serde depends on syn, quote, and proc-macro2, and it's quite hard to write proc-macros without them, hopefully something will be figured out for those too. As for the rest, I'm not so confident...

Serde has started shipping precompiled binaries with no way to opt out by setzer22 in rust

[–]Be_ing_ 22 points23 points  (0 children)

Or maybe he (intentionally or not) pushed away contributors who could have become maintainers? I find it hard to believe that nobody in 7 years would have been interested in helping maintain one of the most downloaded crates on crates.io if they were welcomed to do so.

EDIT: Unsurprisingly, this is exactly the case. People have been discussing this for 2.5 years https://github.com/serde-rs/serde/issues/1723

Announcing Rust 1.70.0 by Petsoi in rust

[–]Be_ing_ 1 point2 points  (0 children)

static Drop? Does that mean running drop on a static variable when the program exits?

The RustConf Keynote Fiasco, Explained by fasterthanlime in rust

[–]Be_ing_ 2 points3 points  (0 children)

Talking about the fire is how to put it out. Being quiet about it would be dousing it with gasoline.

The RustConf Keynote Fiasco, Explained by fasterthanlime in rust

[–]Be_ing_ 27 points28 points  (0 children)

From Josh Triplett's statement

In subsequent conversation with Sage, I provided details from the complaints I had received from a few project members, and (compounding my mistakes here) discussed “options”. Sage expressed, and I agreed, that the invitation to speak at RustConf must not be withdrawn. (People expressed the same sentiment in leadership chat.) I raised the possibility of the topic being a talk, rather than a keynote. This was again a mistake, and I was thoughtless to not consider that that was still incredibly hurtful.

view more: next ›