I'll do instance stuff

I'm planning to fix these, since I think they're easy or actually annoying, and just let everything else sit until we iterate or someone else notices:

In Phriction:

The only Maniphest thing I've caught is this:

• Maybe drop "Created" property? Doesn't seem terribly useful to me. This might have been a placeholder at one time to make sure that we always had something so the UI didn't render weird, but I think there's now no case where we have no properties. Fine to keep if you just like having it.
  • The list has lost icon colors. Maybe intentional? Makes things a little harder to pick out visually to me:

Probably pre-existing, but in Pholio, mentioning users in the description does not subscribe them. Embedding images in the description does not attach them to the mock properly. This suggests that the description is not being returned from some getRemarkupBlocks() sort of method although I don't remember which offhand.

These hashtag transactions should use a renderValue() style to render the specific values (for example "drip" should be dark/italic, not plain grey text), we might need to add a renderValueList() or something:

Thanks chad for all your help!

column history full width had other display bugs I didn't feel like writing CSS for.

No this is good, master gets promoted weekly, so this is a bug in master that will be promoted unless we fix it.

This state on projects might be a little misleading: here, theproject supports subprojects/milestones but the viewer does not have permission to edit the project, so they can not actually create them. The text means "It is possible to create milestones for this project" but the phrasing implies the viewer, specifically, can:

Oh, no it didn't. I just can't read.

I don't think it was?

Oh, yeah -- that technically promoted last week but I probably should really be looking at the last two weeks, since the previous roundup in T12685.

Maniphest

Changes this week are:

I also can't reproduce the original report in the general case: when I type text into the "Create Task" form, click a notification to navigate away, then press "Back", my text is recovered. This is true whether Quicksand is enabled or not.

It worked for me too, the trouble in my case was created by the character § used in a filename pushed into mercurial from a Windows client.

Any weird environment variables defined on those workstations? Also add --trace to the arc diff command might give more details

Just tried it, didn't help :(

Thanks for the feedback, those are useful references.

That wouldn't actually address the original problem here (accidentally setting your computer on fire and losing work) but would address the issue in T12731.

A possible attack on this is via whatever future abuse system we ultimately might build (T10215).

Maybe also T11440 for drafts.

I think its fine to let people manage how they get notifications in Phabricator, however giving every user the power to override every other users notification preferences would make Phabricator significantly unpredictable, which isn't acceptable to me in an enterprise setting. I'd suggest these users affected by focus issues use any of the hundreds of applications already available (including the task I merged this into, which will give even more control).

And by doing that, I realize that I have been keeping up with master instead of stable like an (oh, there's no donkey emoji, too bad...).
So it's fixed... Sorry!

Sorry, it completely slipped my mind!

This looks more like donating than like buying a service. That's ok; but there are established methods to manage such things, usually involving a non-profit entity which accepts members and where members get some voting/decision-making privilege above some threshold of contribution (but you could also call it a donor council or a sponsorship with benefits).

Your system has php-fcgi installed on the CLI (note cgi-fcgi in the output). This is incorrect. Replace this binary with a php-cli SAPI binary.

What if you disable the extdiff extension? The documentation doesn't mention modifying regular diff output but probably worth trying.

How could we make it more clear that we require version information for bug reports? Here's how we currently communicate this, but it seems like it didn't work well in this case. Is there a way we could improve this or make it more clear?

Please read Contributing Feature Requests carefully before filing feature requests. This does not describe a root problem; see Describing Root Problems.

Can you show me the output of this command?

We have installed mercurial 3.9.2 both in the server and client, in fact we downgraded the client mercurial from 4.1 to 3.9.2 to match the versions, but nothing changed. The version of arcanist is 3c4735795a29 (pre-last commit) and phabricator is at ef839192aa5a (from Tuesday).

I have been updating the DB manually to set status back to 0 as a workaround for now. But you could probably see how this affects our workflow!

For me it would be a great enhancement if there would be a shortcut which temporarily toggles this option:
Settings → Personal Settings → APPLICATIONS → Diff Preferences → Show Older Inlines

• I believe D17959 should resolve this.
• The new algorithm tends overall toward dispersing tasks over time, and clusters with more tasks should tend to cover an larger range, roughly linearly.
• The first few drags after the new algorithm is available may be very slow, since they'll spread the existing clusters out. After each large cluster has dispersed, all future non-pathological operations should be fast. (One pathological operation is to insert a million tasks at the same priority without performing any dragging, then perform a drag.) It's possible that cluster dispersal is fast enough that this isn't a big deal, although I may also just write a migration to normalize task subpriorities for everyone in advance of the new stuff landing so we pay this cost upfront rather than on-first-interacion.
• master has a bunch of churn already, it's late in the week, and this change is moderately risky (it's hard to undo damage if I got something wrong), so I don't expect it to make it into this week's stable release.

I'm not 100% sure, but from reading the subpriority movement code, it seems like our bell-curve distribution is self-perpetuating--when a block of tasks are moved, most of the time the next task is still relatively close, so $delta is small. I think this might be resolved by a big one-time readjustment to distribute tasks evenly throughout the space. I don't have an intuition on whether this distribution will redevelop over time, or if it's an artifact from the time before D12166.

This and T8588 have been a multi-year fishing expedition which I'm far from thrilled about, but I'll deal with this. 🐳

It looks like even after D12166, the subpriority-assignment logic doesn't do a great job of spreading our subpriorities. P2053 shows that very many of our tasks have subpriorities near 0 (in fact, the vast majority of our tasks; a separate query without the > 1 limit indicates that only about 4k tasks have subpriority neighborhoods of their very own.)

impressive

Currently, Fixes T123 in a commit message means this:

Basically, you're choosing to use a singular task status to track the various lifetime stages of a bug through multiple branches, which isn't what we intended that field for. It's just as easy to expect QA to want to re-confirm the bug is fixed in master as it is your workflow. I think you should track QA in a custom field.

It still doesn't sound like a bug to me, or maybe more specifically, understand what you expect the upstream to fix.

@avivey If you follow the steps in my description, you should be able to reproduce the problem. I'm also attaching a screenshot which indicates that a maniphest was reopened from "Accepted" to "Resolved" twice because the merge commit msg also contains the original commit msg "... fix T...."

I do think "Quote" needs to be somewhere (it wasn't listed at all in T11401#224171, though you mentioned it). Shift-click on reply could also be supported, but such a power user feature is far less important than an easily discoverable function. I believe that I personally would use "Quote" more often than "Edit", but honestly would be happy wherever this were put. I'll probably upgrade my Phab instance and start using the "R" shortcut next week either way.

We need to have enough information to actually see the problem happening, so we can figure out what's wrong, and maybe even test a fix.

I'll try to figure out more details/reproducibility for tomorrow, but through some combination of J+h+@ the highlight reticle will jump somewhere in the timeline

Yeah, some workarounds are:

you take your made-up ghost bugs and go sit in the corner and think about what you've done

Err yea I didn't mean feedback as in "this is what I'd like to see" but more of bug reports. I did come across a bug but it's neither earth-shattering nor consistently reproducible.

Yeah, give us a bit longer for general feedback -- I think I'll file a feedback task tomorrow with the release cut.

We haven't started the new features yet

@avivey I updated description to include version info, repeatable and steps to reproduce, is there anything else you guys need?

I believe we see the same issue in our environment, but I didn't think much of it/rule out actual problems with our setup and just restarted the daemons the first few times it's happened.

Is this open for test/feedback (I think it's usually called "Errata" here)?

I eventually muddled though things, and I believe work here has now substantially concluded.

I'm also toying with the idea of "Shift+Click" on "Reply" to "Reply-with-Quote" but the only way to discover that would be to read the documentation.

(I normally think of myself as like a 95th percentile power user, and don't use keyboard shortcuts at all in Differential today, and suspect I still won't after these changes. However, I'm also an elite mouse power user, per J769.)

Please identify the versions of mercurial used on client/server, also the version of Phabricator in use. If you're on an older version of Phabricator it's possible that upgrading may resolve the issue.

If nothing changes, I was thinking of leaving these top-level:

That is, we show the keyboard shortcut on the dropdown along with the action.

I think if we combine dropdown with keyboard hints, it'd be a good middle ground.

I'm not sure if D17908 is going to stick, but if it does we more reasonably have room to add a caret menu here. I'm not planning to necessarily pursue this in the current iteration, but I believe there are no longer any meaningful technical blockers, just some product questions which will more or less resolve themselves if everything sticks.

I just want to note that we fixed this in less than 5 years. Learn how in my upcoming book "Unbelievably Agile Ultra-High-Velocity Software Development Which Goes So Fast it Almost Must Account For Relativistic Effects".

I don't personally, since I neither use hg or windows, but maybe @cspeckmim from the community has some suggestions.

I tried to reproduce with other users, on the same phabricator install but there is only one user with a particular windows setup (that has nothing different from other users except for his particular windows machine) that is experiencing this problem. I tried following the stack trace and adding some error_log's on the php. But my php knowledge is close to zero. In any case something like this:

We have lots of APIs for external things, but without knowing what you're trying to do specifically, we can't really give you advice here. Herald / Mail are absolutely never the correct answer. Doorkeeper, Harbormaster, Feed Hooks, all available out of the box.

Please read and follow Contributing Bug Reports.