No one actually seems confused by Paste. Obviously documentation "should" exist, but probably not worth keeping this task around since it has just been idle for more than a year. I suspect we'll write it as soon as someone runs into a problem that needs to be documented.

We haven't seen more interest in this in a long time, and I don't currently plan to make compatibility-focused changes to the stack.

I'm going to merge this into T10448, which discusses limitations and improvements to the mail tags system. This is an example of a cross-cutting tag ("No Application/System Settings") that isn't handled gracefully by the current system, but correcting this and other similar issues is a goal of future work.

T7385 is probably also approximately this.

Commandeer fires Herald rules so stuff like "Require Legalpad Signature" or "Add Reviewers: that intern's wrangler" work.

The first page I found on the internet claims the iPhone 7 will be 1920x1080, so my strategy looks like it's paying off!

I think most of these are just moving into Application configuration over time, which tends to be a bit easier to use. I expect to just continue that trend in the future and this probably isn't worth building separately. I can't recall too much other confusion, and most of these are called <appname>.stuff anyway, which is fairly not-misleading.

This doesn't seem to be doing anything bad in practice. I think you can put the data in the URI if you want too and it works fine. Not clear that this is wrong/invalid enough to completely prevent it, and hasn't moved forward in a year and a half or so.

I think this was effectively resolved by D15775, which improved behavior for multiple cluster frontends.

T7074 may not be this, exactly, but they're close enough for government work.

This seems to be working, I think the last step is replacing the original call in the backup workflow.

We made this a little smarter and a little less prominent (on a non-default tab) and I feel like it's generally in a more reasonable place now. I don't currently expect to make it significantly more complex, and none of the rules proposed here feel like simple, unambiguous improvements to me.

We haven't seen other requests in this vein, exactly, in about two years, and we generally don't expect users to rewrite published commits as a routine workflow.

T6706 was the IP-address specific task.

We haven't seen other requests for this in nearly two years, and it can likely be implemented as an extension, except possibly for the weird cases mentioned above.

I have read https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ , and it briefly addresses this:

Oh, yeah, maybe need @avivey or @epriestley for those questions. Over my pay grade.

Yes, that works if you decide to collaborate ahead of time. If you decide to "stack" on top of a revision under review, you have to either

Personally, I think it's maybe easier to do review along the way, but you can go the other route where you just both git push to the remote branch, then review run arc diff when you want to merge it into master.

Hmm, but that's not quite the same thing as what I'm asking (I think) -- in my scenario a pair of authors are adding commits to a branch off master (imagine it's a refactor and we're fixing different tests), and the stack of commits is reviewed in one PR. I know I can do this today by just creating a remote branch, collaborating with someone on it, and doing no code review until all the commits land (at which time one of us creates the Differential revision).

I can't easily find an example, think its been about 18 months since we last did a feature branch.

It's sort of like:

Could you point me at an example revision to see how this looks?

We haven't seen other users run into difficulty with this in the last couple of years, so I don't currently plan to change it.

This was filed a while ago, but it's not clear to me why this is useful -- no obvious reason to want to do this springs to mind.

No clue what this was, haven't had issues recently. I think config may have become simpler in the last couple years.

Although I don't think this is necessarily a bad idea, I haven't seen too much of a need for this. Some alternatives:

Ah, thanks! I think that should be relatively easy to fix.

This happens for everyone here in the company on windows chrome with the HRV (Croatian) layout, where the @ symbol is achieved with the right side alt (ALTGR) + "V". Think that registers ALT + CTRL + V.

We have an existing repository_badcommit table which is used to mark commits as "bad", where "bad" approximately means "the repository as a whole works, but the VCS tools can not read or should not read this particular commit for whatever reason". This is rare, but can happen when, e.g., third-party tools are used to write into repositories.

Yes, I have tried to do storage upgrade but it ends up with an error.

Have you tried following the instructions given in the error message?

In T5051#156552, @chad wrote:

...
This task will be re-scoped to just being about burn down charts for milestones.

Re-reading D9115, I think I was never able to understand or reproduce this and it was ultimately mooted anyway.

As far as I know, no users have actually gone berserk and deleted all their comments in nearly two years now, so I don't plan to specifically build comment removal rate limiting: this action does not seem particularly more dangerous or abuse-prone in practice than other actions like adding comments, merging tasks, etc. If a user did do this, recovery is likely not very difficult even without limiting.

Though I guess a "fake" dashboard is not as performant as actual dashboards. But equivalent to current hardcoded homepage?

Yeah, I think scope-wise this could get out of hand quickly and consume a month on both design and engineering. I think I can propose something here that will not take your time and maybe 1-2 days of mine.

I built a similar UI as part of D15926, but we declined to actually bring it upstream. It's possible that we may revisit this in the future, or that it may become possible via T418, but I don't currently plan to pursue this.

We now allow you control component order in the date control.

I haven't come up with any kind of rule for this in the last couple years which feels sufficiently un-magical, even in theory. It hasn't happened all that often recently, either, at least that I can recall.

This is like two years old now, and I'm pretty sure it works now since no one else has reported it and it would likely have come up when clustering was written a few months ago if it was still an issue. If anyone is still seeing issues, please feel free to file a new report with reproduction steps.

arc cast

I think this was effectively resolved by D12773, since using conduit.token should evade the session timeout.

Sounds like we should write a "Screencastph" app!

is there a twitch module for bash? can I live stream this excitement?

how.will.it.end

rough life :(

do-dist-upgrade is pushing me to 16.04

welp

I'm on 14.04 and it has 0.6.4 installed. :(