<div dir="ltr"><div>William Casarin recently tweeted a link to the bitcoincore devs ACK system[1], which are<br><br><pre><code>Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.

utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.

Tested ACK - Reviewed the code changes and have verified the functionality or bug fix.

ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.

NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
</code></pre><br><br>[1] <a href="https://github.com/bitcoin/bitcoin/issues/6100">https://github.com/bitcoin/bitcoin/issues/6100</a><br><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 September 2017 at 18:37, Richard Eisenberg <span dir="ltr"><<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, this works for me.<br>
<br>
As for merging, I'm always very grateful when Ben does it -- though I agree that it would make more sense for me to do it when I can test-then-merge.<br>
<br>
Thanks,<br>
Richard<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Sep 13, 2017, at 10:29 AM, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br>
><br>
> Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> writes:<br>
><br>
>> On 19 August 2017 at 03:56, Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br>
>><br>
>>> Hi devs,<br>
>>><br>
>>> When reviewing a diff on Phab, I can "accept" or "request changes".<br>
>>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo)<br>
>>> changes, but then when these changes are made, I accept. I'm leery of<br>
>>> making the suggestions and saying "accept", because then someone working<br>
>>> quickly may merge without noticing the typos. Does Phab have such an option?<br>
>>><br>
>><br>
>> "Accept with nits" is standard practice, but you're right it can go wrong<br>
>> when someone else is merging accepted diffs.  We could adopt a standard<br>
>> comment keyword, e.g. "NITS" that indicates you'd like the nits to be fixed<br>
>> before committing, perhaps?<br>
>><br>
> Sounds reasonable to me.<br>
><br>
><br>
>> Also, I don't think it's a good idea to merge commits when the author is a<br>
>> committer, they can land themselves.<br>
>><br>
> I would be quite happy to not have to merge such patches; I merely merge<br>
> them currently since I thought it was generally expected.<br>
><br>
> On the other hand, I generally do integration builds on the batches of<br>
> patches that I merge which can sometimes catch validation issues.<br>
> However, I expect this will be less of an issue with the<br>
> test-before-merge support in the pipeline.<br>
><br>
> Cheers,<br>
><br>
> - Ben<br>
><br>
<br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">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-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>