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. :(

This hasn't come up again in three years so I'm just going to assume that everyone is realistically installing 0.7.0 or newer nowadays. Today, optiping strongly recommends upgrading to 0.7.6 or newer to fix some security issues.

Forgot to mention we're running stable week 34.

Let me see if I can reproduce this, but this is probably straightforward to fix -- I suspect some code just didn't get updated when Owners packages became mailable.

This a very old task that lacks root problem / use case information that we require for modern feature requests.

In T11518#191395, @yelirekim wrote:

Revision.

Basically "is the diff people are reviewing identical to your local branch"

Revision.

I'd call this thing arc status, because arc feature is "a wrapper on git branch", and flow makes me think of git-flow.

which devs don't? it's the designers, isn't it.

This general issue receives significant discussion in T3875. I don't think we've seen significant adoption of the unusual "stacked-on-the-same-branch" workflow, but similar concerns apply to branches-on-branches at the least.

I believe this was resolved by T6878 or related work. In the modern codebase, we fetch with --prune and explicit refspecs, which is sufficient according to git help fetch:

In T11517#191349, @chad wrote:

Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.

Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.

So for us "Close task" doesn't work anymore, looks like you just have deleted the code which processed the button. Is there any replacement for this I don't know or you have just deleted a nice convenient feature which worked fine for some people like we are?

who can help me?

I need help:>>> UNRECOVERABLE FATAL ERROR <<<

Note: this is only to log informations and try to reproduce the issue, with other user who see this bug, is it okay if I keep using this ticket ?

I hate commanding arc with these commands. Can we also please add please do a prefix for everything? Like arc please do a diff, arc please do a land

Ah, the project creation issue with gd issue is captured in T10405.

@epriestley - I did the same on your setup and can't reproduce!

Also arc anist should probably be an alias for arc, so you can type arc anist diff.

Thanks! I still can't reproduce this. Here's the install I brought up, following your instructions as closely as possible:

I want to join in

@epriestley - Find the steps below. If the below seems insufficient, please close the ticket. I have a workaround which works and I have attempted to substitute any other extra reproduction steps with a diagnosis.

This is not a bug report until it has reproduction instructions. If we don't get reproduction instructions, we will not send this to the bottom of the list -- instead, we will close the report as "Invalid" and ignore the problem: we can not move forward without reproduction instructions.

@epriestley - I want to be as clear as possible that this is NOT a support request. I have a perfectly working hack ( something I think actually addresses the root issue of JS dependencies at some level ). So I am just trying to help and I don't have a sense of how critical this issue is to the overall Phab roadmap. So I will perfectly happy with Phab eveb if this gets thrown at the bottom of the list and will be happy to stop updating this specific issue if its distracting.

arc anoid already works

Ah yes I forgot about the fun of internationalization. Btw those fragments are correct 👍🏻 (I speak Spanish).

Strings with sentence fragments like that can be difficult to translate in the normal human language sense, see:

The translation.override settings seems to be the easiest path forward. I definitely don't want to be modifying the source if I can help it.

It's possible there's some weirdness, but I think it just works. Let me know if that doesn't hold up in practice.

No I just read over all of the email commands and didn't see any exceptions thrown and I assumed this didn't work.

This is probably something we'll need in the very long run for T6703 (if we legitimately let you connect to two different LDAP servers, it would be silly to have two "Login with LDAP" dialogs) but, yeah, using translation.override or just editing PhabricatorLDAPAuthProvider might be the shortest path today.

Can you just override the translation? /config/edit/translation.override/

Per discussion T11508, I'm just going to officially call this a "feature".

Essentially I would like to customize the "Login or register with LDAP" here to be "Login or register with OpenDirectory"

(You are free to choose any other behavior -- even a useful one -- the requirement is only that arc weld do something.)

This will further familiarize you with arc. This may make sense to hold until some time after T5055, when arc workflows may change a bit. See also T11429.

You can find this UI in Config → Home Page → Pin Application. Here's the relevant control:

I think you should be able to throw any exception to get a reply to the user. Here's what I expect you to get back (from T10709), at least roughly: