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

@epriestley my assumption here is:

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.

We are certainly not going to engage into paid consulting without knowing how long it might take to solve the problem, given your hourly rate :)
I would have appreciated at least a tiny hint on how to solve this ourselves instead, so I guess I'm going to dive into the code and implement a workaround somewhere. For example, tinkering with the $smart_wait calculation might be a start.

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.

@Ondrej I was mostly trying to understand if you were seeing a regression, a mis-understanding of how Audit currently works, or missing some setting we should be trying against a default install. There were a number of variables still open based on your explanation to me at least, sounds like @epriestley has plans forward here though already.

• Chad, lets say I would rise a concern on your commit and I would never come back to Phabricator's website. You cannot mark your revision as closed. You need to remove me as an auditor and accept your commit (what is little bit complicated). What's more, there's no functionality to help me to follow this concern. When you commit a fix, how can you let me know about this fix?
• Epriestley, T2393 would fix the second issue, that would be great to have it today:-)!

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

if a concern is raised; no one except this auditor can close the audit.

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 was afraid this would happen. However, short of giving you access to our server, there is no way I can exactly describe our setup: there are fare too many variables. Perhaps we could narrow it down a bit? What could be a factor here? The obvious non-standard features of our setup are :

• linux-vserver
• 32bit userland
• LVM on soft raid
• daemon user = web user

That said, I can't understand why the same user can run hg log with negligible CPU impact, and run the same hg log through phabricator with significant performance impact. Clearly phabricator does something in addition to calling mercurial that is causing the problem, and I don't know what it could be. That's where your input would help :-)

I did for now, will see what FontAwesome 5 brings, but the was never something I really liked for Phame anyways.

Beyond that I don't know how you're using Calendar or what types of events you have.

I'd update Phabricator first, then see if it clears.

Actually this error started quite long ago. In my memory it started after some big changes on Calendar app. I have updated several versions before I fired this bug report. I will try to update to the latest version later. Regarding the reproduction steps, this is a background daemon log, not triggered by direct human action. I have no idea how to provide the reproduction steps. Any hint?

We will also need reproduction steps to accept this as a valid bug report. See Contributing Bug Reports.

You're at least 6 weeks out of date. Can you update Phabricator and verify the bug at HEAD before filing, please?

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:

The repository at https://bitbucket.org/LeCoyote/brokentest is enough to see unusual CPU usage. Of course, it is nowhere near as bad as the other one, but the CPU is still coasting a noticeable 2 or 3% above average, which seems disproportionate for such a small repo. Also, when calling the update manually:

$ time ./bin/repository update 3
Updated repository "cieltest".

Noted. I'll try and reproduce the problem with a different repository.

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

Unless you can make this task private to a group of people who would be prepared to sign a NDA in French, that's not going to happen.

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

In https://github.com/aik099/phabricator/commits/jenkins-integration branch I've:

(I've grown to like the icon-less menus though)

We'd probably be fine picking 16 per form... Not sure people customize forms outside of Maniphest though.

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.

And before you file it, no, cat facts are not supported.

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

Are we not supposed to have permission to "Edit Favorites", or is the Favorites application still being worked on?

This is complete for now, there may be more minor updates, but all top level goals have shipped.

This is in a reasonable state, will follow up with a new task on errata.

Thanks for the detailed explanation!

Yes, I've updated to 269dd81f91784d40abdd9af2d95061cdb3d2c394 and the issue is resolved.

As I've understood the EditEngine supersedes CustomFields by the flexibility. Are there any examples (in code or in documentation) on how new fields can be added to commits or other entities?