Yes. In Mercurial, branch heads may be "Open" or "Closed".

That the branch is closed?

What is state here? I don't really remember what this was about, or if it's needed.

I'm going to merge this into T12963, which isn't exactly the same but overlaps this substantially. It's possible we'll pursue a more narrow "vacation review" mode eventually, but we'd want to finish T12963 first and make sure it didn't adequately address this problem on its own.

@epriestley @jdiepenmaat If I may add ideas on that. I am using Things at the moment. There are only two reasons that hold me back to finally and completely switch to Phabricator:

• recurring tasks
• start dates for tasks

The latter is basically what your example is about, right? Because if I have just renewed the SSL certificate then a new task is created (due date being in one year), but it should not possible to start that right away, as it's not necessary. You would use a start date as well, wouldn't you?

It works great now with Windows + Chrome + German keyboard layout!

Search is now in the header, see rP

Practically, msortv() and PhutilSortVector are now the solution here. They provide high-performance (no usort*()), multi-dimensional, stable, explicitly typed sort.

Just sweeping this up, rewriting the property display to show +x seems reasonable to me but I think it's self-evident enough that we don't need to keep a task around for it.

I don't think this meets the high bar required by modern feature requests (see "Upstreamable Feautures" in Planning).

(This isn't anything upstream-actionable.)

This seems to have calmed down.

We appear to have survived this. D18398 removed the double writes. There's a bit more cleanup (we could remove the edge type and actually destroy the older data) but that can happen whenever we get around to it.

In T10890#231066, @epriestley wrote:

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

This is five years old, and doesn't meet the requirements of a modern feature request. If you're still interested in this, feel free to start a new discussion on Discourse.

This doesn't meet the criteria of a modern feature request and predates significant changes to the inline comment UI. If this is still an issue, feel free to start a new discussion on Discourse.

Closing this for lack of feedback, feel free to resurrect it if you get back to it.

This isn't a bug; they aren't subscribers, and aren't listed in "Subscribers" in the right-hand column or in "Subscribers" in "Edit Task".

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

I just clicked through it, I don't think there's any reason for staff to be there normally.

Just curious what you want to do there as staff.

Is this what you expect to see:

Alrighty

There doesn't seem to be anything actionable remaining on our end.

We still get a tiny mess where administrators clicking "pin" might mean "pin by default for all users" or "pin by default for just me" but that's reasonable to clarify in the workflow.

Currently, users may hide or reorder builtin queries. With the simplest version of the plan above, users will lose that ability: builtin queries will always be visible (unless hidden by an administrator) and always at the bottom of the list.

@aubort, please use the community forum (see: Discourse) if you'd like to discuss this issue.

@aleb, if you like to continue discussion of this please use the appropriate channels, as @chad suggested above (at the time, they were Conpherence and Ponder, but the appropriate channel is now the community forum -- see: Discourse).

+1 the problem is still here. There's no way for a end user to make it right without the need for an admin to go run a command on the server, which is not very good.

The error truncating behavior affects also Diffusion > R > Status, where only part of the stderr is shown, making it impossible to debug the problem without hacking Phabricator:

ab@phabricator-1-vm:/opt/bitnami$ diff apps/phabricator/libphutil/src/future/exec/CommandException.php.original apps/phabricator/libphutil/src/future/exec/CommandException.php
59c59
<     $limit = 1000;
---
>     $limit = 1000000000;

In https://hackerone.com/reports/259246 (not currently disclosed) a researcher found an actual issue with figlet. Although it would probably be hard to develop into a practical attack, it does make me feel better about the decision to pull all this stuff into PHP (not just dot) when the dot issue was originally identified.

I've landed the two scary migration changes (D18418, D18419) and deployed them here without any obvious issues arising. The actual effects here are:

I'm just going to merge this into T929, I don't think it's a distinct task. I'll link that to T12824.

They should fix themselves once the instance is suspended.

This cropped up in the HN thread -- works in my browsers (although Phabricator does not recognize it as a valid link):

Thanks for the writeup :)

adding my vote to @ivo's suggestion.

The reason the upstream projects aren't using -- is that it isn't portable. For example, Putty's ssh doesn't support it.

The full set of mitigations is now available in stable, and I've promoted 2017 Week 32 (Mid August).