61–70 of 120 posts
Earlier quoted context omitted.
To be explicit: I agree. But I still think it's basic decency to close the PR and tell them No. Or if you plan to leave it around make a comment to that effect.
There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.
I recall once upon a time there was a GitHub project wherein the owner would just immediately merge any PRs that were opened -- I believe it was a social experiment, and I don't recall the exact nature of the repo in order to know if that kind of thing is ludicrous here. But I do think it'd be good fun to take this lull and find out the outcome of a hypothetical github.com/open-terraform/open-terraform which just ran…
Earlier quoted context omitted.
There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.
Is there no way to just have a script add a comment on every new PR saying "Due to insufficient staff, your PR may not be reviewed for a considerable amount of time."?
Something like that?
I recall once upon a time there was a GitHub project wherein the owner would just immediately merge any PRs that were opened -- I believe it was a social experiment, and I don't recall the exact nature of the repo in order to know if that kind of thing is ludicrous here. But I do think it'd be good fun to take this lull and find out the outcome of a hypothetical github.com/open-terraform/open-terraform which just ran…
https://github.com/illacceptanything/illacceptanything
Earlier quoted context omitted.
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 don't understand why people think that just doing unsolicitied work and pressing a button means the people on the other side are obligated to spend time reviewing and integrating it. GitHub has weirdly unbalanced open source contributions with a heavier burden and burnout on maintainers. Contributing to a project doesn't mean just slinging code and calling it good. Communicate--talk to the people maintaining the co…
In the same way that the maintainers don't have an obligation to review my PR, I don't have an obligation to go find them and learn how to use IRC/bugzilla/mattermost/mailing lists/smoke signals/yodelling to communicate with them with the exact secret handshake to get a review. I can just throw a PR out there, point our code at my fork, rebase it whenever they make changes, and otherwise ignore their requirements until they either fix the bug themselves or merge my code.
Earlier quoted context omitted.
Isn't a good review at least as hard as a good PR?
No, reading code is far easier than writing it. Either way both have go be done regardless of the author.
The opposite of this: "code is much harder to read than it is to write" is held up as a ten-commandments style law of programming.
Here's why: When you write code, you as the author know exactly what it does, so you have exactly one copy of the code in your head.
But as you read code, you repeatedly run into "forks", where you encounter something you aren't sure of the meaning of. Even at a very small rate, like understanding 95% of what you're reading, and being unsure about 5%, it adds up. At every one of these points, you create multiple hypotheses of what the program actually does. Each one of these hypotheses is a full "copy" of the program, running in your head. Frequently to __really__ read code, you have to rig it up and test these hypotheses to keep the mental burden low (since directly testing it and confirming one of them collapses/nullifies all the other ones). (This is a huge reason why software that can be inspected live (lisp, javascript, etc) has a fairly high value, and why companies like MS have built fancy IDEs to enable the same thing with compiled software like C++, C#, etc. Past a certain point, you need to poke it with an inspector to test what parts of it do, in order to "read" the code.)
If you just "read code" and think you know what the program actually does — specifically by skimming over those parts where it's like "yeah, I'm not sure, but it probably does XYZ", it's a very juvenile, dangerous mindset. I don't have a polite way to put it, but it's in exactly the same bucket as the usual brogrammers who think their software has no security holes, for no reason other than that they trust their own work. This is where "programming as craftsmanship" breaks down; like other fields like structural engineering, it's better to build a bridge and know it will hold up because you did the actual material calculations (i.e. to not trust your own judgement, but to verify it externally). As opposed to building one, and simply having a hunch that it's sturdy enough to hold for no reason other than that you've built a lot of stuff, and your gut says it's solid.
Earlier quoted context omitted.
I do this. I wish I didn't. First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes…
heh. i've been considering a switch from ansible to terraform because i've been frustrated by ansible's limited support for some of the edge cases around ALBs. good to hear that terraform also sucks. i'm gradually coming to the conclusion that all the tools that are supposed to make provisioning cloud infrastructure easier aren't as good as a bunch of crappy custom scripts using boto or aws-cli.
I sometimes fool myself into thinking I can use Ansible in simple cases and that Terraform would be overkill but so far I've regretted those decisions every time.
One of these days Hashicorp is going to cash in and one of the major cloud operators will own the lingua franca of cloud provisioning. Oracle, for instance, directs the cloud users to Terraform as its de facto first class provisioning tool. It works rather well BTW.
Really hoping they go public. They are one of two tech companies I would invest in.
Earlier quoted context omitted.
To be explicit: I agree. But I still think it's basic decency to close the PR and tell them No. Or if you plan to leave it around make a comment to that effect.
There are many projects where just doing that would be the equivalent of a full time position. Even saying no requires a skilled review.