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

A-Z and 0-9 is all we need here? Gotta remember user @0

It'd look something like this:

From what I understood, if I edit the built-in form, It would apply globally, so I only wanted that field hidden, if it was a new form. which is what I was trying to create.

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

I am not able to edit the form such that users belonging to a certain group are not able to change the state ie: "close" a task.
Having read into other similar situations ( T11207 ) and reading that your solution is to use custom forms I began investigating custom forms.

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

Honestly I'm fine with 6600 uniques out of the box. I think beyond that people can update their image. Mostly I'd like it for individual conversations (tasks with newbies), so I don't expect collision in those cases.

Googling around I can find programmatically generated lists of 256 colors x 26 letters = 6600. We can also make background shapes. 4,5,6,7,8 sided. This would give us 33k uniques.

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.

Shapes x Colors x Letters seems most clear, but will have some collisions. I can mock something up. The letters would be generated images like in Projects? Or can this be all GD? I think that assumes fonts.

commit eec6cd865c854fd00c8de41b8ca8ed0da78760e8
Author: Chad Little <chad@phacility.com>
Date: Fri Feb 24 15:21:23 2017 -0800

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.

Cool, now I don't feel so bad since I know you only recently added the option 😄

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

That works, Im curious when this changed, as I didn't need to filter since the last few weeks.

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

The reason I think something isn't working correctly is in my dashboard, I list recent commits, and since I updated my install a few weeks ago my commit list looks like this a lot:

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

See T12298#213181.

Thanks @epriestley and @rfreebern - your scripts worked perfectly! Between them both (and tweaking that one "hasSubprojects" field in the database myself), I was able to move an entire project tree. Yay!

@epriestley all other commits that have the message "This commit has been deleted in the repository: it is no longer reachable from any branch, tag, or ref." have imported, so I don't think the reachable code is working correctly, as until within the last few weeks I wasn't seeing these "This commit has been deleted in the repository: it is no longer reachable from any branch, tag, or ref." commits showing up, but now I see them all the time.

For the record, you can work around the problem as such:

{
  "linters": {
    "filename": {
      "type": "filename",
      "exclude": ["(\\+)", "(\\@)"]
    }
}

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.

We would be prepared to step in for prioritization on this.

The re-launched hosts seem OK, I'm waiting for DNS to update and then redeploying them.

The hosts launched into an "Auto-Assign Public IPv4" subnet but didn't get IPv4 addresses. Restarting them didn't help, and there's no apparent way to assign public addresses after the fact. I'm going to throw them away and try again.

I'm going to put more hosts into production immediately before pursuing other issues.

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

• The tier as a whole is 88% full.

So here's a tentative plan for subtyping:

Custom Forms are the general tool we want to use here, but they currently have some limitations for this use case. As a starting point, here's what they can do today, some of the strengths, and some of the weaknesses.

@epriestley Yep - like what you're doing there :)

So I don't forget:

Maybe the "Install Arcanist" header on Quick Start could be like:

Oh, no, it's just to do with the ordering of the links vs the annotations: if you're totally new to phabricator, you're going to get tripped on the "quick start" link which says "install stuff" and in the middle links you back two pages...

I'm assuming he wants us to duplicate the installation information onto Win/Mac pages or only link to those pages after installing arcanist.

That is, this passage:

There's a short version and a long version. Each version links to the other version, saying "here's a different version of these instructions, if you'd prefer that one". How could we make this more clear?

Thanks! I guess nobody ever noticed that before!

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

@pouyana Here's a workaround for you. In your notification.servers Phabricator configuration, add path: "/ws/" to the client server. Then, modify your apache configuration like so:

I don't see how to configure/use that

Neither can I - I may have imagined it being possible to "lock" the edit form of a task to the one that was used to create them...

I think it's fine to disallow changing from one type to another - can that be enforced? And sure, I think the custom form approach would work but I don't see how to configure/use that - can you point me in the right direction? I presume this implies that the underlying fields are the union of those exposed by all of the forms which would be fine.

This is a followup to a private discussion elsewhere, I'll flesh it out a bit when I have a chance.

Can a task mutate between "feature" and "risk"? If not, can you use a different Custom Form for each type, which will hide the unused fields?

The commit cache should be a fairly large performance win.

Hibernating daemons currently show as "Waiting" in the Daemon console, but I'm not going to worry about that for now.

Ah, okay. This is the relevant part: