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.

What'd be the fee for that 1 second command and a 5 second copy/paste?

I'll make sure to update this task with full reproduction steps on Monday.

I appreciate the details and pointers - we may look at a custom reject transaction and/or required action bucket. I just went digging here for related discussion to see if others may have run across similar scenarios.

If you miss a comment and then forget about a revision you authored for a while, it probably wasn't that critical?

I can investigate further what issues people are having with the current solutions - I'm not sure being critical is the concern but more-so there being a delay for the change to land/verify without it being clear who should be the next step (presumably from the dashboard/bucket?).

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?

Could you at least give me the time output for the broken/test repository update on your test system, so that I have a baseline for comparison later? Thanks!

I want to resist adding additional actions here if they would be rarely used and reasonable workarounds already exist. After EditEngine (T11114), third-party extensions will also be able to provide supplemental actions.

In T12136#208145, @chad wrote:

I can vanish them now.

I can vanish them now.

Yeah I meant to clean that up too

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

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