3 ms·

We have code reviews and stuff for this. It's also totally possible for somebody to spend hours setting something up and then develop really bad code - it might

We have code reviews and stuff for this. It's also totally possible for somebody to spend hours setting something up and then develop really bad code - it might even be more likely in situations where time is a constraint. Having people jump through arbitrary hoops that have nothing to do with the matter at hand is not a good thing. This is especially the case with rust which isn't exactly the most beginner friendly language to begin with.

johnisgood 8y ago
Code reviews, yes. Not all projects can afford to go through millions of contributions because the barrier was lowered or eliminated. So in that case it is not necessary a good thing to accept lazy contributions.[1] And before someone misinterprets, sure, you can work endless hours on a contribution and then submit it easily. This is not the case I am talking about, and this is not what we have observed in the case of these package managers either. Or at least that's what I did when I took a look at npm. If it's not polluted because anyone can submit their garbage easily, then what is at fault, exactly? [1] We are still talking about a package manager, and this project specifically.
- captainbland 8y ago
  I think that as a package maintainer, you can set the bar(rier) as high or as non-existent as you like. If you've got a lot of contributors, you've almost certainly got some regular contributors who you'd be able to trust to review/triage things for you. Otherwise just stick a big note saying 'we're full up, not accepting PRs, find another project, file or support a bug, the princess is in another castle' on your readme. I think they'll get the message. I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project. Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself. I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.
  - johnisgood 8y ago
    Ah, I don't like the idea of artificial barriers either, but what other package managers have seems to be good enough. Look, I came across a neat program written in Rust, and this is how the recommended way to install it looks like: https://streamable.com/iyq6b https://streamable.com/iyq6b. The video is truncated, and it took 16 minutes to finish! This entire "making it easier for everyone to contribute" idea encourages and enables such outcomes. It does sound good, but in practice it is not as good. I understand that it is up to this particular project to avoid dependencies, but that is not what I have seen in ALL pieces of Rust software that I came across. It just seems more prevalent in such ecosystems. Maybe it brings together people who think it is a good idea to depend on 2 lines of code and as many libraries as possible, I don't know. Remember the days when it was encouraged to have as fewer dependencies as possible? It seems like these days are over because of such ideas.
    - captainbland 8y ago
      I can totally sympathise with this - especially when if you look at the project's cargo.toml it looks simple enough, but turns out to have a boat load of transitive dependencies as seems to be the case with that project. Plus the experience is somewhat exacerbated by Rust just generally being quite slow to compile. I think there's a mindset that is imported from agile business culture, more than anything else, that if you're not developing functional requirement business features as fast as humanly possible while meeting the bare minimum for quality then you're being slow and inefficient compared to the guy who's willing to do that. This same mindset also makes it completely unlikely that a tool with any kinds of barriers to entry which would have to be overcome on company time will ever gain any adoption. The other side of that coin is that where there are community projects which are not supported by companies where developers are just working in their spare time, often around work and so on, to develop something they think might be interesting but cannot commit to making everything the best it could possibly be while also realistically getting the thing done. It also has to work everywhere, it has to look pretty, it can't just work on whatever version of Windows is current and have done with it. Then there is just a logic to using dependencies because they've already been battle tested for you, there's a decent chance those developers have done a better job than you would given whatever limitations that you have simply because they've put the time and effort into it already. Maybe somebody's even paying them to do it.

johnisgood 8y ago

Code reviews, yes. Not all projects can afford to go through millions of contributions because the barrier was lowered or eliminated. So in that case it is not necessary a good thing to accept lazy contributions.[1] And before someone misinterprets, sure, you can work endless hours on a contribution and then submit it easily. This is not the case I am talking about, and this is not what we have observed in the case of these package managers either. Or at least that's what I did when I took a look at npm. If it's not polluted because anyone can submit their garbage easily, then what is at fault, exactly? [1] We are still talking about a package manager, and this project specifically.

captainbland 8y ago
I think that as a package maintainer, you can set the bar(rier) as high or as non-existent as you like. If you've got a lot of contributors, you've almost certainly got some regular contributors who you'd be able to trust to review/triage things for you. Otherwise just stick a big note saying 'we're full up, not accepting PRs, find another project, file or support a bug, the princess is in another castle' on your readme. I think they'll get the message. I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project. Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself. I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.
- johnisgood 8y ago
  Ah, I don't like the idea of artificial barriers either, but what other package managers have seems to be good enough. Look, I came across a neat program written in Rust, and this is how the recommended way to install it looks like: https://streamable.com/iyq6b https://streamable.com/iyq6b. The video is truncated, and it took 16 minutes to finish! This entire "making it easier for everyone to contribute" idea encourages and enables such outcomes. It does sound good, but in practice it is not as good. I understand that it is up to this particular project to avoid dependencies, but that is not what I have seen in ALL pieces of Rust software that I came across. It just seems more prevalent in such ecosystems. Maybe it brings together people who think it is a good idea to depend on 2 lines of code and as many libraries as possible, I don't know. Remember the days when it was encouraged to have as fewer dependencies as possible? It seems like these days are over because of such ideas.
  - captainbland 8y ago
    I can totally sympathise with this - especially when if you look at the project's cargo.toml it looks simple enough, but turns out to have a boat load of transitive dependencies as seems to be the case with that project. Plus the experience is somewhat exacerbated by Rust just generally being quite slow to compile. I think there's a mindset that is imported from agile business culture, more than anything else, that if you're not developing functional requirement business features as fast as humanly possible while meeting the bare minimum for quality then you're being slow and inefficient compared to the guy who's willing to do that. This same mindset also makes it completely unlikely that a tool with any kinds of barriers to entry which would have to be overcome on company time will ever gain any adoption. The other side of that coin is that where there are community projects which are not supported by companies where developers are just working in their spare time, often around work and so on, to develop something they think might be interesting but cannot commit to making everything the best it could possibly be while also realistically getting the thing done. It also has to work everywhere, it has to look pretty, it can't just work on whatever version of Windows is current and have done with it. Then there is just a logic to using dependencies because they've already been battle tested for you, there's a decent chance those developers have done a better job than you would given whatever limitations that you have simply because they've put the time and effort into it already. Maybe somebody's even paying them to do it.