I'm going to merge this into T11036, which specifically describes subproject columns.

One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

Per above, this is working as intended. I'm open to implementing "Copy Columns from <Previous Milestone>" if anyone actually wants that, but it seems like I may have just made it up. Feel free to file a new task if you'd like to see it.

Yep, that looks good to me.

For (2), the specific problem is that there's no way to look up the milestone PHID, right? If you have the PHID I believe maniphest.search lets you find tasks tagged with a particular milestone:

I think this should be fixed by D17146, which landed a few hours ago. Presumably you're running some ancient stone-age version of Phabricator that's 6 or more hours old?

I think I got all of these, but yell if you catch any more.

This should do it:

(After T12071 we will almost certainly require "E", so you could get ahead of that now.)

Actually, it looks like PHP defaults to "EGPCS" but ships with config files that use "GPCS" (??? why would you do this ???), so this is probably not something that got changed or configured intentionally or accidentally.

Perfect, thanks! That's what I expected, so D17148 should resolve this. Alternatively, setting that value to "EGPCS" (without upgrading, just restarting the daemons) should also resolve this.

I believe this is now fixed at HEAD of master. You should be able to pick up the change with arc upgrade now (if you run master) or in about 36 hours (if you run stable).

While I'm chasing this down, can you show me the output of this command?

This is an unintended side effect of D17100 but resolution isn't straightforward.

This is D17122 interacting with some extremely high-quality code in arc.

This is far afield from an actionable bug report.

Using postfix instead of sendmail

We could possibly remove it entirely since I think it isn't useful for 99% of users, but D17144 just fixes the command.

That one is somewhat interesting because the user created a safe-looking object, then edited the objectionable content into it. I had hoped we might see a few years of uneasy peace before things escalated so far.

I think this really is the same as T10687, but the jittery bad degenerate behavior is only when a scrollbar gets added, so probably laptop + mouse works to repro but not laptop + touchpad?

Thanks for the excellent bug report with high-quality reproduction steps. Your clear, thorough reproduction steps made fixing this issue extremely easy!

Specifically, this was already improved by D15726 in April 2016.

The revision editor and diff editor should no longer be racing to edit the diff. The two revision editors may be racing now, but that race is significantly easier to resolve if it crops up.

This should work again now. The behavior probably needs refinement -- I don't remember exactly where we left it and I think there was some disagreement about who should or shouldn't receive build failure notifications before D10911 accidentally disabled this, but I think T9892 and other Harbormaster tasks discuss most of that.

Chrome upstream has patched this, now:

From elsewhere:

I'm not actually sure which will end up being easier, I think they have like 95% of the same problems. Quick Create probably is a bit easier, though.

Haha, maybe it's like when Blizzard uses a simulator to build a colorblind mode they screw it up, therefor the simulator must not work?

Ah, cool. I'm 100% onboard with it if an actual affected user has confirmed that the change is good, I'm just really uneasy about accessibility changes that don't actually involve the affected users.

Do you specifically not want to add a red-green colorblind mode to the existing "Accessibility" settings?

If a change only had one of those colors (e.g., just one added section, or just one removed section) I think I'd have no clue if it was removed-red or added-red.

You were thinking about doing this one first, then Home later, right?

That's easy to add, but I'd worry it will result in much worse readability for all users for diffs with a lot of small corrections. If there are just 1-2 big edits the extra "+" and "-" probably aren't a big deal, but choppier edits will get a lot of extra annotation.

100% accurate mockup of this feature

I'm hesitant about using math to solve this because I think Blizzard did that in Overwatch (apparently? or something?) and ended up with modes that were worse for colorblind users than users with normal vision:

What version of Phabricator are you running? See Providing Version Information for help.

Cool, glad things are back in working order. Thanks for following up.

I believe this reproduces by following the steps in T11537#192019, but deleting all timestamp information completely.

This is working as intended.

What color scheme would the user prefer?

I was able to reproduce this at HEAD and D17134 should fix it, but please make sure future issues you report are against upstream code -- not forked local code -- and that your install is up to date. Many issues are already fixed by the time they are reported, and we are powerless to troubleshoot issues with local code even if we wanted to.

See Consulting if you'd like a one-on-one answer from the upstream.

Please see Contributing Feature Requests for instructions on filing a feature request which can become a maintainable feature in the upstream.

Specifically, the limit is enforced here. You could remove this limit locally if you are not concerned about the usability of the result:

This is not a bug. The element has a minimum height because viewing or selecting text from a tiny element would create usability issues: imagine trying to select 30 lines from the middle of a 100-line block with lines=2.

See Planning for more information on understanding timelines and priorities, which also answers your question. Thanks!

In T11085#178406, @epriestley wrote:

You're watching #twitter.

I think the desired behavior is to silently drop the notifications, yes. Specifically, they should be dropped in PhabricatorMailReplyHandler->filterRecipientUsers().