[HN Gopher] Terraform is currently not reviewing community pull ...
___________________________________________________________________
Terraform is currently not reviewing community pull requests
Author : jaxxstorm
Score : 77 points
Date : 2021-09-05 17:11 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| shadycuz wrote:
| Maybe they are desperate enough to hire me
| mrtweetyhack wrote:
| nobody's THAT desperate haha _jk_
| danpalmer wrote:
| 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 think that's very fair.
| leetrout wrote:
| 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.
| jdavis703 wrote:
| 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.
| mrtweetyhack wrote:
| If you spent the time and effort to hunt down the problem
| for them, the least they could do is look into it. repos
| that don't care enough are a waste of time.
| mwaitjmp wrote:
| Out of interest then how do you proceed? Do you fork the
| code and run your own patched version?
| jdavis703 wrote:
| Yes, just use our own forked version.
| arthurcolle wrote:
| 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.
| benatkin wrote:
| 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.
| wmf wrote:
| Community projects fall behind on PRs all the time. Many of
| them are permanently behind.
|
| Also, foundation != community.
| braddeicide wrote:
| 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.
| devoutsalsa wrote:
| Getting people to submit PRs that stand up to your requirements
| can be a nontrivial exercise.
| YorickPeterse wrote:
| 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.
| Etheryte wrote:
| 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.
| OJFord wrote:
| Isn't a good review at least as hard as a good PR?
| bawolff wrote:
| I don't see anything wrong with that.
|
| 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.
| lloydatkinson wrote:
| Wow. Glad I started using ARM/Bicep for my recent learning about
| devops.
| dagss wrote:
| ARM is a complete joke, and Bicep compiles down to ARM.
|
| (More details: ARM is simply a dumb script that says "do this,
| do that", it doesn't interact with your cloud resources in any
| smart way. As one example: You can download a template for an
| Azure SQL instance from the Azure portal. That template will
| then randomly fail to execute, because it contains two
| "configuration" child resources of Azure SQL, which ARM will
| try to deploy in paralell, but oh, they touch the same parent
| sources, so they crash with an error...
|
| Then try to add depends_on in order to have it, perhaps, not
| fail.
|
| Or how about the Azure SQL feature where, if you block Azure
| SQL to only AD logins, you'd have to declare an administrator
| password on first ARM run (resource creation), then remove it
| on subsequent ARM runs (resource update) because having it is
| then prevented...
|
| These aren't minor issue or glitches; it's symptomatic of a
| system that's just built in the wrong way from ground up. ARM
| isn't a stateless description of your resources, it's an
| awkward scripting language (although since the APIs it
| interacts with are idempotent the difference isn't obvious at
| first).
|
| How Microsoft could decide to have Bicep compile to ARM is
| beyond me -- Azure has some good features (refer to resources
| by name rather than allocated ID) that could greatly simplify
| the approach that Terraform/Pulumi takes if they only targeted
| Azure -- why didn't Microsoft do that instead, give us
| Terraform/Pulumi for Azure without having to keep a statefile
| (especially a statefile with secrets in it).
| electroly wrote:
| 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.
| OJFord wrote:
| (Minor contributor, perhaps major issue-opener-commenter
| speaking)
|
| I have a lot of respect for the team personally (as in myself),
| though I do recognise what you say completely too. I just think
| there's a lot of focus on trying to do things right, and long-
| term-maintainably, that it often presents with a poor outlook
| or like there's a lack of interest.
|
| @apparentlymart from OP in particular - I have no idea who he
| in Hashicorp hierarchy, I just recognise him from GitHub - in
| particular is really excellent in responding to good issues and
| adding information along the lines of 'yes we want this but
| unfortunately XYZ so we're hoping PQR is going to make this
| easier but first we need to ABC so yes but sorry not a priority
| right now' sort of thing.
___________________________________________________________________
(page generated 2021-09-05 23:00 UTC)