<div dir="ltr"><div class="markdown-here-wrapper" style=""><blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:0px 0px 1.2em!important">What is this bad state?</p>
</blockquote>
<p style="margin:0px 0px 1.2em!important">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).</p>
<p style="margin:0px 0px 1.2em!important">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.</p>
<ul style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px">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)</li>
<li style="margin:0.5em 0px">You need two independent sets of approval to get either part of a patch merged.</li>
<li style="margin:0.5em 0px">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.</li>
<li style="margin:0.5em 0px">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.</li>
</ul>
<p style="margin:0px 0px 1.2em!important">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.</p>
<p style="margin:0px 0px 1.2em!important">/Arnaud</p>
<div title="MDH:PGRpdj4mZ3Q7IFdoYXQgaXMgdGhpcyBiYWQgc3RhdGU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp
dj5JIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHRoYXQgaWYgeW91IGRvbid0IHB1c2ggdG8gaGFkZG9j
ay9naGMtaGVhZCBmaXJzdCwgdGhlbiB0aGUgY29tbWl0IGluIGdoYy9tYXN0ZXIgd291bGQgcG9p
bnQgdG8gYSBjb21taXQgd2hpY2ggaGFzIG5vIGd1YXJhbnRlZSB0byBiZSBkdXJhYmxlOiBpdCBt
YXkgYmUgcmViYXNlZCBvciBzcXVhc2hlZCwgYnkgdGhlIHRpbWUgaXQgZ2V0cyB0byBnaGMtaGVh
ZC4gVGhpcyBtZWFucyB0aGF0IGFmdGVyIHRoZSBjb21taXQgaGFzIGJlZW4gbXV0YXRlZCwgdGhl
IGNvbW1pdCBpbiBnaGMgaXMgbm8gbG9uZ2VyIGEgdmFsaWQgY2hlY2tvdXQgKGJlY2F1c2UgaXQg
Y2FuJ3QgY2hlY2tvdXQgaXRzIEhhZGRvY2sgc3VibW9kdWxlKS48L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2PkluIHRoZSBjdXJyZW50IHNpdHVhdGlvbiwgaXQgaXMgaW1wZXJhdGl2ZSB0aGF0IGhh
ZGRvY2svZ2hjLWhlYWQgaXMgdXBkYXRlZCBmaXJzdC4gSWYgd2Ugd2FudCB0byBwcmVzZXJ2ZSB0
aGUgbW9zdCBtaW5pbWFsIG9mIGludmFyaWFudC4gSXQgaXMgc3RpbGwgYSBwcmV0dHkgYXdmdWwg
c2l0dWF0aW9uIHRvIGJlIGluLCB0byBiZSBob25lc3QuPC9kaXY+PGRpdj4tIEl0J3MgcmF0aGVy
IGhhcmQgdG8gZW5mb3JjZSwgc28gaWYgb25lIGZvcmdldHMgdG8gdXBkYXRlIGhhZGRvY2svZ2hj
LWhlYWQgZmlyc3QsIHRoZW4gd2UgYXJlIGJhY2sgdG8gc3F1YXJlIG9uZS4gKEkgc3VwcG9zZSB0
aGF0LCBpbiBjb25zdHJhc3QsIGluIE1hdHRoZXcncyBsaW50ZXIgY2hhbmdlLCB3ZSB3b3VsZCBo
YXZlIHJlZCBDSSBkdXJpbmcgdGhlIGVudGlyZSByZXZpZXcgcGhhc2Ugb2YgYW4gTVIuIFdoaWNo
IHdvdWxkIGJlIHJhdGhlciBpbmNvbnZlbmllbnQsIHRvIHNheSB0aGUgbGVhc3QpPGJyPjwvZGl2
PjxkaXY+LSBZb3UgbmVlZCB0d28gaW5kZXBlbmRlbnQgc2V0cyBvZiBhcHByb3ZhbCB0byBnZXQg
ZWl0aGVyIHBhcnQgb2YgYSBwYXRjaCBtZXJnZWQuPC9kaXY+PGRpdj4tIFR3byBNUiB3aGljaCB3
YW50IHRvIG1vZGlmeSBIYWRkb2NrIHdpbGwgbmVlZGxlc3NseSBjb25mbGljdCB3aXRoIG9uZSBh
bm90aGVyLiBXaGVuIG9uZSBoYXMgaXRzIEhhZGRvY2sgbW9kaWZpY2F0aW9uIG1lcmdlZC4gVGhl
IG90aGVyIHJlcXVpcmVzIHVwZGF0ZXMgKGl0J3Mgc3VwZXIgdGVkaW91cyB0byByZWJhc2UgYSBo
aXN0b3J5IGFuZCBiZSBjbGVhbiBpZiB0aGVyZSBhcmUgc2V2ZXJhbCBjb21taXQgd2hpY2ggdG91
Y2ggSGFkZG9jaywgYnkgdGhlIHdheSkuIEFuZCB0cmlnZ2VyIHVubmVjZXNzYXJ5IGNvbnN1bXB0
aW9uIG9mIG91ciBhbHJlYWR5IHByZWNpb3VzIENJIHJlc291cmNlcy48L2Rpdj48ZGl2Pi0gSW4g
ZmFjdCwgYW55IG1lcmdpbmcgb2YgYSBjaGFuZ2UgdG8gaGFkZG9jay9naGMtaGVhZCB3aWxsIHJl
cXVpcmUgcmV3cml0aW5nIHRoZSBoaXN0b3J5IG9mIHRoZSBNUiB0aGF0IG5lZWRzIGl0LiBBbHNv
IHVubmVjZXNzYXJ5IGNvbnN1bXB0aW9uIG9mIENJIHJlc291cmNlcy48L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2PlF1aXRlIGZyYW5rbHksIHRoaXMgaXMgbm90IGEgZnVuIHBsYWNlIHRvIGJlLiBJ
dCBtYXkgYmUgd29ydGggdGFraW5nIGEgc3RlcCBiYWNrIGFuZCBjb250ZW1wbGF0aW5nIHRoZSBz
aXR1YXRpb24gd2UndmUgYnVpbHQgZm9yIG91cnNlbHZlcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48
ZGl2Pi9Bcm5hdWQ8YnI+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 3:19 PM Alec Theriault <<a href="mailto:alec.theriault@gmail.com">alec.theriault@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite">Under your workflow it doesn't seem like the commit which ends up in<br>master will point to a commit on ghc-head?<br></blockquote></div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite">This is problematic when doing bisection if the branch where the<br>commit lives is deleted or force pushed to.</blockquote></div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite">I would prefer a workflow which is more annoying for contributors but<br>doesn't leave the tree in a bad state than one which is convenient but<br>dangerous.</blockquote></div><div><br></div><div>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 <font face="Menlo">ghc-head</font> 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).</div><div><br></div><div>Thanks,</div><div>Alec</div><div><div><br><div><blockquote type="cite"><div>On Mar 13, 2019, at 6:59 AM, Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:</div><br class="gmail-m_6918019680469193453Apple-interchange-newline"><div><div>Under your workflow it doesn't seem like the commit which ends up in<br>master will point to a commit on ghc-head?<br><br>This is problematic when doing bisection if the branch where the<br>commit lives is deleted or force pushed to.<br><br>I would prefer a workflow which is more annoying for contributors but<br>doesn't leave the tree in a bad state than one which is convenient but<br>dangerous.<br><br>Cheers,<br><br>Matt<br><br>On Wed, Mar 13, 2019 at 1:42 PM Alec Theriault <<a href="mailto:alec.theriault@gmail.com" target="_blank">alec.theriault@gmail.com</a>> wrote:<br><blockquote type="cite"><br>Hi,<br><br>The currently recommended workflow is that your commit should be in<br>the ghc-head branch before the merge to GHC takes place. This enforces<br><br><br>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:<br><br>Once you’ve finished your patch, rebase the GHC side on top of upstream GHC master<br>Rebase the Haddock side on top of upstream Haddock ghc-head<br>Once Marge merges your MR, fast-forward the upstream ghc-head to your new commit<br><br><br>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).<br><br>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).<br><br>Thanks,<br>Alec<br><br>On Mar 13, 2019, at 4:13 AM, Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br><br>I tried adding back the linters which check to make sure a commit is<br>in the upstream branch before a MR is merged but got blocked by a<br>gitlab issue.<br><br><a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/395" target="_blank">https://gitlab.haskell.org/ghc/ghc/merge_requests/395</a><br><br>The currently recommended workflow is that your commit should be in<br>the ghc-head branch before the merge to GHC takes place. This enforces<br>some linearisation but it stops the tree breaking.<br><br>Matt<br><br>On Wed, Mar 13, 2019 at 9:17 AM Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br><br><br><br>On Wed, Mar 6, 2019 at 11:04 PM Alec Theriault <<a href="mailto:alec.theriault@gmail.com" target="_blank">alec.theriault@gmail.com</a>> wrote:<br><br><br>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><br><br><br>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><br>Is there a short term solution which would alleviate that cost, besides merging Haddock in the main Ghc tree?<br>_______________________________________________<br>ghc-devs mailing list<br><a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br><br><br></blockquote></div></div></blockquote></div><br></div></div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>