OK thanks @sclv, that does clarify your position to me. I still think that leaves some would-be ecosystems-proposals that don’t involve resourcing at all in the lurch, but we can ignore that for now as it doesn’t pertain to proposal.
In this case, I may as well ask my question here – as compared to what we have now, what’s the difference? If it is multiple head.hackage instances[…]? […] even a recently released ghc could also benefit from this, so having at least two (current release, genuine head) could be a win. Is that about it?
I took this to be one about overlay per release, and one for HEAD. When ever a release is cut, the overlay is also cut to make a new GHC.X.hackage.
The big questions to me are thus:
- Do
GHC.X.hackages need to modified post release? - Are changes ever worth applying to multiple releases?
I think the answer is “yes” to both, because it is possible (if a bit tragic) for a library to release a new version that doesn’t yet support the latest released GHC.
In that case, it probably makes sense put the corresponding patch in the oldest GHC.X.Hackage that needs it (i.e. the one for newest GHC it doesn’t support), and then merge that into all the new ones since?
This makes me think that multiple branches is better than multiple repos.