That's a useful script! Thanks for sharing, that will likely do everything we will need and I can run that.

At least locally, I can't manage to get node to not leak:

oh, I might take you up about PhabricatorRepositoryManagementEditWorkflow then.

My hack for it is P1963: It's a script, not a conduit, but it's reasonably usable other then that.

Oh, and as an unusual special case I'll upstream anything you want to do to PhabricatorRepositoryManagementEditWorkflow and we'll keep it not-broken until T10337, although I promise to break it after that. This workflow has special favor and exists outside the normal rules of usptreaming hacks.

You can also just update the JSON value in the details column in phabricator_repository.repository directly. This won't generate a proper transaction in the edit record, but will work correctly (that column is authoritative, and not cached by anything).

This would be strictly obsoleted by T10337 and not help us build toward it, so we'd prefer not to pursue it in the upstream.

To actually do forking, the pathway is roughly:

We can do "private branches", but you can already do something like this:

I've an old generation one. The first three generations weren't U2F.

It's also worth noting that newer yubi keys have a u2f support that doesn't require third party server integration. Which may be more palatable?

This is done. Minor followup: T10698.

We're seeing a lot of connections stick in "R" ("Reading Request") for a long time, but the client is the load balancer and the request hasn't been read yet so it's not clear exactly what's going on with these. I think they may be crawlers, since pretty much every search engine loves indexing everything on this install hundreds of times an hour.

I'm fiddling with LB health checks, so it's my fault if the server vanishes.

Per T9293, client-uri and server-uri should be split into client-port, client-host, admin-port and admin-host.

I'll make a note on T10697 to split these options into explicit host and port options. The use of uri options which combined hosts and ports was intended to make specifying hosts and ports more convenient, but I think it's clear that it was a grievous error.

In T9293#167654, @epriestley wrote:

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

MaxRequestWorkers 24 appears to be creating some issues. This host only serves about 5 requests/second, but I can hit delays with concurrency of 10 (e.g., ab -n100 -c10):

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

In T9293#167652, @epriestley wrote:

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

In T9293#167637, @epriestley wrote:

We will not trust X-Forwarded-Proto, X-Forwarded-For, etc., by default because they are not trustworthy in the general case (they are completely client-controlled if you aren't behind a load-balancer).

See T10326.

We had a user that was confused and frustrated because on the task view page projects are under a "Projects" field but on the edit page are under a "Tags" field.

I plan to make these options explicit instead. This tangled maze of inferring things from various values is a bad state of affairs. See T10697.

To resolve this, configure your server so that $_SERVER['HTTPS'] is set correctly. This impacts other checks, so it is much better to fix it than try to guess our way around it by examining aphlict.client-uri.

This doesn't describe a reproducible problem. See Providing Reproduction Steps.

I plan to separate this configuration and make these options all explicit, see T10697.

The Aphlict logs don't reveal anything useful, and could use some attention: they're heavily geared toward setup/debugging, not maintenance/operations.

I've deployed a MaxRequestWorkers 24 change to this server and wasn't able to get it to burst over 24 workers with ab, so that seems to be working. I'll keep an eye on it for the rest of the week, and the 48 limit will go out to the cluster later this week if no problems turn up.

To prevent this, I plan to:

Here's the smoking gun from /var/log/syslog:

Since this isn't clear from the previous posts: In my case, GPG signed mails ONLY create an attachment. The actual contents of the mail get discarded.

Hi, I have upgraded both tortoiesesvn(1.9) and phabricator (server+client) and I still get this error.
I have tried to understand what happens to that and I think i have found the problem.
the problem is that arcanist run this command:

As a totally crazy idea, based on the virtualizing refs thing: Allow some sort of "private branch" without forking?
That way user can "push for backup", but don't need to add a remote, or keep their fork up-to-date with the master.

See also T5701 for bonus complexity.

I was expecting this "parameter" to be a checkbox that could be turned on / off on the diff itself, and editable through the creation and edit forms, not through the action system, if that makes sense?

This option should already be available from the UI. Here's a screenshot?

sorry, forgot to say it's this document https://secure.phabricator.com/book/phabricator/article/arcanist_lint/

@jshirley, here's the issue we spoke about earlier.

Anyway, assuming this is a "freedom and flexibility" issue over a "perform only reasonable operations" issue, we're definitely open to implementing forking, but this is probably in the realm of prioritization with a nontrivial set of infrastructure and product blockers.

I think I'm still missing something here -- are users doing this?

I always see it like this (Chrome/Windows); I've dug a little in the algorithm, and I think it's using location relative to the page for the calculation, which is why the first (top-most) tooltip acts differently than all the rest.

I think that "forking" is the right answer here.

It's not rewriting an existing published branch, we don't permit that, it's just publishing a branch that you've accumulated a bunch of things on as you've been iterating for some period of time. You're not done with it by and stretch of the imagination, and it's been sitting on your machine too long for you to not push it somewhere.

In this case, does the branch contain reviewed changes, or just draft changes by multiple different authors?

I think these steps should reproduce the issue:

How do I reproduce this error?

Root problem: To ensure quality software, I want to make sure that all reviewers accept a change.

Most likely your request is covered by other tasks.

Do you have blocking reviewers on these diffs?

I have read it, but after re-reading let me give this another go. My apologies, I know you guys are busy and I'm sitting here not knowing how to properly formulate a problem description.

I think that's just a rewording of the original description, and doesn't provide any new insight or context. It still focuses on a very narrow symptom problem (not being able to see individual reviewer status from the revision list), not the root problem.

@epriestley Oh! You are right. Let me take a stab at my problem then. Some of this is caused by the lack of rules for complex acceptance conditions like in T731.