Not sure I see this in such a rose-tinted way. The linked ‘bug report’ is full of people specifying very exact ways that they want to be warned beforehand: I want a blog post, the post has to be dedicated specifically to this one thing, I don’t read Reddit, the tool itself should loudly warn me several months in advance.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
Nothing is perfect for sure. There were some more spicy commentary on this on social media, for example. But, it’s all about the overall ratio, and the outcome.
Notably, none of these comments actually volunteer any help with any of the above.
I both agree and disagree. I think it’s normal in bug reports to report the bug, and wait for a decision to be made, before offering help. I’m sure that if they asked for help, they would have gotten it. There’s actually a pretty high degree of social cohesion here, which may not be obvious to outsiders, but I recognize virtually all of the names on that ticket, and so like, I think it’s sort of understood that if active help was desired, all you have to do is ask. The original reporter is on the language team, for example.
Even the maintainer is talking about rustup as a ‘Rust project product’.
The Rust Project has long described their output as a product. There’s pros and cons to this, but it’s been the norm for at least 12 years now. I do attribute that style of thinking to be one of the reasons why Rust has been successful.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
As an ex-lead of the Rust project: I don’t think the Rust project needs more volunteers all the time. It has capacity for fixes, so just stating problems is fine. A lot of people in the discussion are also people who contribute to Rust at other places, by writing libraries, etc.
I think treating a tool as a product of some kind is an important part of ensuring it delivers value to users. There are several things this mindset implies, such as having a product vision rather than just exposing your internals and calling it a day.
Not to downplay the role that thoughtful people played, but I also think a large part of why this went so well is that, unbeknownst to I think everyone, rustup actually had (and has) staged rollouts. Specifically there’s a small number of CI systems that update it promptly, and everyone else that gets the update… someday.
Your average desktop user appears to be similarly insulated. I just checked and I’m still running the release before the problematic one… I’m not sure when/how this automatically updates, but apparently not promptly.
This meant that the population impacted was relatively small (for such a widely used tool). Which helps a lot with avoiding piling on.
It’s a little more complex than that; when you update or install a toolchain, by default, rustup will automatically update itself. This means cases like CI get updates immediately, while users may not see it as long. It’s not so much about staging as it is about usage patterns.
This meant that the population impacted was relatively small (for such a widely used tool). Which helps a lot with avoiding piling on.
I think projects like actix-web dying is not a bad thing per se. There are already a dozen extremely interchangeable web frameworks. No project has an intrinsic right to exist.
Not sure I see this in such a rose-tinted way. The linked ‘bug report’ is full of people specifying very exact ways that they want to be warned beforehand: I want a blog post, the post has to be dedicated specifically to this one thing, I don’t read Reddit, the tool itself should loudly warn me several months in advance.
Notably, none of these comments actually volunteer any help with any of the above. Even the maintainer is talking about rustup as a ‘Rust project product’. I feel like everyone’s framing is wrong here…
Nothing is perfect for sure. There were some more spicy commentary on this on social media, for example. But, it’s all about the overall ratio, and the outcome.
I both agree and disagree. I think it’s normal in bug reports to report the bug, and wait for a decision to be made, before offering help. I’m sure that if they asked for help, they would have gotten it. There’s actually a pretty high degree of social cohesion here, which may not be obvious to outsiders, but I recognize virtually all of the names on that ticket, and so like, I think it’s sort of understood that if active help was desired, all you have to do is ask. The original reporter is on the language team, for example.
The Rust Project has long described their output as a product. There’s pros and cons to this, but it’s been the norm for at least 12 years now. I do attribute that style of thinking to be one of the reasons why Rust has been successful.
As an ex-lead of the Rust project: I don’t think the Rust project needs more volunteers all the time. It has capacity for fixes, so just stating problems is fine. A lot of people in the discussion are also people who contribute to Rust at other places, by writing libraries, etc.
I think treating a tool as a product of some kind is an important part of ensuring it delivers value to users. There are several things this mindset implies, such as having a product vision rather than just exposing your internals and calling it a day.
thank you for writing this up @steveklabnik! It’s refreshing to see something called out that went well
Not to downplay the role that thoughtful people played, but I also think a large part of why this went so well is that, unbeknownst to I think everyone, rustup actually had (and has) staged rollouts. Specifically there’s a small number of CI systems that update it promptly, and everyone else that gets the update… someday.
Your average desktop user appears to be similarly insulated. I just checked and I’m still running the release before the problematic one… I’m not sure when/how this automatically updates, but apparently not promptly.
This meant that the population impacted was relatively small (for such a widely used tool). Which helps a lot with avoiding piling on.
It’s a little more complex than that; when you update or install a toolchain, by default, rustup will automatically update itself. This means cases like CI get updates immediately, while users may not see it as long. It’s not so much about staging as it is about usage patterns.
I do agree that this plays into things, though.
I think projects like actix-web dying is not a bad thing per se. There are already a dozen extremely interchangeable web frameworks. No project has an intrinsic right to exist.
[Comment removed by author]