I'm going to push this out to next week since D19586 probably has a few minor issues with it and it's close to the release cut. It adds a lot of new policy checks which weren't explicit before, so I'd guess it may cause a few improper policy errors on things which are actually allowed. I caught a bunch of them (like "Mute Thread") but probably didn't get every single one.

These are actually removed in 2018 Week 33. See T13186 for a small amount of followup and discussion, although there isn't too much new information beyond what's here.

Oh, right, "meetings". I've heard of those!

In T13062#235217, @epriestley wrote:

This is also showing up in initial email, which is silly and pointless.

I'm touching some adjacent code for a "Disable User" permission in T13164.

Hahah you beat me to it!

I think T13183 is the exact same hosts. :)

In T13185#240300, @epriestley wrote:

Same as T13183?

Same as T13183?

The root use case here was a desire for a better sense of how often certain rules were firing, and we improved the push logs instead to address this more directly (D19555, D19556, D19557).

I did rebuild-identities on every instance

The "activity" migration went to production just now. I expect all production instances just bailed out, since I ran rebuild-identities some time ago, but I'll verify that:

I believe this was fixed by D17558 and discussed in T11050.

Somewhat related:

T13182 was a resurgence of this exact issue, but I'm currently banking on the fix being a move to Ubuntu 16 with T13076 before this breaks again, given that it was stable for ~18 months.

That appears to have fixed it, so this was just T12171-redux.

It feels like the basis of the problem is that linting was written well without autofix in mind and then the feature was added later.

It feels like the basis of the problem is that linting was written well without autofix in mind and then the feature was added later. It wasn't designed in from the beginning and that results in limitations where compromises were/are necessary. Unfortunately, this means users sometimes end up with unexpected or unintuitive behaviors. I think we're all just trying to find ways to mitigate them.

A related score-board might be to show mana-rich tasks.

One specific thing we hit in the context of T13180: sbuild001 stopped and started with a new public IP, and the Almanac device record needed to be updated with the new address.

This was more fun than expected. Notes for future historians:

Doing this now.

See PHI790, which reports an inconsistency in reporting between APCu and APC that possibly points at a more significant issue.

re-archetect the patch application to operate per linter or per issue rather than after completing all analysis

Here's an example: