Also, please work with other KDE project members to discuss KDE priorities and needs downstream, then have a single point of contact (nominally, @bcooksley) bring them upstream once there is consensus on the nature and priority of problems. Currently, you, @abika, and @bcooksley are all independently interacting with this upstream.

What specific modifications are you interested in making to the messages?

I'm making some amount of progress here, although I've only made it slightly past "run SSH in a loop" so far.

Worth mentioning is that you can query for exact(username) to get a dashboard for only individual reviews, but this is a partial solution; there's no way to get a dashboard for "all my stuff, except stuff I've explicitly said I don't care about".

This task has meandered a bit, but the current behavior is this:

I'm fine with just declining to implement that, it just seems like something we should fix if we're calling it a bug.

I think it was historically possible for third-party code to read custom config, but not possible for them to add new settings until D16928 (Nov 2016), which might be why we don't warn about bad values. Should be fine to do so now, though.

I think we've ended up in a fairly stable place here, and remaining work generally has existing tasks motivating it in terms of features (like T10967 for reviewers, T10574 for acceptance rules, T2543 for revision states, various tasks for inlines, T9713 for commit message parsing). Obsoleted transaction types also need migrations (but they should happen alongside the migrations that other features require so we're minimizing the number of weeks with migrations that need special planning) and this dumb mess got left in PhabricatorModularTransaction.php and will probably be there for an uncomfortably long time:

We'll probably implement a Phabricator-side mute-this-thread in connection with T10448, I'm just guessing that some of the users complaining that GMail mute doesn't work won't consider clicking a link in the email body, then clicking "Mute Thread" to be an acceptable solution.

I'm pretty sure we can't generate our own Message-ID with Amazon SES, at least -- although we use the HTTP API, not the SMTP API, and maybe the rules differ. Not sure about other providers.

See the LICENSE file for license information.

(Or we should just remove CAN_JOIN -- is there any actual use case for read-only rooms? If there is, shouldn't users still be able to join those rooms in order to follow them, just not send messages?)

A related issue is that CAN_EDIT does not imply CAN_JOIN, so users with CAN_EDIT but no CAN_JOIN can get a policy error while trying to join.

(Your diagnosis of the root cause was also correct.)

I deployed D17346 and rebuilt the indexes on this install with bin/search index --type DivinerLiveSymbol and behavior now seems correct. Thanks for the report!

Please file a new task following the instructions in Contributing Bug Reports if you'd like us to take a look. We need all that information before we can start looking at a bug.

I'm going to merge this into T12196; this is almost certainly an issue with PHP7. Upgrading to PHP 7.1.2 may resolve it.

Possible followups from D17344:

See Planning for help with timelines and status.

See downstream for general discussion. See T12256 / T12257 for upstream followups.

Example: I disabled a bogus user when the "confirm your e-mail" MTA job was on its ~200th attempt. It's now at its ~240th attempt :)

This is a copy of downstream https://phabricator.kde.org/T5242. See that task for discussion.

Thanks, this should now be fixed in HEAD of master. Let us know if you run into anything else.

Resolved by D17337.

The WMF downstream has some similar discussion here and in linked tasks:

T5701 describes a strategy for Pygments styles. I don't think we should tackle that as an accessibility issue, but I think building it as a user preference issue is reasonable.

If you configure your project so that arc unit runs your tests and then make your Buildkite build run arc unit --everything --target $HARBORMASTER_TARGET_PHID --conduit-token ..., you should get full reporting support. Then arc unit on its own will also work, arc diff will get the same integration, etc.

hiding policy controls when creating panels in context of the Arrange Panels page seems like a good way to minimize this

No idea if realistic, but what if this "feature" is only enabled on installs of less than 6 months (or with the right db schema or something)?

Those seem to have been the magic words:

Panels can currently appear on multiple dashboards, so we can't use the dashboard's policy for them directly. If we could, you could always see any panel by creating a new dashboard you have permission to see, adding every panel to it, and looking at the panel you wanted.

The LocationsResource file is completely copy/pasted and wrong (still refers to "Instances").

I think the complexity of those rules exceeds their utility.

Base scenario should create the appropriate edge tables.

And phabricator.developer-mode and phabricator.developer-mode and phabricator.developer-mode and also phabricator.show-prototypes.

We should suggest configuring phabricator.developer-mode and phabricator.developer-mode (for UIExamples, to see icons).

I suppose that I'm being lazy, but the exact same argument exists for arc close-revision or arc upload.

The db001 issue is still an issue, but the shard has managed to stay just under 80% for the last couple of weeks so we're not in any immediate peril. As followups, I think T12217 and T12218 better capture the broader issues here.

We haven't received any more information about this in a little more than two weeks, and don't know how to reproduce it so we can't move forward. Feel free to file a new task if you're able to come up with reproduction steps which work in a clean environment.

I think there are some more things worth doing here, but user profiles should be significantly more clear after recent changes. Here's @demo on this install now:

Oh we already had one of these

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

Presuming this is resolved since we haven't seen any evidence otherwise, but feel free to file followups if you run into issues or limitations.

We haven't received information that lets us reproduce this in about a week.

I scratched at the surface of T2794, but @chad also bought me a larger monitor so I can put more SSH terminals on it which should buy us another few weeks.

• Why do you track "percent complete"? What do you use it for?
• Is it actually accurate? Developers are notoriously bad at estimating project timelines, so I would naively guess that a "Percent" field would have almost no relationship to reality.