There's now a grayed out page

your phutil is 3 weeks older than the rest

Should I open a new bug?

Phrequent is a prototype. We do not accept feature requests for prototypes, see User Guide: Prototype Applications.

This is exceptionally rare, strictly user error (i.e., avoidable by entering your email address correctly), and administrators can force-verify email addresses with bin/accountadmin which offers one way out of this state.

This is what I see on my Macbook in Safari:

Emoji look terrible on nearly every platform / browser

I think it's useful to keep track of bugs which impact customers

I tagged this with Phacility because a Phacility customer was the original reporter. I think it's useful to keep track of bugs which impact customers, but maybe I should make a different tag?

I can't reproduce this. It's possible that you actually experienced T11165 and misremembered exactly what you'd done, or performed one edit in a tab with the other tab open.

This is by design, and explained in the documentation.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?

I deployed this to the Phacility production cluster.

I'm going to merge this into T12142 since that one has an earlier timestamp even though this one is more pure of heart.

I think the pros and cons are something like:

I think we should just use actual emoji for this, not sprite sheets?

I deployed that change here (secure.phabricator.com). I'll cherry-pick it and deploy it on admin in a little bit, if nothing catches on explosion fire.

Haha, no worries. Uninstalling Home is pretty unusual.

After purging dead instances, db003 and db004 are each <25% utilized on their data volumes.

Purging db001 brought primary volume down to 79.2%, which is technically below the 80% caution threshold. It doesn't need to be fixed immediately, but the pathway forward isn't terribly clear. Some options are:

Instance service windows on db003 and db004 have synchronized and the shards are now purging.

The temporary directory storage pressure on repo016 has an unclear root cause (it's related to importing an SVN repository, but I haven't been able to pinpoint where the issue started). The issue no longer appears to be occurring so I'm going to stop digging until it happens again.

The storage pressure on db001 is primarily because an instance imported a large SVN repository with approximately 60M paths. The instance is a free instance with one user.

The db001, db003 and db004 shards have also hit 80% full on their primary volumes. I'm purging dead instances from db001 now. db003 and db004 have never been purged and need to have instance out-of-service dates synchronized first. This is currently underway for db004.

I'm going to move forward with the deploy since this shouldn't impact actual instances, the stuff in this menu isn't super-critical, and workarounds (albeit inconvenient ones) exist to access the items.

And if I gave you a precise estimate you could be sneaky and just divide it by $1,500/hr to get the answer without paying for it!

Obviously, we can't just hand out estimates for free. Converting units and multiplying numbers together takes away valuable time and resources we could be using to develop Phabricator.

I'd be happy to, see Consulting to move forward.

How do I reproduce unexpected results at the application level (for example, what's something I can search for that doesn't match but should match)?

Yes and no. So: maybe?

While I've got you, how do you feel about a diff to:

(If there's pushback, maybe like a "one-time hacky copy your old global app settings into the menu script that we don't support" sort of thing? But I'd guess users won't feel like this is too painful since the new menu is a lot more flexible/powerful.)

I think it would potentially be reasonable to not migrate, especially if you do another blog post like the Favorites one to ease migration pain. Global stuff is relatively recent and pretty easy to put back in place, and I think a gentle nudge to configure the menu to work well for your install isn't a bad thing.

Maybe less complainey now that Audit and Differential have fairly sane default "stuff you should do" bucketed queries which can go on a dashboard? But who knows. I tend to think we should make an effort to toss these and see how much pushback we get. In particular, they're very expensive to build relative to their utility (and no one has complained yet that I nuked the Audit count, although it has only been gone for a little while).

Sounds good. I'm going to close this since it doesn't seem to be moving toward becoming a bug report which we can accept upstream.

There's a TODO about this in the code:

I'm going to merge this into T12134, which begins defining a more concrete plan roughly following some of the outline above. The major change from an upstream perspective since this task was filed is that we have a more specific set of harder technical requirements around support for Phacility SAAS instances (particularly after the launch of free instances), so it makes more sense to let those requirements drive product design and then accommodate general free support under that umbrella. Broadly, I expect to move support (bug reports, feature requests) into Nuance and continue reducing user access to the upstream.

(This change was half-accidental, and then I just figured I'd roll it into T2393 when I realized I'd made it.)

This did actually change in connection with T10978, but only if audit.can-author-close-audit is configured. I plan to resolve T2393 (maybe today?) and hopefully get rid of "Close" and this option entirely. I'm just going to merge this there.

I'd be happy to work with you one-on-one to help troubleshoot issues in your environment, but we can't offer that kind of support for free. This process almost always takes up a large amount of our time and very rarely uncovers any real bugs in Phabricator or helps anyone except the single user experiencing a configuration problem. See Support Resources for more discussion of the kinds of free and paid support we offer. If you'd like to move forward with one-on-one configuration and environment support, see Consulting.

I am unable to reproduce the issue you described by following the steps provided. To move forward:

Here's what I did to try to reproduce this:

(A synthetic repository which you create by running hg commit in a loop, or instructions which allow us to build such a synthetic repository, are also fine.)

An existing, open source project is perfectly fine, provided you first verify that it reproduces the problem.

We need specific reproduction steps to move forward, and "a repository with about 2800 commits" isn't sufficiently specific.

This is easy but I think you want to get rid of all the IconSet stuff and just let everything have any icon?

This report is probably correct and the remedy is likely also correct, but getting lint into Diffusion is completely in shambles so I'm actually not immediately sure how to reproduce it, at least in a reasonable / moderately-convenient way.

Not intentional -- @chad, I can figure out what's going on there since it might reasonably be me and I have a local repro.

I think the big trick on this is going to be making inline comments work somewhat-correctly in the extreme case of octopus merges.

Does upgrading past b21cd24341c6552a3fbd21305ca682a161129a6b resolve it?

As an adversarial actor, I can use the proposed rule to avoid audit of dangerous changes like this:

My merge of T6557 here was questionable, but I think this is a case where the audits are basically correct and the remedy is better cleanup tools.