Currently, haskell-updates is a strange creature: It's based off of a merge base of master and staging, but merges into staging.

This has some disadvantages:

• GItHub's UI keeps showing "fake" merge conflicts that don't really exist.
• Real conflicts come in from time to time, that can't be resolved before actually merging into staging.
• Once the branch is conflicted, its Eval job will not run against the merged result in staging anymore, but only on the branch itself. This means a merge can introduce eval failures on staging.
• In special cases we might end up not being able to fix Eval on haskell-updates, yet, because this would break Eval on the branch itself, which then would cause hydra to fail.

In the referenced special case, we can work around it by not generating a warning like this - but in general, we will not be able to avoid having cases where Eval will fail, but we still want to merge. This, but also the requirement to resolve conflicts on merge doesn't work with "required status checks to pass before merge", which we recently enabled. (Currently, they can still be bypassed, but ideally, we'll be able to disable that in the future!)

I think up until somewhere around 24.11 branch-off, we still based haskell-updates on master and also merged it back into that branch. This didn't work well, because these merges induced huge rebuilds, for example for everything using shellcheck (but I think there were others, too).

The reason we went with the current construct is, I think, because:

• We need something as a base that is already mostly cached - otherwise the rebuilds we do for all the haskell packages, need to rebuild a lot of dependencies additionally.
• We can't target master due to the number of rebuilds on merge.

I think that in the meantime staging has changed so that hydra also builds its stdenv regularly. Does that mean basing off and into staging could be an option?

Alternatively, would using staging-next help in any way?

Or, if that doesn't work either: Could we re-target master, but somehow add a bigger hydra job before merging into master again?

Or.. could we get rid of these dependencies somehow (I think there were ideas to move shellcheck into passthru tests, for example), to be able to get back to a simple workflow directly targeting master?

@NixOS/haskell @emilazy @K900 @mweinelt @vcunat