#13532: Work out better way of interacting with boot library upstreams -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13532 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler