No plans to move forward with this.

It does include this direction (T9868), so I'm looking forward to this.

The state transitions are a bit tricky. "Plan Changes" temporarily sets the status to "Plan Changes", but does not "address" (internally, "void") individual reviewer state on its own.

So by going through a Plan Changes status it would "clear" or "address" the prior Request Changes status?

I believe you can arc diff --plan-changes if your intent with (3) and (5) is to partially address feedback but not return it to me for review.

That is, the expected state at (6) is:

Okay - wanted to double check

The revision was created on 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2. While at that same revision I had updated the diff.

Oh wait. That is expected. The assumption is that the "one last change" in (5) is a response to my reject in (2), and that I need to look at it again.

That's not expected, but sounds like D17653. Did all the actions happen at rP517372a1?

A small update on this topic.
The diff I have submitted above in P1853#4950 is not working anymore since rP45b386596e62.
The corrected patch would be:

--- a/InsecureRemarkupGraphvizBlockInterpreter.php      2016-02-24 08:47:54.517183033 +0000
+++ b/InsecureRemarkupGraphvizBlockInterpreter.php      2016-02-24 08:51:02.784873997 +0000
@@ -41,11 +41,14 @@
           $stderr));
     }

I'm not sure if what I'm seeing is a bug or expected (or even if related to this). We have sticky accept set to true (just as default).

Adding the file should fix this error, but we'll almost certainly break it again when we go to 800x800 without a test.

Basically, we routinely double the size of transforms. When we do, we also need to replace default-111x111.png with default-222x222.png so we have a fallback. We have failed to do this ~every time we've doubled things since it's impossible to know/remember, so getting test coverage seems like a good idea.

oh i see... so I just make one for now?

In D17295, we changed the "profile" transform to generate 400x400px images instead of 200x200px images. When we add or change a transform, we need to include a default result file for that transform which can be used as a fallback if the transform fails (most often because an install does not have gd, but possibly because of a corrupt image, inaccessible file storage, etc). That change didn't update the default result file, resources/builtin/image-200x200.png, so we were left with a 400x400px transform but a 200x200px unused default image that were not linked to one another.

Er, sorry, what mistake did we make again? I can’t find 400x400 ever
existing?

Also javelinjs.com currently has bogus DNS, and there's probably no value in continuing to support it for the moment. I'll keep the bills paid on the domain in case we eventually revive Javelin as a standalone framework, but we could safely drop it from config.

I think the upstream actions are probably:

I don't see a 400x400.png anywhere in builtin history.

I suspect the reproduction steps are something like:

How can we reproduce this locally?

We already have a path forward on the next iteration of Phriction, and it doesn't include this direction. Please read Contributing Feature Requests and Describing Root Problems if you have future feature suggestions, root problems are required for any request filed. Thanks!

Here's what we currently have:

I'm going to kick this out of the ops space since none of this should be sensitive.

On mobile, I'd probably just keep this element in a fixed position on the page

@chad, some design stuff I'm thinking for later on, about in case you have feedback/ideas/objections:

I'm going to fix the editor behavior and then call this done.

I'm just going to merge this into T11401, at least for the moment. That may eventually split out into application-specific tasks when it gets underway.

If you experience this, please file a new task explaining what specific messages you're encountering and why hiding these messages is a better solution than changing the linters to raise more relevant messages. I believe fixing the linters is always a better approach here.

Actually, I'm just going to WONTFIX this. We may actually fix it, but I don't currently see a legitimate use case for it described anywehre.

My expectation is that the workflow in the task description will generally show this:

Actually, that description is a little misleading, but I'll follow up in T10607.

I'm going to merge this into T10607.

I can't reproduce this: