Phab failing to apply patches

Jan Stolarek jan.stolarek at p.lodz.pl
Mon Jan 18 17:24:34 UTC 2016


I agree with everything Richard said.

Janek

Dnia poniedziałek, 18 stycznia 2016, Richard Eisenberg napisał:
> 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



---
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.


More information about the ghc-devs mailing list