conda-forge / conda-forge/aws-sdk-cpp-feedstock
Benefit of output separation - bring back everything under aws-sdk-cpp?
- Dominant language
- Batchfile
- Stars
- 1
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Description
I'm wondering what gains we're getting from having
```
aws-c-auth
aws-c-cal
aws-c-common
aws-c-compression
aws-c-event-stream
aws-c-http
aws-c-io
aws-c-mqtt
aws-c-s3
aws-c-sdkutils
aws-checksums
aws-crt-cpp
s2n
```
all being migrated separately. It's generating a lot of churn, and I'm not sure what gain we get in return?
It might make sense to rather just implicitly migrate through this package?
W.r.t. to the costs that any benefits would need to offset (IMO) the very frequent migrations for all of the above packages. That alone creates a lot of maintenance on the pinning repo, but worse than that, they often logjam because one of the packages involved automerges a new version while another migration is still running, requiring manual intervention.
While the above migrations are mostly internal (i.e. don't cause rebuilds of packages outside of `aws-*`), and we finally reduced the number of "external" migrations due to `aws-sdk-cpp` in #662, there are still ways this amps up the maintenance elsewhere.
For example, I added `aws-crt-cpp` as a host-dep to arrow because the link check complained otherwise, which worked without too much hassle for some time, but now generated 3 migrations (times 4 maintenance branches) in a very short succession (https://github.com/conda-forge/arrow-cpp-feedstock/pull/1224, https://github.com/conda-forge/arrow-cpp-feedstock/pull/1229, https://github.com/conda-forge/arrow-cpp-feedstock/pull/1240)
CC @conda-forge/aws-sdk-cpp @conda-forge/core
Contributor guide
Assessment
This issue has not been assessed yet.