<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<br class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The currently recommended workflow is that your commit should be in<br class="">the ghc-head branch before the merge to GHC takes place. This enforces</blockquote></div><div class=""><br class=""></div><div class="">This seems problematic: everyone is going to race to get their changes into Haddock's <font face="Menlo" class="">ghc-head</font> first, then block everyone else’s Haddock-touching patches from building with CI until the GHC side of the first person's changes goes through too. And that might take some time if Marge finds problems with the patch. I propose the workflow be:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Once you’ve finished your patch, rebase the GHC side on top of upstream GHC <font face="Menlo" class="">master</font></li><li class="">Rebase the Haddock side on top of upstream Haddock <font face="Menlo" class="">ghc-head</font></li><li class="">Once Marge merges your MR, fast-forward the upstream <font face="Menlo" class="">ghc-head</font> to your new commit</li></ol></div><div class=""> </div><div class=""><div class="">That way, multiple MR’s with Haddock parts can “race” to get merged. Whoever loses just has to rebase. Ideally, we would have Marge doing both the rebasing and step #3 for us. In the place of Marge, anyone who has write access to Haddock should feel free to do step #3 too (like when Marge merges an MR while the author of the MR is busy doing other things… like sleeping).</div><div class=""><br class=""></div><div class="">As a side note, I do wish there was an easy way in GitLab to quickly jump to the diffs of submodules (or at least an easy way to copy the new commit hash).</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Alec</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 13, 2019, at 4:13 AM, Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" class="">matthewtpickering@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I tried adding back the linters which check to make sure a commit is<br class="">in the upstream branch before a MR is merged but got blocked by a<br class="">gitlab issue.<br class=""><br class=""><a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/395" class="">https://gitlab.haskell.org/ghc/ghc/merge_requests/395</a><br class=""><br class="">The currently recommended workflow is that your commit should be in<br class="">the ghc-head branch before the merge to GHC takes place. This enforces<br class="">some linearisation but it stops the tree breaking.<br class=""><br class="">Matt<br class=""><br class="">On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class="">On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault@gmail.com> wrote:<br class=""><blockquote type="cite" class=""><br class="">The right way to solve this problem is probably to find a better way of factoring GHC-specific functionality out and putting only that in the GHC tree. This is a good long term goal, but I don’t think we are quite there yet. Some other ongoing changes in both GHC and Haddock are blocking the way forward on this front…<br class=""></blockquote><br class=""><br class="">In the meantime, there is no way to make atomic updates to GHC and Haddock (which need to happen regularly). And GHC's master and the ghc-head branch keep getting out of sync. It's really hard to diagnose, until it blocks someone's valuable time. At which point it's too late.<br class=""><br class="">Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree?<br class="">_______________________________________________<br class="">ghc-devs mailing list<br class="">ghc-devs@haskell.org<br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></blockquote></div></div></blockquote></div><br class=""></div></div></body></html>