Phab failing to apply patches

[Richard Eisenberg]

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.

That said, I also agree that we wish to accept patches that validate only when compared against HEAD.

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.

Thomas's suggestion is essentially "don't post WIP patches". But posting a WIP patch is very helpful, serving two needs:
 1) Validation that doesn't tie up a local machine.
 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.

Is this possible? Is this desirable to others, too?

Thanks,
Richard

On Jan 18, 2016, at 12:09 PM, Thomas Miedema <thomasmiedema at gmail.com> wrote:

> 
> 
> On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > If you are working from an old base commit, either rebase your patch before
> > submitting to Phabricator (painful? you will have to do it before pushing
> > anyway, might as well do it now), or ignore the Harbormaster validate
> > result.
> I am typically working on some non-trivial features (ie. rebases tend to be painful). Having
> Harbormaster build results is a useful way of telling whether I broke something or not. Even if
> it is for some older commit. Rebases take time and if I know my feature will not be finished in
> the next couple of weeks I want to save myself from unnecessary rebasing. Why rebase all the time
> if I can do it just once at the end?
> 
> There are a few options:
> 
> * you validate locally (in a different build directory, so you can keep using build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
> * 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 
> 
> 
> 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: https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ 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.
> 
> 
> 
>  
> 
> Janek
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> 
> This email contains information intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message in error,
> please notify the sender and delete it from your system.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160118/686382e6/attachment.html>