On Jul 22, 2014, at 9:58 AM, Austin Seipp
Hi Richard,
Sorry for missing this email - it slid out of my queue...
No worries on the delay. I wouldn't be surprised if there is a Best Practices document somewhere which advises waiting at least several days to respond to a work-related email with a human emotion in the subject line. :) I appreciate your thorough answers below.
2) I develop and build in the same tree. This means that I often have a few untracked files in the outer, ghc.git repo that someone hasn't yet added to .gitignore. Thus, I need to say `--allow-untracked` to get `arc diff` to work. I will likely always need `--allow-untracked`, so I looked for a way to get this to be configured automatically. I found https://secure.phabricator.com/book/phabricator/article/arcanist/#configurat... , but the details there are sparse. Any advice?
No, it doesn't look like it I'm afraid. I asked upstream about it this morning (it was very easy to write a patch for), and unfortunately they do not want to allow this feature (it's very easy to add it as a config option, but I digress).
In the mean time, you can use 'arc alias' to create a version of 'arc diff' like what you want:
$ arc alias udiff diff -- --allow-untracked
Then run:
$ arc udiff
instead.
I think this is really a short-term solution; in the long run we should commit .gitignore entries for everything since the reason for this is that having untracked files is generally a liability that should be caught.
Thanks for the `alias` tip. I think that having an always-updated .gitignore might be difficult from a practical standpoint, because each different architecture might produce different files. Of course, I could add entries myself, but I'm always quite scared of touching anything interacting with the build system.
[snip] I personally suggest that we take the pain on these as an opportunity to remove things, per recent discussions. We can't remove it all in one swoop, but we should start being aggressive about enforcing style errors.
In short, I'd suggest you
- Add silly excuses for now - Land your changes - Commit fixes for the lint errors *after* that. - Commit lint fixes one file at a time.
If we keep doing this, we'll begin making a lot of headway on this, I'm sure. (The nice thing is that now, you can be lazy and fix violations, then let Phabricator or Travis-CI do builds for you.)
Not a bad plan. I've personally come around to the "let's just de-tab now and get on with it" camp, even though it will give me a painful merge. I think my (and others') painful merge is less painful than the status quo.
6) When I looked at my posted revision, it said that the revision was "closed"... and that I had done it! slyfox on IRC informed me that this was likely because I had pushed my commits to a wip/... branch. Is using wip branches with Phab not recommended? Or, can Phab be configured not to close revisions if the commit appears only in wip/... branches?
Joachim ran into this today.
In short, I fixed this by tweaking the repository settings. Phabricator will now autoclose commits ONLY if they occur on the master branch.
This means you should feel free to push to wip/* branches as much as you want without fear now. Sorry!
Great. Thanks!
7) How can I "re-open" my revision?
I'm afraid you can't.
Is this worth pushing upstream as a feature request? Even absent technical glitches like the wip/* stuff, I could see wanting to do this. Say there is a subtle revision that accumulates a bit of commentary. It lands after general consensus that the revision is good. Then, someone discovers that it was wrong, after all. It would be nice to continue the original conversation instead of starting afresh, I would think.
8) Some time after posting, phaskell tells me that my build failed. OK. This is despite the fact that Travis was able to build the same commit (https://travis-ci.org/ghc/ghc/builds/30066130). I go to find out why it failed, and am directed to build log F3870 (https://phabricator.haskell.org/file/info/PHID-FILE-hz2r4sjamkkrbf7nsz6b/). I can't view the file online, but instead have to download and then ungzip it. Is it possible to view this file directly? Or not have it be compressed?
This is a bug in my script because it's a piece of crap, both the failure and the build logging. I'm working on a Much Better Version™ not written in Shell script but Haskell that should fix all this, hopefully I can deploy it soon. It will also include more features that may or may not actually work. :)
I'd prefer to keep the log files compressed if that's OK. An uncompressed log from ./validate is over *ten* megabytes already, and it doesn't even correctly capture *all* of the logs! In comparison, the .gz version is a short 300kb. That's a crazy space savings, especially since this bot will hopefully report more soon.
Is it possible then to use some web-server magic to call gunzip and then push the result down the wire? Not a big deal, and not worth much time investment to get this nicety, but the current multi-step process just to view the log is a little jarring. Perhaps as a middle road, the last 100 lines or so could be available uncompressed? Again, low priority but would-be-nice.
9) When I do view the build log, I get no answers. The end of the file comes abruptly in the middle of some haddock output, and the closest thing that looks like an error is about a missing link in a haddock tag `$kind_subtyping` in Type.lhs. I didn't touch this file, and I imagine the missing link has been there for some time, so I'm dubious that this is the real problem. Are these log files cut off?
Again, bug. Sorry about that. The shell script is already falling on its face.
10) More of a question than a phrustration: is there a way to link directly to Trac tickets and/or wiki pages from Phab comments? I like the Phab:D73 syntax from Trac to Phab, and thanks, Austin, for adding the field at the top of Trac tickets to Phab revisions.
There's unfortunately no syntax for this. HOWEVER, I have just this morning rolled out a change to phabricator.haskell.org that now allows you to set the Trac issue #s in a revision, and it will hyperlink it! For example:
https://phabricator.haskell.org/D88
Look at the 'Trac Issues' field, which hyperlinks to the right issue - yay!
You can even specify this field when using arcanist, if you add something like:
'Trac: #9303'
to the commit message when you run `arc diff`.
Cool! Thanks! Thanks again for your help! Richard