Well, it half-works in email, so that's something!

You can do this

They need to be on their own line. I think this rule got added in 2011, shortly after I left FB.

Drive-by mention in PHI91.

It should also work with Mercurial (D18652 and D18653 were my Mercurial tests).

• arc diff --cache (which was a passthrough for arc lint --cache) has been removed.

D18651 is marked as fixing this. The "fix" is very rough and will land in the experimental branch, see T11911 (and perhaps T12996) for followups.

• arc diff --no-diff (an internal workflow) has been removed.
• The internal "async lint" flag has been removed. This was an ancient, Facebook-specific flag for extensions which is obsoleted by Harbormaster.
• arc lint --only-new has been removed. This relied on upstream lint support which was never fully developed.
• arc lint --cache has been removed.
• The arc.lint.cache config option has been removed.
• arc lint --only-changed has been removed. arc now detects whether you want warnings on all lines or only changed lines by examining the other arguments (paths, --everything, --lintall, and --rev).

I think I'm going to land this stuff on the experimental branch since there's also some other related work which is better targeted there, and things are probably going to get worse before they get better.

Can we avoid filling the output buffer in subprocesses by testing if writes to stdout would block? (This should also be a "yes".)

See T12996 for spiritual followup.

This is now in stable, and deployed here and to the Phacility production cluster.

Modern flow is:

Some followup SHOW INDEXES from the case in PHI47 provided output which didn't have any evidence of key cardinality issues, so it seems less likely that this is a cardinality problem.

An unusual case here is Herald rules which take the "Send me an email" action, and act "only the first time". Their current behavior will be to activate when the draft is created, have their mail killed later in the pipeline when the Editor declines to generate any, and then never fire again.

I deployed this to secure without issue, so it looks like LOCK TABLES ... is promising as a general tool for migrations.

We actually already have bin/remote stop, I just run it so rarely that I forgot about it.

Next chapter: T12989: Phacility Deployment: 2017 Week 38

vault002 is dead. Long live lb001.

This is now deployed on this server, we'll see how it holds up. It won't promote to stable until next week, and I'd discourage anyone from picking it up right away.

This has promoted to stable. See T12974 for upgrade guidance. See T12985 for one followup change. This may still have some bugs (or it may scale very differently on real-world workloads and need substantial additional work) but I think we can handle those separately.

Swap DNS.

• I opened up 22 -> 2223 on lb001.
• I allowed external 22 in the security group.
• I hard-coded my hostfile and cloned successfully:

I'm going to take a stab at this now since I think it's non-disruptive and straightforward.

It's also possible to write a custom instances.do-exactly-what-we-need sort of endpoint and generalize later if that seems like a more promising approach.

The other shadow lurking in the water here -- which I think we can mostly avoid -- is that Almanac is mostly a-bit-bare-bones-but-overall-pretty-functional, except that the way properties on Bindings and Services are specified and edited is complete garbage. You more or less just have to magically know which properties are valid, and there's no real support for defaults or nice UI controls or hints about what you can set or suggestions that you're making stuff up and probably typo'd something.

The "most right" way in terms of consistency is to fully convert Binding to EditEngine, then implement almanac.binding.edit which can create/edit bindings. When creating a binding, it would require transactions specifying the service and interface. PhamePostBlogTransaction is sort of an example of this: when you create a new post with phame.post.edit, you must specify a blog transaction.

Yeah, this is hard coded here:

In Mercurial, can a branch have some open heads and some closed heads?

This seems like a legacy data issue that's probably unique to this install. The only way I could reproduce it locally was: