These things happen, props to Hashicorp for communicating about it. It would be easy to say that this is a failure of open-source in some way, but to do so would be unfair to the huge amount of work that companies put into tools like this, and the stewardship that they offer, both of which take a lot of time and money. If periods of low activity while teams change are the cost the community needs to pay for that, I t…
They don't happen to community projects like Node.js, Rust, Vue, or Debian.
Perhaps this is apples and oranges, but I'm most interested in open source projects that are governed by a foundation.
The beauty of open source is you can run your project however you want: bazzar, cathedral, or something else. If people think its a bad choice, they can fork.
These things happen, props to Hashicorp for communicating about it. It would be easy to say that this is a failure of open-source in some way, but to do so would be unfair to the huge amount of work that companies put into tools like this, and the stewardship that they offer, both of which take a lot of time and money. If periods of low activity while teams change are the cost the community needs to pay for that, I t…
They don't happen to community projects like Node.js, Rust, Vue, or Debian. Perhaps this is apples and oranges, but I'm most interested in open source projects that are governed by a foundation.
Community projects fall behind on PRs all the time. Many of them are permanently behind.
Props to them for being honest, but it's still not a good look for Hashicorp. Their stewardship of Terraform leaves a lot to be desired. For years now I've watched Terraform PRs just wither on the vine. You get the impression that nobody is working on the AWS provider at all. Every PR to the AWS provider that I've ever cared about has taken years to be reviewed and merged despite lots of thumbs-ups and comments from users begging for it to be merged. This has been ongoing for years. There is clearly a priority problem here.
I had a conversation with my coworkers when I worked there about being upfront with folks that we wouldn't review or accept their PR and stop leaving people hanging (this was on the TFE provider). I'm glad this was added. I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored.
I’ve made PRs because I need the change for my day job. By the time I’ve traced an issue down to a third party library the cost of making a PR is minimal. But if they don’t want to take the changes, it doesn’t bother me. Of course I don’t work on open source out of passion, so I could imagine this is different for the true believers.
Out of interest then how do you proceed? Do you fork the code and run your own patched version?
Surely community patches are such a good return on investment they should be pulling devs off other areas to keep someone on reviewing public prs. I've always been confused by companies that aren't over the moon to spend minimal review time to get the benefit of hours of work by free employees.
Getting people to submit PRs that stand up to your requirements can be a nontrivial exercise.
I’ve made PRs because I need the change for my day job. By the time I’ve traced an issue down to a third party library the cost of making a PR is minimal. But if they don’t want to take the changes, it doesn’t bother me. Of course I don’t work on open source out of passion, so I could imagine this is different for the true believers.
Out of interest then how do you proceed? Do you fork the code and run your own patched version?
Surely community patches are such a good return on investment they should be pulling devs off other areas to keep someone on reviewing public prs. I've always been confused by companies that aren't over the moon to spend minimal review time to get the benefit of hours of work by free employees.
Getting people to submit PRs that stand up to your requirements can be a nontrivial exercise.
In addition, many people will only contribute once or twice. The result is that you as a maintainer may need to invest a lot of time, while the results are minimal.
Surely community patches are such a good return on investment they should be pulling devs off other areas to keep someone on reviewing public prs. I've always been confused by companies that aren't over the moon to spend minimal review time to get the benefit of hours of work by free employees.
There are no free lunches, pull requests are no exception. For starters, before merging every pull request needs to be reviewed at a minimum. That by itself can oftentimes be a very time-consuming activity, especially if the changes are from someone outside the circle of regular contributors. Outside of fixes for typos and other trivialities, pull requests generally require a lot of back and forth to get to a good state — does this change make sense architecturally, does it cover edge cases, does it come with tests? Additionally, oftentimes pull requests expand the scope of what you need to maintain, whether you want to take on that permanent burden is a critical question in and of itself. The list goes on. There are many projects that do make it work, but make no mistake that this takes a considerable amount of effort.
Out of interest then how do you proceed? Do you fork the code and run your own patched version?
Yes, just use our own forked version.
So then when your upstream repo diverges would you just rebase and manually add in anything you want from the forked development tree on the upstream side?
Not sure what's best practice so... just curious how people have handled this - I usually leave my forks of stuff pretty stale and focus on my own little sub-pieces to achieve what I want but not too much else.