Testing GHC against Hackage via CI

[Ben Gamari]

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190305/270086e7/attachment.sig>