Sounds good. I added you to Community so you should have sweeping administrative powers now.

The more modern, slightly more concise process is:

I'm thinking for my case, there's not really a lot of value in keeping the tags around after the diff has been closed. Maybe that's something to consider?

I probably wouldn't show them in the UI for now, although I don't think adding an "Other Refs" table underneath tags/branches on the main screen with, say, 5 entries and a "See All" button would necessarily be terrible if anyone can come up with a reason that users might ever care about it.

User profile images should be getting cached. For example, your profile image here:

Sounds good. Let us know if you run into anything else.

You can register an event listener for the TYPE_AUTH_WILLREGISTERUSER event. We are generally moving away from this system, but it works today and I don't have any near-term plans to replace it in this case. This is the documentation:

I haven't been successful locally in getting a GC'd node to reach an appreciable level of memory consumption, and the production servers are currently at ~1.5GB.

I think the ~1.5GB node instance size is also expected.

In T10350#167753, @rbalik wrote:

This is useful, but are there any plans to add this functionality to the GUI? Would be nice to have for when we're doing some housekeeping

See T10350.

Sorry, Vehicle VIN Identification Numbers.

(It mostly has reference stuff like our vehicle VIN numbers, our PG&E account number and credentials, etc. If you hack it, you can pay our electric bill!)

There is, but we don't use it very much.

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

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:

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.

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

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

See T10326.

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:

See also T5701 for bonus complexity.

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

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

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:

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

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.

T1279 is talking about the reviewer list on the detail page (/Dxxx), not the list page (/differential/). This was implemented years ago, so I suspect it isn't a duplicate, unless you're years out of date.

Thanks for the request!

D15545 should fix the infrastructure part of this, and make this error more clear by returning an explicit diagnostic error rather than a mostly-working string and a log.

Oh, I believe the actual issue is that the translations are variant on the wrong parameter. I think this is the correct fix (adding an extra array()):

D15544 (changing %s to %d) shouldn't be the fix for this -- %s is correct, because we want to render "1,234,567" if the number is large:

D15535 should completely fix this in all cases

u wot m8? havin' a go? havin' a little laff?

Specifically, the issue here is that we fetch and import branch heads, but not other refs, including tags. We also aren't totally consistent about which refs we import across hosted/imported repositories.

At a minimum, Herald, Harbormaster, Nuance, Phortune and Differential can author stories today, although not all of these stories currently render with photos. We should probably assume any application may author stories.

See also vaguely-related T8952.