Ah, that makes sense. Everything else sounds entirely reasonable to me on the "VPC per customer" plan.

bastion host per subnet

I think we end up more consistent overall if "Resign" and "Accept" have the same behavior in this case.

From reading the code, resigning (instead of accepting) probably also leaves the revision in "Needs Revision".

It looks like the price difference is pretty large -- $45/month for a m4.large reserved instance vs $80/month for a m4.large dedicated -- plus ~$1,500/month/region for having at least one dedicated instance. It would be easy to start using dedicated hosts in the future, right? Just an issue of converting existing hosts if we run into issues?

A customer is hitting an issue where pushes to staging areas do not push LFS objects. I'd guess this is an LFS upstream problem based on a hazy recollection of events here.

I don't see an "Email Settings" panel, am I missing it or did you mean a different panel?

T4411 discusses some similar issues, although it predates Spaces and focuses on subscribers rather than assignees.

That is, I think the right tool for the job is either runtime enforcement or lint enforcement: make unittest.skip() with no reason fail (so the tests don't pass) or make lint raise a warning like "unittest.skip() must have a comment above it explaining the plan for re-enabling the test.".

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

This is either T10333 or T4863. I'd guess the former will happen first. Filter is probably the best workaround until then. See also T12374 maybe, although I think that task involved a lot of meandering.

Notes for myself about billing:

Have you actually tested this scenario yourself?

See Consulting if you'd like immediate help with this issue.

Edit the Saved Query to contain something sensitive

From elsewhere:

A user might have a saved query which contains sensitive information no one else should know about.

That use case doesn't strike me as compelling enough to justify a separate field or a behavioral change so I don't plan to adjust our behavior here.

You must be able to view a post's blog to view the post, so the rule is effectively "view and edit".

Historically, Phame originally used the claimed rule ("only the author"), introduced in or around D3694.

The rule we implement seems to work properly, but the UI tells you a different rule.

The language here is inconsistent with the rule we attempt to implement. Let me make sure the rule we attempt to implement actually works and that this is just a language issue.

Synchronously in the request. I'll look at adding logging.

This is an issue specific to the repository names containing hyphens. The code is already calling calling the correct sort functions.

I created these repositories:

So I'm not immediately able to reproduce this. Some possible questions:

I used this parameter bundle to create a repository:

I'm attempting to reproduce this from the web UI first. I created a new repository, and get 0 versions as expected:

I am unable to reproduce this problem given the instructions provided:

That change fixed a lot of bugs, so we aren't going to revert it: reverting it would break all the things it fixed and added test cases for. --no-index --no-prefix diffs have never been part of the test suite and it is just coincidence that it worked before that change.

I'm writing a Mercurial extension to send changesets to Differential like hg email provided by patchbomb extension.

Also we aren't the only ones to be surprised by the AWS NAT junk:

It looks like Terraform probably can add a listener without destroying the LB (since it's a separate resource type? But the "changing the size of a volume destroys the instance" case suggests maybe it doesn't work like this, if that's how that works), but if you want to enable access logging on your LBs hope you didn't need 'em for anything important? I could probably just install it and figure this out / nuke production forever.

If PHP just injects that information into the templates during generation, we might not need to feed anything back into Almanac.

Yes, this is expected. The process of converting a project to become a parent project can not be undone:

Terraform also seems to have terraform taint (mark a resource for destruction) but no, e.g., terraform freeze (mark a resource for preservation). This is sort of philosophically bewildering to me. Is the modern approach to ops just like "data isn't important"? Is everyone just really, really careful when they type commands into their fully-automatic resource destruction rifles loaded with high-explosive foot-seeking shells?

How does the weekly deployment to all clusters work?

I guess everyone uses GMail nowadays anyway (as mandated by international galactic law) so my paranoia is probably mostly moot because they can undetectably read all email communication anyway.

I think you probably won't be able to answer most of those questions with Google Analytics. For example, bots will never hit client-side analytics, so any question about bots probably can't be served by GA. Likewise, GA can't see Conduit/API activity.

(Both adjust and doc/symbol documentation affect an entire service tier rather than particular servers, too -- we only need to generate docs or make schema adjustments once, no matter how many hosts are in the secure or admin tiers.)

My recollection is a little fuzzy, but I think admin may have once had a hacky crontab for backups that I replaced with a normal backup trigger at some point when the infrastructure matured a little.

I believe your analysis and proposed change are correct. D18177 brings that change upstream. It is now available in master, and should promote to stable later today (within about 12 hours).

This should now be fixed in HEAD of master and promote to stable later today (within about 12 hours). This change hasn't been deployed to secure.phabricator.com yet but will be deployed no later that tomorrow morning (about 24 hours from now), at which point the example link you provided should start working.

I think it's probably reasonable for us to warn about RSVP'ing to an event which has already ended. I'd guess this is usually a mistake, and in cases where it isn't some kind of weird off-label workflow is taking place and the warning is probably fine.

Why do you want to track users with Google Analytics or a similar library?

The "consulting firms" use case is explicitly disavowed by, e.g., the Spaces documentation, here: