Haddock tree spongled

Thu Mar 14 11:07:42 UTC 2019

What is this bad state?

I think the problem is that if you don’t push to haddock/ghc-head first,
then the commit in ghc/master would point to a commit which has no
guarantee to be durable: it may be rebased or squashed, by the time it gets
to ghc-head. This means that after the commit has been mutated, the commit
in ghc is no longer a valid checkout (because it can’t checkout its Haddock
submodule).

In the current situation, it is imperative that haddock/ghc-head is updated
first. If we want to preserve the most minimal of invariant. It is still a
pretty awful situation to be in, to be honest.

   - It’s rather hard to enforce, so if one forgets to update
   haddock/ghc-head first, then we are back to square one. (I suppose that, in
   constrast, in Matthew’s linter change, we would have red CI during the
   entire review phase of an MR. Which would be rather inconvenient, to say
   the least)
   - You need two independent sets of approval to get either part of a
   patch merged.
   - Two MR which want to modify Haddock will needlessly conflict with one
   another. When one has its Haddock modification merged. The other requires
   updates (it’s super tedious to rebase a history and be clean if there are
   several commit which touch Haddock, by the way). And trigger unnecessary
   consumption of our already precious CI resources.
   - In fact, any merging of a change to haddock/ghc-head will require
   rewriting the history of the MR that needs it. Also unnecessary consumption
   of CI resources.

Quite frankly, this is not a fun place to be. It may be worth taking a step
back and contemplating the situation we’ve built for ourselves.

/Arnaud

On Wed, Mar 13, 2019 at 3:19 PM Alec Theriault <alec.theriault at gmail.com>
wrote:

> Under your workflow it doesn't seem like the commit which ends up in
> master will point to a commit on ghc-head?
>
>
> Correct, but at most the head commit will be out of sync (and a fast
> forward merge should be always possible). Step 3 is about rectifying that
> situation.
>
> This is problematic when doing bisection if the branch where the
> commit lives is deleted or force pushed to.
>
>
> We still end up with an easy-to-bisect linear history (in both Haddock and
> GHC) at the end of the day. I fear I may be misunderstanding your point
> here.
>
> 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.
>
>
> What is this bad state? Perhaps I’m again misunderstanding, but how does
> your proposal help leave the tree in a better state? As soon as someone
> preparing a GHC patch pushes changes directly to ghc-head and before
> those changes get merged, the situation is going to be just as confusing
> for everyone else trying to do something with Haddock (and not easily
> fixable either).
>
> Thanks,
> Alec
>
> On Mar 13, 2019, at 6:59 AM, Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
>
> 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.theriault at 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 <
> matthewtpickering at 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.spiwack at tweag.io>
> wrote:
>
>
>
> On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <alec.theriault at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190314/d9258ba6/attachment.html>