D17452 marks this as resolved and makes these changes:

A basic version of this is now available in HEAD of master. Here's a walkthrough of what we've implemented and a discussion of some areas where we'd like feedback.

Closing this since there doesn't seem to be any thing left that's actionable for us.

That's the default behavior, and you can achieve it by deleting "Name":

You can set history.immutable to true in your repository to prevent arc from performing mutation operations (amends, squash-merges).

(And, if our behavior is "confusing fatal", that could prevent new installs from getting far enough to even see the setup warning saying "install gd".)

I think all the other requirements are usually builtin (we "require" them only because it's possible to remove them, and some distros occasionally do for kind-of-maybe-questionable reasons) but I think it's basically like requiring your car to have tires.

This runs into T5873, which is a large task. The very short version is:

I think the NUX case is fairly tricky. I need to look at the code, but I'm thinking something like:

Cool, sounds good.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

Why are you sharing an instance between two separate groups with separate identity providers?

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.

Oh wait, this is the unit tests failing. Nevermind

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.