<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 26 September 2016 at 20:13, Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> writes:<br>
<br>
> I would rather we *didn't* accept contributions via github, even for small<br>
<span class="">> patches, and instead put more effort into streamlining the Phabricator<br>
> workflow.<br>
><br>
><br>
</span>>    - Adding another input method complicates the workflow, users have to<br>
<span class="">>    decide which one to use<br>
><br>
</span>I think we would want to try to sell the GitHub route as "if you would<br>
like to contribute then we would strongly prefer you use Phabricator,<br>
but if you must and it's a small patch, we will accept it via GitHub."<br></blockquote><div><br></div><div>But this is opening the floodgates a crack... how do we know what a "small" patch is?  What happens when someone submits a patch that's too large?  The patches will get larger, we'll have to do code reviews on two different tools, and it will be really hard to go back.  I just have a bad feeling about this.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>    - Github is not integrated with our other infrastructure, while<br>
>    Phabricator is<br>
><br>
True, but I suspect for the small documentation patches that we are<br>
currently consider this shouldn't matter so much.<br>
<br>
>    - Mutliple sources of contributions makes life harder for maintainers<br>
><br>
It does certainly put yet another task on our plates, but I would argue<br>
that it's actually easier than accepting patches via Trac, which we<br>
already do.<span class=""><br></span></blockquote><div><br></div><div>We should stop accepting patches via Trac too :)<br></div><div><br></div><div>Cheers<br></div><div>Simon<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>    - I also like the idea of auto-push if validate succeeds.  Or a button<br>
<span class="">>    that you can press on the diff that would do the same thing, so you can get<br>
>    code review first.<br>
><br>
</span>To be clear, I'm a bit weary of opening up the auto-push feature to new<br>
contributors. While regular contributors know what changes can be safely<br>
pushed and which require review, we have no guarantee that a new<br>
contributor has developed these sensibilities.<br>
<br>
>    - +1 to making the manual easier to build.  The same goes for Haddocks;<br>
<span class="">>    it's really hard to make a simple patch to the docs and test it right now.<br>
><br>
</span>The users guide should be quite possible to do.<br>
<br>
I don't believe there is any reliable way to allow a contributor to<br>
build the haddocks without having built GHC (since you need GHC master to<br>
parse `base`, et al.); that being said, we could have Harbormaster<br>
upload built documentation somewhere and then leave a link to it on the<br>
Diff.<br>
<span class=""><br>
> One other thing that came up but wasn't mentioned in the notes: let's be<br>
> more prompt about reverting patches that break validate, even if they only<br>
> break a test.  Now that we have better CI support, we can easily identify<br>
> breaking patches and revert them.<br>
><br>
</span>Agreed.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div><br></div></div>