A contributing issue is that one instance appears to be making clone requests for approximately 30 repositories per minute to this shard. This is easy to rate limit, but probably not easy to rate limit in a generalized, not-a-cluster-hack way.

One remaining issue with backoff/cooldown is that mirrors aren't included: a regularly-updated repository with broken mirrors still tries mirroring. This is somewhat more involved to fix, though (see T6131).

Those changes seem stable. Unclear how much they're really helping, but load is looking at least somewhat better. I'm going to dig into things a bit more and see if I can get a better sense of whether we're on the path to recovery or not.

D16574 retains update cooldowns (so we don't immediately update everything after a restart) and sets up for the following change.

Repository retries (failed mirrors, failed fetches) have no real backoff

I could alternatively throttle down the highly active instances (or all instances on this shard) but that's not too great.

• Maybe a good time to launch new shards? Last tier size increase was 10 months ago (late November, 2015) when I fixed the allocation algorithm to be not a huge wasteful pile of garbage that required us to constantly throw hardware at it.
  • Maybe the allocation algorithm should consider active users, not just active instances? I think the 002 shard has the most active users by a hefty margin, just by luck of the draw. But this will tend to be moot at scale.
  • Maybe start moving instances between shards? This seems hard to do without downtime today, and doing all the legwork to reduce downtime through clustering is foreboding.

And you can technically:

Oh, right. That works, but I think isn't documented:

We could conceivably special-case this since setting an empty attribute to a value isn't meaningful, I suppose.

Some somewhat-good news is that Google Calendar just gives you an .ics blob of garbage to describe recurrence rules:

Things don't look promising.

I think we should be able to accommodate that fairly easily.

More generally, here's how I'm planning to model imports, which seems largely consistent with other systems:

Yeah, I fiddled with that but didn't immediately have any luck. It's possible that there's some complex condition like non-self organizer + non-self sender or something. If it only requires non-organizer, it should already work today (e.g., on this install).

Sort of. I'd like to have use cases (what are you trying to do?) first, and I'm not certain what the best representation of dates and times is for external consumption.

This probably already works, on the backend, but needs:

I think the first part of this should be fixed in HEAD now, thanks for the report!

The "multiple packages" issue may have been a symptom of the dominion/archive problem, here's a case I hit while testing that made it look like there was a second issue:

D16564 might fix this but I need to actually test it.

Also, what is the expected behavior if two Owners packages point to the same path?

Is it possible that this is slightly narrower: "package dominion rules incorrectly consider archived packages"? That seems to fit with the observations, but maybe I'm overlooking something.

See Contributing Feature Requests for help filing a feature request we can accept upstream.

Feel free to submit a diff for this, should just involve adding some stuff to HarbormasterBuild in getFieldSpecificationsForConduit() and getFieldValuesForConduit().

I'm having trouble making GMail provide a reasonable pathway forward for getting .ics events onto Google Calendar. Ostensibly this just works:

ICS primarily identifies users (organizers and attendees) by email address. Phabricator does not normally disclose email addresses, and I don't want to let someone scrape every email address out of Phabricator by inviting every user to an event and downloading the .ics.

Even if everything else defaults to public, I don't think that's an especially strong argument on its own for copying that default. There are a lot of other cases where we diverge from common practice because we think there's a stronger case for a different default or behavior.

Sorry, we aren't interested in maintaining any version of this change in the upstream at this time.

D16465 has details on how to move forward here if anyone wants to steal it before @michaeljs1990 gets back to it.

Hmm, I guess I don't have the same experience -- the defaults are what I expect and the UI doesn't seem difficult to me (rough in places, but the basic flows are what I expect/want).

This stuff is defined in PhabricatorUser->loadEditorLink(), which ain't great but probably not worth generalizing.

Of the visible rooms I'm a member of, 14 out of 15 are private (the other one is General Chat).

Neither T11277 or T6706 are exactly about that, but I think the ultimate fix to those is likely a general refinement of SSH key metadata (source IP range restrictions, logging, specific permissions).

for sshd and ignore the username

I'd expect to just hide that in CLI porcelain:

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/project/lipsum/PhabricatorProjectNameContextFreeGrammar.php

D16542 should fix this and reveal whatever the underlying error is.

Yes, if you want the change to apply retroactively. Something like bin/repository reparse --message --all rXYZ, but see bin/repository help reparse first to test that on a few commits and make sure it does what you want.

I don't think this is preview related -- I think PhabricatorEditEngineConfigurationTransaction just doesn't implement hasChangeDetails() and some related methods to generate this link.

There is no such setting, and I believe this use case is very unusual -- it's like putting the subject line of email in the first line of the body -- so I currently have no plans to add support for it (see also T8227).

Sorry, we don't offer setup and configuration help. See Support Resources for discussion of what we do offer.