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.

Sounds good, thanks.

On re-reading T3917 I agree it has approximately nothing to do with this, but see also T5338, where I think I go through a flow like this and it doesn't trigger an audit.

Per above, not sure how to reproduce this.

I don't believe this report, but here goes:

I'm having some difficulty figuring out exactly what this and related reports are describing.

I'm going to merge this into T3917, which I think is the broadest description of this issue.

I'm going to close this as "Wontfix". Although adding custom fields is something we may still do, I no longer expect to "rebuild" on top of that infrastructure.

D17221 adds an "Auditors" field to Herald.

making the old version of arc continue working as it did, if trivial, with new versions of the backend

goes away after upgrading both to latest

No. This task covers documenting this syntax.

After a quick look, ModularTransactions doesn't currently expose a shouldHideFormMail() hook and I may want to do something a little more tailored here, so fixing this isn't a one-liner.

This does not appear to be moving forward as a valid bug report which we can accept upstream.

For context, this is a side effect of the move to EditEngine in T11114.

Thanks, D17218 should fix this.