• persistent header element is a great idea
• scrollbar annotations are very helpful

It's inconsistent because you need to be watching a room and someone has to post a message (in order to trigger a sound). Thanks for the report!

Super! We'll report results when we've got it deployed.

I shored up D17959 a bit, landed it, and deployed it to secure.phabricator.com, then spent some time fiddling with workboards here, but couldn't find any issues with it. We have ~6,500 "wishlist" tasks on this server and it distributed all tasks near 0 (approximately 2,700 tasks) evenly across the range [4096, 4096] fast enough that I didn't notice it. I'm currently inclined not to write a dedicated migration since it seems plausible that all existing installs will survive the first dispersal without much fanfare.

If anyone wants to fix anything else here feel free, but I think we squeezed most of the soup from this stone once D17972 lands.

Oh, yeah, transaction is great. Property feels a little clutter-y since we have the transaction anyway.

I'm fine with keeping it, just thought it might be a legacy holdover from a bygone era.

oh property. yeah, thought you meant transaction.

Drop "Created" property for instances.

oh thx :)

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