Question about `validate` workflow
Hello, I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming. I am using CPUS=4 ./validate --fast Can I do something, to "validate continue", at least until I get a basic validate to pass? I don't mind redoing everything one final time to make sure things are OK, it is just that it seems wasteful while I am fixing things. -Iavor
I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming.
$ ./validate --help ... --no-clean don't make clean first, just carry on from a previous interrupted validation run ... I don't know if it works!
It does work, and it's very useful. Edward Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800:
I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming.
$ ./validate --help ... --no-clean don't make clean first, just carry on from a previous interrupted validation run ...
I don't know if it works!
I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC.
Admittedly, this is a bad workflow if you're expecting a bunch of extraneous-import failures (and such) during validation, but I just wanted to make sure you knew of this option.
Richard
On Nov 8, 2014, at 7:50 PM, "Edward Z. Yang"
It does work, and it's very useful.
Edward
Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800:
I was wondering how do other devs `validate` their tree? In particular, I just merged a whole bunch of stuff and am validating things. However, every time something goes wrong (e.g., unused import warning), the whole process starts from the beginning, which is quite time consuming.
$ ./validate --help ... --no-clean don't make clean first, just carry on from a previous interrupted validation run ...
I don't know if it works!
ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hi, Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC.
of course this spams ghc-commits quite a lot. So while I think it’s reasonable to use this method to validate something that you expect to pass, I would advice using your own GitHub fork if you do trial and error. It’s just takes a few clicks or so to set it up, including enabling Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On Nov 9, 2014, at 2:42 PM, Joachim Breitner
Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC.
of course this spams ghc-commits quite a lot.
Which brings me to ask: why send email to ghc-commits for `wip/*` branch commits? I've personally gone back and forth between using the main GHC repo for my WIP because of precisely this issue. If there were no emails generated, I would surely always use the GHC repo -- it's easier for others to find my work, and tracking a branch in my head is easier than a separate remote and a branch. As it is, I'm always slightly embarrassed when I push to my `wip/rae` branch, causing other people to get emails about my internal GHC meanderings. But, I'm using GHC's repo now for better integration with Phab, for when Harbormaster pulls base commits. So, I propose: Do not send commit emails for commits to `wip/*` branches. What do we think? Thanks, Richard
Hi, Am Sonntag, den 09.11.2014, 21:53 -0500 schrieb Richard Eisenberg:
Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC.
of course this spams ghc-commits quite a lot.
Which brings me to ask: why send email to ghc-commits for `wip/*` branch commits? I've personally gone back and forth between using the main GHC repo for my WIP because of precisely this issue. If there were no emails generated, I would surely always use the GHC repo -- it's easier for others to find my work, and tracking a branch in my head is easier than a separate remote and a branch. As it is, I'm always slightly embarrassed when I push to my `wip/rae` branch, causing other people to get emails about my internal GHC meanderings. But, I'm using GHC's repo now for better integration with Phab, for when Harbormaster pulls base commits.
So, I propose: Do not send commit emails for commits to `wip/*` branches.
What do we think?
of course it is nice to know what others are working on, and someone interested in your particular thing might have a look. But especially due to rebasing the current commit message setup does not work for wip branches. We could experimenting with just sending those „branch wip/foo's head updated“ mails, i.e. only one mail per push, listing the git commit titles. That would greatly reduce the traffic, while still giving some indication of action. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On Nov 10, 2014, at 3:33 AM, Joachim Breitner
We could experimenting with just sending those „branch wip/foo's head updated“ mails, i.e. only one mail per push, listing the git commit titles. That would greatly reduce the traffic, while still giving some indication of action.
I like this idea, as it still allows those who want to watch something closely to do so. Thanks, Richard
participants (5)
-
Edward Z. Yang -
Iavor Diatchki -
Joachim Breitner -
Richard Eisenberg -
Thomas Miedema