4 ms·

Is it the end of the world if your PR is not accepted immediately? If you fix is really important, you are not waiting for your PR to get accepted and make it i

Is it the end of the world if your PR is not accepted immediately? If you fix is really important, you are not waiting for your PR to get accepted and make it into a release before running it in production. Maybe there is a startup idea here, in making it easier to manage and patch third party dependencies, like how of the big tech companies do? CTA: send me a message if you like build systems and packages managers and Git and want to manage a billion forks. Worst case scenario we start a support group.

reilly3000 5y ago
There was a show-stopping bug in the AWS provider that I was watching for about 13 months before a community patch got merged. Over 200 watchers and +1’s galore. We had to spin up separate tooling and write glue scripts to cover the gap. We didn’t really consider forking the AWS provider, but that may have big a quick fix in exchange for ongoing maintenance merges and confusion.
zimbatm 5y ago
I use Nix for that all of the time. My workflow is usually like this: * upstream has a bug. * find and fix the bug, send a PR. * update the Nix code to build with either the PR branch as the source, or the PR diff as a patch. What's missing is a good tool to scan for new releases and remove the override. Other than that it works really well. It's much nicer to run a terraform provider from a branch than having to publish a temporary fork to registry.terraform.io
- arianvanp 5y ago
  I spent my last week wasting hours on end how i could ship a fork of the aws provider to support some resources that upstream refuses to add (ec2 classic link). Wasted hours on end convincing terraform not to redownload or to not have hash collisions with their built in way to do this so i indeed ended up using nix to patch and ship the terraform provider in the end! Very nice experience. My edits are purely additive so I have it as a patch file that I simply apply to the nix package definition. So far it has applied cleanly on many different terraform versions I use in the wild.
mschuster91 5y ago
> Maybe there is a startup idea here, in making it easier to manage and patch third party dependencies, like how of the big tech companies do? It's most often not as simple as "patch third party dependencies". The Linux kernel is quite infamous for having so many refactorings and reworkings that you can count the amount of proprietary drivers for current (!) kernel versions on one hand. IIRC, the only one viable at the moment is NVIDIA's weird shim, with the longest other holdout Paragon NTFS having gone for open-sourcing a couple weeks ago. Everyone else (cough Android or general embedded PSPs/BSPs) is stuck with fossilized kernel versions. Take apart any cheap router firmware and you'll likely see a 2.6.x kernel and even older u-boot versions since no one wants to do the work necessary to port over all the custom cruft to a modern version, and no one wants to commit stuff upstream as the Linux kernel maintainers won't even think about accepting the shoddy quality that is common in the embedded space, not to mention people being afraid of violating NDAs.
- yencabulator 5y ago
  > the only one viable at the moment is NVIDIA's weird shim Yeah they recently gave up on supporting older hardware on new kernels, now one of my machines is stuck on Linux 5.4 LTS. (Nouveau can't do Audio over HDMI on that hardware.)
don-code 5y ago
In a way, it is - I take on an operational overhead of rebuilding an upstream tool, periodically merging my changes with master and rebuilding, etc. This isn't something I budgeted time for, or something I even roadmapped for, which means the build process is going to be a 30-minute kludge and will likely incur greater-than-normal ongoing overhead.

reilly3000 5y ago

There was a show-stopping bug in the AWS provider that I was watching for about 13 months before a community patch got merged. Over 200 watchers and +1’s galore. We had to spin up separate tooling and write glue scripts to cover the gap. We didn’t really consider forking the AWS provider, but that may have big a quick fix in exchange for ongoing maintenance merges and confusion.

zimbatm 5y ago

I use Nix for that all of the time. My workflow is usually like this: * upstream has a bug. * find and fix the bug, send a PR. * update the Nix code to build with either the PR branch as the source, or the PR diff as a patch. What's missing is a good tool to scan for new releases and remove the override. Other than that it works really well. It's much nicer to run a terraform provider from a branch than having to publish a temporary fork to registry.terraform.io

arianvanp 5y ago
I spent my last week wasting hours on end how i could ship a fork of the aws provider to support some resources that upstream refuses to add (ec2 classic link). Wasted hours on end convincing terraform not to redownload or to not have hash collisions with their built in way to do this so i indeed ended up using nix to patch and ship the terraform provider in the end! Very nice experience. My edits are purely additive so I have it as a patch file that I simply apply to the nix package definition. So far it has applied cleanly on many different terraform versions I use in the wild.

mschuster91 5y ago

> Maybe there is a startup idea here, in making it easier to manage and patch third party dependencies, like how of the big tech companies do? It's most often not as simple as "patch third party dependencies". The Linux kernel is quite infamous for having so many refactorings and reworkings that you can count the amount of proprietary drivers for current (!) kernel versions on one hand. IIRC, the only one viable at the moment is NVIDIA's weird shim, with the longest other holdout Paragon NTFS having gone for open-sourcing a couple weeks ago. Everyone else (cough Android or general embedded PSPs/BSPs) is stuck with fossilized kernel versions. Take apart any cheap router firmware and you'll likely see a 2.6.x kernel and even older u-boot versions since no one wants to do the work necessary to port over all the custom cruft to a modern version, and no one wants to commit stuff upstream as the Linux kernel maintainers won't even think about accepting the shoddy quality that is common in the embedded space, not to mention people being afraid of violating NDAs.

yencabulator 5y ago
> the only one viable at the moment is NVIDIA's weird shim Yeah they recently gave up on supporting older hardware on new kernels, now one of my machines is stuck on Linux 5.4 LTS. (Nouveau can't do Audio over HDMI on that hardware.)

don-code 5y ago

In a way, it is - I take on an operational overhead of rebuilding an upstream tool, periodically merging my changes with master and rebuilding, etc. This isn't something I budgeted time for, or something I even roadmapped for, which means the build process is going to be a 30-minute kludge and will likely incur greater-than-normal ongoing overhead.