Somehow I always I believed that Harbormaster does not apply a patch onto master but onto the revision it was created from. Has there been any change in this behaviour recently? Janek Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:

"Unable to apply patch!" means just that. Harbormaster is unable to apply the patch (to master). You can test it yourself by running 'arc patch --nobranch D1778` on an up-to-date checkout of the master branch, and it will fail in the same way.

Solution: rebase your patch onto master, and update the Diff. You'll notice there are indeed merge problems.

On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek

wrote:

...

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this?

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

Can we somehow force Phab to apply a patch against a base commit from which the patch was created? Current setting does not seem very useful - it will probably force me to rebase my patches once a week or so. That will be very painful. Janek Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:

It changed some time last year.

Before, Harbormaster would sometimes try to build some bizarro intermediate mix of base commit + patch + master. See https://ghc.haskell.org/trac/ghc/ticket/9855.

On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek

wrote:

...

Somehow I always I believed that Harbormaster does not apply a patch onto master but onto the revision it was created from. Has there been any change in this behaviour recently?

Janek

Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:

...

"Unable to apply patch!" means just that. Harbormaster is unable to apply the patch (to master). You can test it yourself by running 'arc patch --nobranch D1778` on an up-to-date checkout of the master branch, and it will fail in the same way.

Solution: rebase your patch onto master, and update the Diff. You'll

notice

...

there are indeed merge problems.

On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek

wrote:

...

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this?

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

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

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?

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.

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

On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

* 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 Second option is an acceptable workaround for me, but having the third one would be even better. I definitely want to avoid the first one - computing power of my machine is limited.

Side note: I think we should go back to using Phabricator for finished patches only. What if we could set the default state of upload patch to "planned changes"? This way patches would end up in the review queue only when someone explicitly sets them to "Request Review". Wouldn't that solve the problem?

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.