T7661 is also similar.

I just realized after testing a few versions that the "Auditors: <username>" in the commit message needs to have 1 empty line before it to be triggered. Probably some parsing issue.

Actually, that report is already fixed.

Actually, that report is already fixed. For completeness, the behavior adapters should have is:

See also T7961, which is another modular behavior adapters should have.

• You can now technically write this as an extension by extending HeraldAction, although mail is quite complicated and this extension may be challenging to write.
• You could use an extension like the one in P1895 to add a comment instead, although I think this will be caught by notification preferences.
• You can use the action above (reject commit unless they bypass).
• You could use "Add Projects" and then just manually email the offenders who got hit at the end of the week to warn them.

Offhand, I'm inclined to still publish "Herald closed the task." in the "subscribe + close" hypothetical, which I think is the current behavior.

This behavior is "correct" in some sense (Herald really did perform the "strongest" action in the transaction group) but the sorting on tiebreakers is likely wrong (see D14680 for a similar case) and we should sort actions by real users over actions by Herald at the same strength.

The build for Dyyyy should not fail. They do not fail in the upstream.

Related, the test console has a big if ($x instanceof ...) mess that should be pushed down into Adapters. A reasonable flow might be:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

Broadly, if comments have the new "stacked action" UI (an "Add Action..." dropdown, allowing you to take multiple actions at once), the expectation is that they support the new drafts too. This includes Maniphest at HEAD.

I've just tried archiving the packages, but when a new commit comes in, the package/owner is still a reviewer for that commit :-(

I can't reproduce this issue by following the steps in the report:

I can't edit my own task... it 404's

In T9924#147596, @epriestley wrote:

So - a technical team lead would encounter this.

I'd describe myself as this, at least approximately, but never have files lying around that I don't want to commit. Why wouldn't you want to commit a file?

1. In this case I was yes.
2. We have post-push builds hooked up, but not pre-push for this project in particular. (rely on arc unit)
3. We have tests only run on affected files, but we have certain files that can trigger a lot of tests.
4. I'm all for this (reducing some big categories from warning to advice by default). Going to try to make it happen. Would be cool to have a list of "top errors in this project" somewhere to make this process easier.

These unit tests take a while. I'll run it on the final revision

Ah yes, this should be a feature request and not a bug report. Sorry!

I saw it as two subproblems

1. Difficulty remembering whether lint or unit failed
2. Difficulty remembering excuse for lint failures in particular.

(See general churn in T9905, T9908, T9132.)

Oh -- are you creating these from the workboard? Never mind, in that case.

I don't understand the difference between this and T9936. Aren't they aiming to solve the same problem (difficulty remembering what failed during arc diff when running arc land)?

Actually, what is the difference between ~/.arcconfig and ~/.arcrc?

The expectation is that you'll remember what the issue was, since arc diff printed the specific problems earlier and you already explicitly confirmed that you wanted to continue despite the issues.

As a workaround, you might be able to put aliases in /etc/arcconfig (e.g., symlink that to something which is version controlled) and use ~/.arcconfig for credentials only.

I have two aliases that I wish I didn't have to have re-typed today between two of my machines.
I particularly like to be able to set up a new machine without thinking of what I might have missed on the old one.

yeah maybe lazy is bestest

After "thinking carefully" about this I am going to do the lazy / less bold approach and we can sort it out later so you can have this back. :3

sometimes have uncommitted files lying around you don't want to commit just yet

Yeah, maybe it's not terrible, will have to see what other feedback we get here is. One idea might be to allow columns to define what forms are there, with all forms by default on the Backlog.

("Not really." in the sense of "I don't have anything in mind" -- I agree that it might feel weird.)

Not really. I was going to do this:

In some regards, having "bug report", et al. on a column might feel weird. Or do you have something in mind?

I'm going to try to bludgeon this in for EditEngine, we can refine it in Projects v3 if I ham it up.

Just clarifying, is this link is considered PhameHome?
https://secure.phabricator.com/phame/

I think D14016 actually fixed this?

I don't plan to implement this. We haven't seen other interest in it and your use case seems fairly unusual.

See Contributing Feature Requests for help writing a feature request.

Do you have a meaningful amount of configuration in your ~/.arcrc?

https://secure.phabricator.com/T9935 Thank you!