Under your workflow it doesn't seem like the commit which ends up in master will point to a commit on ghc-head?
This is problematic when doing bisection if the branch where the commit lives is deleted or force pushed to. I would prefer a workflow which is more annoying for contributors but doesn't leave the tree in a bad state than one which is convenient but dangerous. Cheers, Matt On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault <alec.theria...@gmail.com> wrote: > > Hi, > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > > > This seems problematic: everyone is going to race to get their changes into > Haddock's ghc-head 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: > > Once you’ve finished your patch, rebase the GHC side on top of upstream GHC > master > Rebase the Haddock side on top of upstream Haddock ghc-head > Once Marge merges your MR, fast-forward the upstream ghc-head to your new > commit > > > 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). > > 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). > > Thanks, > Alec > > On Mar 13, 2019, at 4:13 AM, Matthew Pickering <matthewtpicker...@gmail.com> > wrote: > > I tried adding back the linters which check to make sure a commit is > in the upstream branch before a MR is merged but got blocked by a > gitlab issue. > > https://gitlab.haskell.org/ghc/ghc/merge_requests/395 > > The currently recommended workflow is that your commit should be in > the ghc-head branch before the merge to GHC takes place. This enforces > some linearisation but it stops the tree breaking. > > Matt > > On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud <arnaud.spiw...@tweag.io> > wrote: > > > > On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theria...@gmail.com> > wrote: > > > 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… > > > > 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. > > Is there a short term solution which would alleviate that cost, besides > merging Haddock in the main Ghc tree? > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
