test packages on the staging, staging-next branches as well as master

[samuela]

It's often the case that large, sweeping changes are made on staging/staging-next that break builds. This is problematic due to the massive number of commits between successful and broken versions, making bisecting very annoying. It would be nice to run all of the canary builds on all three branches: master, staging, staging-next.

[SuperSandro2000]

You don't need to bisect builds. Most if not all of the time it is more time effective to take a look at the error and figure out whats wrong from there.

Also building staging all the time is a bad idea because you are going to compile a lot of stdenvs and compilers.

[samuela]

You don't need to bisect builds. Most if not all of the time it is more time effective to take a look at the error and figure out whats wrong from there.

I've found bisecting to be useful in a number of scenarios. If nothing else, it allows me to go to the author of the breakage with 100% certainty that it was their change that broke the build.

Also building staging all the time is a bad idea because you are going to compile a lot of stdenvs and compilers.

Agreed, but how else do you propose I address the issues raised in this post?

[SuperSandro2000]

Agreed, but how else do you propose I address the issues raised in this post?

I would suggest to build python-updates and staging-next when the PR is older than a day or two to make sure you are not compiling the world which can take 12 hours.

it allows me to go to the author of the breakage with 100% certainty that it was their change that broke the build.

Well, yes, that true. Maybe I fiddled to much with python packages that I gave up on this.