Results of nixpkgs-review pr 83526

https://github.com/NixOS/nixpkgs/pull/83526
1 package marked as broken and skipped:
python38Packages.qiskit-ibmq-provider

5 package built:
python27Packages.scikit-build python37Packages.qiskit-aer python37Packages.scikit-build python38Packages.qiskit-aer python38Packages.scikit-build

python38Packages.qiskit-ibmq-provider fails due to python38Packages.uvloop disabled on master #78343.

Thoughts on target branch?

@GrahamcOfBorg build python27Packages.scikit-build python37Packages.scikit-build python38Packages.scikit-build

Thoughts on target branch?

It should target master, as you've done here, and then once merged to master send a PR to release-20.03 that has run git cherry-pick -x <commit> for the commit(s) you'd like to backport (or ask a maintainer to do this step).

If the build were idiosyncratically broken on the 20.03 branch only, then it'd make sense to send just to 20.03; but in this case we have real fixes we'd like to get to master, and then backport afterwards.

If the PR change were going to cause hundreds of package rebuilds, we'd send it to staging, which batches the rebuild-the-world PRs together to avoid excessive binary churn on master.

@bhipple thanks for the detailed reply :)

You're welcome!

I can also squash these two commits, just wanted to keep logically separate.

Under most circumstances I'd agree, but since your patch is really just limited to the patches section, and the diff is still quite readable even all taken as 1 commit, and since we're about to cherry-pick it onto another branch, I'd say squash it in this case.

Great, thanks! Can you send the backport PR? Just run cherry-pick -x branched off of release-20.03, then send a PR with [20.03] in the title, like this one for example:

#83550

@bhipple #83774