For repositories with a short name like "codebase", I imagine users would prefer /diffusion/codebase/ over /diffusion/123/ as the canonical URI.

We should maybe hide the tags for archived projects on worboard cards, I notice WMF has a lot of this:

See also:

Doing this blindly would let clients spoof remote addresses on installs that are not behind load balancers. The current recommendation is to replace REMOTE_ADDR in preamble.php if you trust the connecting device. Here's what we do in the Phacility cluster (although we're in SiteConfig here, not preamble):

My planned pathway forward here is:

I will report you to the workboard police on T10215 if you keep it up! You better check yourself before you wreck the project roadmap for weeks by derailing it into abuse cleanup tools.

I have replaced your dumb 1x1 transparent GIF with a fearsome tyrannosaur.

I really like the look of the inverse tag, although I haven't personally felt too much confusion about milestones vs nonmilestones on project pages.

In T10349#159831, @cmmata wrote:

So is there any official/recommended way to work with global milestones?

D15289 should give you better tools for gaining an advantage over your adversaries in hostile departments.

I can update the script with a "no int check + warn on weird values" version if anyone wants that but isn't too comfortable with PHP.

Yeah, the int is mostly out of an abundance of caution. There's currently no float custom field type, and if you previously used string you probably need to massage values anyway since some of the fields may have strings in them (I think WMF had a few strings like huge, epic, etc). You can comment out the int check safely, but may need to add some code to examine $value for usual values if you do (or accept that they'll probably be cast to 0).

Just shelving this for the moment until more information is unearthed.

Aha! See also T4947.

Ugh, the lint stuff also uses PhabricatorRepositoryBranch, although I suppose they can be moved off separately.

Per Q314, we also need to fix the coverage table. I'm not grossly disgusted with the +J{...} hack in D15286 but I think we need to add some kind of table to replace branchID like this:

No, that was some stray debugging code. I updated the script.

You may be able to just comment out that check, but I'm not sure how the extension stores its data. You'd have to check with the authors to be sure.

Yeah -- you're actually going to extend HeraldField. A good place to start might be DiffusionPreCommitRefPusherProjectsHeraldField. Basically:

If you want to block a push when a user has too many open reviews, you need to write a new condition, not a new action. Your rule will look like this:

This is a feature, not a bug.

Please describe the root problem when requesting a feature. See Contributing Feature Requests. If you aren't sure what we mean, see Describing Root Problems for some more details.

I can't reproduce this. Here's what I did:

I think this should be fixed in HEAD, let me know if I missed anything. Thanks for the report (and the patches; I did approximately the same thing in D15282).

We have this config (which I think setup issues recommend) but that should be the only difference between this and other installs, I think:

Unless, perhaps, "long" was really quite long indeed.

No luck on that one either. :)

Hmmm... pneumonoultramicroscopicsilicovolcanoconiosissupercalifragilisticexpialidocious

I added you to Community.

Can't reproduce:

untalcumish

New watch stuff should be live now.

Yeah, that's buggy. I think I that only got partially implemented. My plan is:

Can you describe a specific case where a generator emits some equivalent substring and can not be modified to emit a different substring? See Describing Root Problems.