Skip to content

Work out better way of interacting with boot library upstreams

Currently our protocol for tracking boot library upstreams is a bit painful. Namely, I periodically try updating the library submodules, typically all at once, and see what breaks. We then have to go about pushing various patches fixing the breakage. After a week or three when all of these patches are upstream we can try bumping the submodules again. Ideally nothing else has broken and we can push the result. However, let's just say that Murphy's law has an unfortunately truth to it.

I wonder whether moving in the direction of what we currently do with haddock would be an improvement. Namely, we maintain a ghc-head branch of each of the libraries. We can then pull upstream in master and make fixes as necessary. These changes can then be asynchronously pushed upstream. In principle, we could even try pulling nightly to catch issues early. Of course, prior to a release we would ensure that ghc-head sat on a proper master commit.

Anyways, I've been meaning to do something about this. Another task for post-8.2.

Trac metadata
Trac field Value
Version 8.0.1
Type Task
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information