(I'm not sure how "Compatibility Mode" and the DOM inspector are interacting, so maybe I'm just using it incorrectly.)

Here's the note in PhabricatorPeopleQuery about this:

I don't think this is worth bringing upstream. It very occasionally saves users one click on an otherwise straightforward workflow, but requires significant complexity and maintenance from the upstream.

According to compatibility mode on my machine (Windows 7, IE 11, in IE10 mode), there is no crumb bug in IE10 if float: left is removed. This isn't consistent with T5902 or with other results I got (e.g., this thing says there is such a bug).

Are you OK with this plan?

I made some effort to fix this, but without much headway:

D17374 makes hovercards a little bit more clear too, although that might get some design feedback still (see "Horse" here, for example):

In the future (T550) we plan to allow arc commands to use an SSH key. I'm not sure if that will reduce or increase confusion.

You should be able to can arc install-certificate --conduit-uri=https://whatever to install a certificate for an arbitrary install with no other configuration.

What is your use case for API access to notes?

D17373 should fix the typo.

Thanks! Your reproduction instructions were extremely clear and made hunting this down straightforward. D17372 should resolve this.

I gave the goat some leaves to eat because maybe goats eat leaves?

Those are old now I guess, I'll file something to see if @chad can fix it because I am not licensed to pixel.

Well by the time you divide false into 3600 pieces you can't have much left!

See LICENSE for license information:

Recently, we've started seeing a handful of attacks where human users appear to read a discussion, formulate a human-sounding, contextual reply (e.g., discussing the thread topic in what appears to be a human way, just with a very shallow understanding of the issue), and then include a link to a site offering various services (mostly essay writing?) in the footer.

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: