
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Just to chime in here: I agree with Janek that the current requirement that Phab always cherry-picks changes against master is annoying. I have a limited amount of computing power available locally, and it's much easier to push to Phab than to slow down my primary dev machine for 2+ hours. (Yes, it takes my machine 2+ hours to validate.) And rebasing a big patch frequently is even more annoying, even though it inevitably must be done in the end.</div><div><br></div><div>That said, I also agree that we wish to accept patches that validate only when compared against HEAD.</div><div><br></div><div>So, I wonder if a diff in Phab can have a new state, WIP. A WIP patch doesn't show up in the review queue and validates against its own base commit. When the author is ready for a full review, the author changes the state to Please Review, which then shows up in queues and validates only against master.</div><div><br></div><div>Thomas's suggestion is essentially "don't post WIP patches". But posting a WIP patch is very helpful, serving two needs:</div><div> 1) Validation that doesn't tie up a local machine.</div><div> 2) Allows for early feedback on a patch. Several times, I've had some work-in-progress that has benefitted from an early review. And I've provided early reviews that saved the author time from burrowing down the wrong hole.</div><div><br></div><div>Is this possible? Is this desirable to others, too?</div><div><br></div><div>Thanks,</div><div>Richard</div><br><div><div>On Jan 18, 2016, at 12:09 PM, Thomas Miedema <<a href="mailto:thomasmiedema@gmail.com">thomasmiedema@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek <span dir="ltr"><<a href="mailto:jan.stolarek@p.lodz.pl" target="_blank">jan.stolarek@p.lodz.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> If you are working from an old base commit, either rebase your patch before<br>

> submitting to Phabricator (painful? you will have to do it before pushing<br>

> anyway, might as well do it now), or ignore the Harbormaster validate<br>

> result.<br>

</span>I am typically working on some non-trivial features (ie. rebases tend to be painful). Having<br>

Harbormaster build results is a useful way of telling whether I broke something or not. Even if<br>

it is for some older commit. Rebases take time and if I know my feature will not be finished in<br>

the next couple of weeks I want to save myself from unnecessary rebasing. Why rebase all the time<br>

if I can do it just once at the end?<br></blockquote><div><br></div><div>There are a few options:</div><div><br></div><div>* you validate locally (in a different build directory, so you can keep using build flavour = devel2 in your development directory)</div><div>* fork the ghc github repository, push your branch there, and let Travis validate it: <a href="https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis">https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis</a></div><div>* ask Austin for some special Phabricator syntax that you could add when you submit the patch, to request Harbormaster not to rebase onto HEAD before validating </div><div><br></div><div><br></div><div>Side note: I think we should go back to using Phabricator for finished patches only. It slows the review process down, when there are 50 patches in the queue waiting-for-review-but-not-really: <a href="https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/">https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/</a> Sometimes it leads to finished patches actually getting ignored for a long time, because the reviewers still think the author is working on them. But other might think differently, and maybe it's not a big deal.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><div class="h5"><br>

Janek<br>

<br>

---<br>

Politechnika Łódzka<br>

Lodz University of Technology<br>

<br>

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.<br>

Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę<br>

prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.<br>

<br>

This email contains information intended solely for the use of the individual to whom it is addressed.<br>

If you are not the intended recipient or if you have received this message in error,<br>

please notify the sender and delete it from your system.<br>

</div></div></blockquote></div><br></div></div>

_______________________________________________<br>ghc-devs mailing list<br><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br></blockquote></div><br></body></html>