Other people having problems with proc_open https://github.com/mikehaertl/phpwkhtmltopdf/issues/56

These things seem very general. I would expect them to be, e.g., on a wiki page like "Guidelines for Effective Code Review at <My Organization>". What advantage are you expecting to gain by building these into Differential as a checklist?

Here are a few off the top of my head:

Can you give us some examples of the kinds of things you're checking for? Specifically, things where rote human review is the best solution to implementing a check?

This is the only difficult blocker for T7673, a bad behavior which is annoying and sort of user-hostile, so I'd like to at least plan our way through it.

I am going to merge this into T7303, which is a slightly narrower task describing OAuth access to Conduit.

The workflow to set a password on an account which does not have one is:

I think there's nothing actionable remaining here. Both our and Facebook's modern instructions encourage users to whitelist redirect URIs.

This report doesn't have enough information for us to move forward or resolve it. See Providing Reproduction Steps for help with writing complete, self-contained reproduction steps that we can follow to reproduce an issue.

@epriestley and @mattflaschen I have created a windows installer here https://github.com/paladox/Arcanist-installer-for-windows

What's left is adding Awarded by ... to recipient list on badge view:

On my mobile device (an iPhone 4S), I think it's slightly faster to tap-wait-tap-copy the URL bar than press-hold-copy a link.

It's an intentional change, so it's easier to copy and paste the task ID. I'm not sure I understand what functionality is different now that you desire. A place to get the full URL but not from the browser URL bar?

In the mobile, it's usually easier to touch the button instead of opening a sidebar to touch refresh button. If you're saying I can use keyboards on mobile, fine.

This report doesn't describe a bug.

This should now be resolved in production.

We have an additional safety check which is supposed to prevent this kind of issue: we refuse to process messages with the same "Message-ID" more than once.

@paladox, we appreciate your enthusiasm but I think you have a very mistaken set of expectations about the kinds of services we provide. See some discussion in Support Resources.

See the link in the description that shows what zuul can do.

the current features I think that need supporting is

@epriestley well I'm not sure if Harbormaster has a ui but zuul does and makes it so easy.

We don't plan to support this in the upstream. We have a system in a similar role already (Harbormaster) and would prefer to expand it to do more if there is missing functionality.

There are free installers that create the installation we want like

Is this task meant for the upstream or your local Phabricator install?

I think this is happening:

Thanks for the report, D15573 should fix this. Sorry about that!

I can reproduce:

avive@vm:~/devtools/libphutil master$ arc backout @
Starting backout.
Backing out commit @ Implement a stream iterator and hashing iterator
Double-check the commit and push when ready.
avive@vm:~/devtools/libphutil master$ git log -1
commit 3546d1d307b6a3971162ab5e359df909ce84da64 (HEAD -> master)
Author: Aviv Eyal <avivey@gmail.com>
Date:   Fri Apr 1 21:05:33 2016 -0700

See Support Resources.

@epriestley Maybe a bug request wasn't the right thing to submit. How can I go about getting support or advice on this issue without figuring out how to reproduce it. At the end of the day it is likely not a bug but rather me breaking something through deleting a project.

No, badges themselves don't have an awarder.

We currently track awarderPHID in the badges_award table. Do we still need an awarderPHID in badges_badge table?

I know you guys want reproduction steps

jx-tooltip is a free spirit :3

Thanks Everyone!

keep in mind that that was successfully compiled by removing lots of code https://github.com/RustJason/xhprof/commit/6c473e39fa93fb7f0acc3fae73f626e5c66dff1a and i'm not completely sure of the implications of the changes.

my pleasure! thanks for the swift reaction and resolution, and very clear messaging on when we can expect the fix to be available on the phacility instance.

This should now be resolved in HEAD of master. I've deployed the change here, and verified I can interact with the comment in D15565.

I think a workaround is to swap the particular changeset into unified mode (View Options → View Unified) and then interact with the comment, but the fix seems trivial and straightforward.

Thanks, I can reproduce this as well (e.g. D15565).