Richard Eisenberg
How will this affect workflow of developers submitting patches? For example, suppose I write a user-facing change that breaks some of these packages. Am I expected to patch up the breakage? How? Will the CI infrastructure detect this before merging or after?
To be clear, I don't have specific answers I'm looking for here. In particular, I think it's reasonable to ask that the developer of a user-facing feature make sure that head.hackage works with the feature. This has the distinct advantage of making sure the developer knows that their patch breaks code and how it must be fixed. Indeed, this can all be fodder to force the developer to update the GHC migration guide alongside their work in fixing head.hackage. I just want to know what the steps are. :)
All very good questions. Frankly, many of them are still open. I should have made this clearer: The short answer is that in the short term very little is changing. head.hackage is, at the moment, merely another tool that we can use to evaluate contributions and identify regressions in the compiler; it's not (yet) a requirement that MRs pass the job. The reason is that I don't think we are yet in a position to start requiring contributors to update head.hackage. For one, the workflow for doing so is arguably not well enough documented (something that I will be working to fix). Moreover, it's quite unclear to me exactly how much work maintaining this infrastructure is going to require. I'd like to better understand this before requiring that contributors put in the work. Cheers, - Ben