I have a few questions about this, and some ideas for how we could solve it:

Earlier, I predicted:

I mean doesn't Arcanist track this?

D17425 doesn't change my thinking here.

Go ahead and file something separate for that, I don't think it interacts here.

Go for it.

The description of the "git:branch-unique(...)" rule in the "Arcanist Commit Ranges" document may be helpful in understanding why this is hard, or at least hard enough for me that I was unsuccessful in producing a "do the right thing" or "do what users expect" behavior when I tried and we ended up with "base" instead:

Maybe a better path forward is this:

Also, how do you expect to arc to distinguish between these two use cases, each of which some users prefer?

The general "why of the why" is that if "git push = publish" is a valid assumption, and users "git push" a series of changes, they expect corresponding revisions to close -- even if they've rebased, amended, etc., those changes. We try very hard to find revisions to close when we discover new commits to meet that expectation.

Arcanist understands this is a new topic branch which no associated revision yet,

By default, Phabricator assumes that git push means "publish", and that it is ONLY used to publish the final version of complete, reviewed changes. If you haven't already seen it, this post describes this in more detail:

I think you can use imagecolorallocatealpha($img, $r, $g, $b, $a) to do it for you. Note that alpha is 0-255, not 0-1.

Here's what I just did on a new Phacility instance:

Great, thanks! I haven't come up with any other major concerns myself after considering this for a couple of days, and expect to move forward shortly.

Or maybe a simpler question is: when you run arc diff without arguments, what is the complete algorithm you want arc to follow to figure out which commit range you intend to send for review?

Is this behavior clear after finding "Explain Why"? Which parts remain unclear?

Based on the output, what do you believe arc is doing? What do you think it should do instead? Which part of the behavior do you believe to be a bug?

I've deployed everything so I believe this is now resolved. I'll keep an eye on it going forward.

The pool appears to be scaling up and down properly now. I'm going to deploy the fix to the secure and repo tiers since it may affect all instances.

I'm picking D17433 now and sending it to admin.

I'm picking those to stable and sending them to production now.

• The SQL templating should define some new variable like {$FULLTEXT_ENGINE} which evaluates to the appropriate engine at runtime.
• The Quickstart SQL generator should replace the raw engine string output by the build + dump process with this variable in the affected tables. This piece will be a little hacky, but I think that's unavoidable.
• The Quickstart SQL should be regenerated.

I believe the semantics are consistent, but let me know if I'm misunderstanding or you're seeing something different:

crc32 would be fine in this use case too since the requirements are so lax. My version isn't particularly robust either, but should get the job done.

And the pencil icon on workboards, the pencil icon on the list view, and the "Edit Task" action from task detail pages would default to "Edit Plant Task", yeah. The workboard change would only pertain to creating new tasks directly on a workboard.

Right now, this menu always says "Create Task..."

Calling this resolved since the page is now tolerably bad (~5s) which more or less pulls this out of the realm of critical scaling issues.

• If the date is a day or more in the future, show days + hours + minutes.
  • If the date is an hour or more in the future, show hours + minutes + seconds.
  • Otherwise, show minutes + seconds with THRILLING TENTHS OF A SECOND.

This does not describe a bug in Phabricator. I've reviewed the documentation and believe it is already sufficiently clear in describing how to accomplish what you're trying to accomplish. Particularly, I don't see anything in the documentation which is misleading, or suggests that the workflow you're using is the correct way to accomplish your goal -- it isn't, and the documentation describes the correct workflow. See Support Resources for other support resources.

(They could also go into the existing "Waiting on Review" bucket, but I dislike mixing authored and non-authored revisions in that bucket.)

The actual reproduction instructions are slightly more involved:

@jmeador, I believe this is now resolved at HEAD. Let us know if you're still seeing issues after upgrading?

After D17422, I used bin/lipsum to generate about 20,000 badges. (They all have USERS permission so the permission checks are about as fast as possible.)

After implementing PHP7 support for XHProf and updating Lipsum, I used bin/lipsum to generate 4,000 packages owning 150,000 paths. I think I have an approximately-reasonable reproduction case locally now, which generates this profile (6.5s for a change affecting about 100 files):

I did the last deploy (T12316) with Phage again and things went much more smoothly after the various bugfixes and improvements.

See Planning for information on timelines and priorities.

I have a build of this that technically works now (produces profiles, passes tests, does not segfault when gently poked). It's still extremely really rough so I don't know when I'll clean it up enough to push upstream.

@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.

Here's the downstream task: https://phabricator.kde.org/T5406

Note that these steps depend on who is viewing the page (or, specifically, who "Responsible Users" are). More concise steps are likely:

It looks like we currently allow usernames to begin with _, ., and - (PhabricatorUser->validateUsername()), but maybe just do a ? for anything-except-numbers-and-letters?

Have you tried using Lock/Hide Fields to hide the "Status" field?

What's an example of a specific change you're trying to make which you aren't able to figure out how to make?

We can draw letters in GD, but I suspect they won't look very good compared to letters from Photoshop (bad antialiasing, limited font choices, weird alignment/kerning issues), so I'd guess it's not worth bothering and we might as well just jump straight to using generated images like Projects.

You are running an out-of-date version of Phabricator, from February 17th.

Please provide version information for your install. See Providing Version Information.

I think this (and lint/coverage) should move to Conduit, yeah.

(That said, my expectation is that behaviors around unreachable commits have not changed -- D17279 added the "Unreachable" option to solve this problem.)

Likely somewhere in T9430 / T10978, which rewrote a big chunk of the audit code.

If you don't want to see unreachable commits, use a query which hides them:

It is expected that some deleted commits will import and others will not.

See T12298#213181.

Total cost is about 1.6s. Of this:

This is still a little bit of a pain but far more reasonable now, here's an actual profile:

I cycled the rest of the tier and things look better now.

After manually deploying that to repo001, I'm now seeing a consistent Taskmaster/PullLocal count. I'm redeploying the rest of the repo hosts.

I think the issue is that the --reserve flag for reserving system memory now applies to even the first daemon in a pool, because all daemons are now part of pools. Previously, it only applied only to the 2nd..Nth daemon.

Some taskmasters failed to start on repo001 and perhaps elsewhere.

I suspended and destroyed the largest instance on the shard, a free instance with one user and no logins for >30 days (the user appears to have imported a huge repository and then never logged back in). We still have backups, but this instance was way over reasonable resource use anyway. The volume is now 78% full.

I pruned some very old backups (backup pruning is currently very conservative in several cases). The volume is now 72% full. This could easily be reduced much further by allowing bin/host prune to remove backups older than 90 days for suspended/terminated instances that have been out of service for 90 days, but backup utilization is generally relatively stable so I'm not concerned about this.

I synchronized services for this shard and destroyed old instances. The volume is now 68% full.

I synchronized services for this shard and destroyed old instances. The volume is now 44% full.

This was a bunch of repository file data in /tmp. Each file was unique, so this doesn't look like any sort of buggy loop or anything. There's some actual bug here but since there's a long list of other issues here I just "fixed" this by clearing /tmp.

Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

Shards 017 through 020 are now in production.