<div dir="ltr">Ben wrote:<div>> <span style="font-size:12.8px">Admittedly this is where a Git-based workflows have a bit of an</span><br></div><div><span style="font-size:12.8px">> advantage: it is much more convenient to merge a group of commits in a</span><br style="font-size:12.8px"><span style="font-size:12.8px">> structure-preserving manner via a git branch than a stack of</span><br style="font-size:12.8px"><span style="font-size:12.8px">> differentials.</span><br style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So if both parent commits of a merge commit were guaranteed to build and test, would that be enough? Or would you still want to insist that all commits of both branch build and compile? Technically, it's easy to do (just make the CI script loop through each commit between merge base and branch tip). But would you be willing to pay for (sometimes substantially) longer validation times just to guarantee a pristine history?</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think I'm once again confused about what the requirements really are here, and in what order of preference. Once we know that, I'm confident many technical solutions could satisfy them.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Note that we can decouple the question of whether to manage contributions via PR's or otherwise from the review tool question. One could imagine contributions *always* going through GitHub PR's, but say *always* reviewed via Phabricator (say via an import/sync tool discussed many times before but never actually implemented).</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">--<br>Mathieu Boespflug<br>Founder at <a href="http://tweag.io" target="_blank">http://tweag.io</a>.</div></div>
<br><div class="gmail_quote">On 12 December 2017 at 16:54, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Manuel M T Chakravarty <<a href="mailto:manuel.chakravarty@tweag.io">manuel.chakravarty@tweag.io</a>> writes:<br>
<br>
</span><span class="">> Hi Ben,<br>
><br>
>> Am 12.12.2017 um 02:22 schrieb Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>>:<br>
>><br>
</span><span class="">>> I personally think that we should strive for your first point (every<br>
>> commit should be validate-clean) before attempting to tackle your<br>
>> second. I, for one, am rather skeptical that putting all of your patches<br>
>> through review would significantly affect quality.<br>
><br>
> I completely agree.<br>
><br>
</span>On re-reading what I wrote above, I realize that it was a bit unclear.<br>
To clarify, the sentence<br>
<span class=""><br>
>> I, for one, am rather skeptical that putting all of your patches<br>
>> through review would significantly affect quality.<br>
<br>
</span>was intended to mean "I am not convinced that quality would improve as a<br>
result of review". Is this what you are agreeing with?<br>
<span class=""><br>
<br>
> So, what is preventing us from disabling direct pushes to master and<br>
> requiring all contributions to go through a PR or Differential?<br>
><br>
> PRs and Differentials are squashed on merging to master and the whole<br>
> problem (with CircleCI building only heads of commit groups) just<br>
> disappears. I believe that this is the usual approach.<br>
><br>
</span>We generally don't want to squash. Those who typically commit directly<br>
generally master generally take pains to ensure that their commit<br>
history is sensible. This history is valuable, both for the future<br>
readers of the code as well as later bisection; projecting it out is<br>
quite undesirable.<br>
<br>
We could indeed require that Simon, et al. open Differentials for each<br>
of their commits. However, as I mentioned earlier it doesn't seem likely<br>
that putting these commits through rigorous review would be fruitful<br>
relative to the work it would require; these differential would be just<br>
be for merging. Unfortunately, the cost of creating a differential is<br>
non-trivial and I'm not certain that we want to make Simon pay it for<br>
every commit.<br>
<br>
Admittedly this is where a Git-based workflows have a bit of an<br>
advantage: it is much more convenient to merge a group of commits in a<br>
structure-preserving manner via a git branch than a stack of<br>
differentials.<br>
<span class=""><br>
> If the outstanding issue is that you combine multiple contributions<br>
> from contributors and manually valid them to ensure they are not just<br>
> individually sound, but also in combination, we might want to consider<br>
><br>
</span>>   <a href="https://bors.tech" rel="noreferrer" target="_blank">https://bors.tech</a> <<a href="https://bors.tech/" rel="noreferrer" target="_blank">https://bors.tech/</a>><br>
<span class="">><br>
> which is exactly for that kind of thing (and apparently used by Rust).<br>
<br>
</span>Indeed, I'm familiar with bors. Unfortunately it's quite GitHub-centric,<br>
so at for the moment it's not a viable option.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>______________________________<wbr>_________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>devops-group</a><br>
<br></blockquote></div><br></div>