@chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

I think my question is, maybe noone wants this feature.

I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

@chad, T10333 may address this, but looks very complex for a very simple issue.
Believe me, everyone using phab in my company complained about the priorities being automatically changed.
Sorting by Priority is a very common/natural way of using boards.
You should at least propose a setting in Phab to disable this feature - this would make everyone happy.

Natural sort is the default. If you switch sorting by priority, then this feature comes up. The only thing left on this task (since natural sort is now the default) is implementing a UI around the drag and drop for clarity. T10333 is that task.

It isn't the default.

Hi @chad , I'm talking about this issue : "drag & drop on a workboard sorted by priority behavior is surprising" which I understand to be the scenario where you move a task form a column to another in a board and if you're sorting by priority the task might have its priority changed depending on where on the column you drag it.
This behaviour in completely insane - I understand that someone may have thought of this being a shorthand - but it's a very bad idea to implement this behaviour by default.
Apart from this, Phab is awesome.

I consider this mostly resolved. Can you open a ticket with complete steps to reproduce per Contributing Bug Reports if you are still seeing issues. I honestly have no idea what "nightmare" or "here" means.

Could you please raise the priority of this issue? It's a daily nightmare for all folks here.

I used to think this way. After all, in an extreme programming environment it is common for two people to be working on the same task at the same time at the same machine.

testing

Sorry, apparently after running arc upgrade it no longer times out (although it does take a long time).

arcanist(head=master, ref.master=8f69a5c378c3), flarc(), phutil(head=master, ref.master=ff84abc7d857)

In T11699#195930, @chad wrote:

The error log says July

The error log says July

Server

• rP38b10f05a224d29c723c033dec0820f977aa8026
• rARC483e985d08d279816708a9e755de8e5c3586d3ba
• rPHU1a0371a2247a256d1e6e44d4f348adc2750a9788

version info please

Here are some query traces from XHProf:

I'm following up with the one who reported this to me.

hghg

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

name

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

aman

http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url]

name

I can't reproduce it anymore I'm afraid. Before I posted this I tried deactivating the repo, disable/enable the URI to no avail.
After I posted I removed the repo from the command line and recreated it from scratch. It now works. All the details are the same (I'm using a private key).
Works fine now
-\o/-
I've added other repos, observed and hosted (public and private) since posting and they work too. I don't know what caused this to happen on the first repo I created but I can't reproduce it since doing the remove.

Not sure how this was set up, but I noticed this in the logs.

How can I reproduce this locally? See Providing Reproduction Steps for help on providing reproduction steps.

Found something to reproduce this problem, or at least, I assume that plays a big role in it:

Our actual internal use case is as follows:

To accept this report, we need reproduction instructions we can follow to reproduce the issue locally. See Providing Reproduction Steps for details.

I would like to be able to do this as well. Being able to update a Phriction document.

I think this is entirely reasonable.

My concern here is the specific request only solves a side-effect of the root problem, and not the root problem itself.

To actually add a remarkup rule, the basics are simple:

Actually, the problem seems to be in the system configuration. There a hard limit on open file descriptor ( which limits mysqld to 214 connections.

My concern here is the specific request only solves a side-effect of the root problem, and not the root problem itself. We do not expect admins to have to create blogs for people. I would like to understand better what we can do in that case.

Linux Chrome dev channel 55.0.2859.0 (64-bit) have no issues with image paste.
Seems that it is ChromeOS specific issue.

After setting max_connections=1500 , the problem still happens some hours after running the instance.

Aside from that, I don't think it's too much of a stretch to say that as a general principle, permanent/irrevocable subscription to an object is tantamount to spam.

In T11687#195734, @chad wrote:

In my administrator/management role, I create a blog for someone else to write posts for

Why?

Specifically, a root problem would be how you got into this state to request this feature to begin with, not that you want the feature.

In my administrator/management role, I create a blog for someone else to write posts for

Sorry. I thought the root problem was obvious. I guess not.

this entire menu will likely go away

Please see Contributing Feature Requests and Describing Root Problems.

I think this didn't actually get handled in T10262, but should be doable now.