Somehow this didn't autoclose.

Would it be safe for me to write a migration that sets utcInstanceEpoch equal to utcInitialEpoch on every row in the calendar_event table?

After running the migrations, some instances of recurring events end up with null for the utcInstanceEpoch column. I'm not sure how this happened, however, as some of the instances have a value that matches utcInitialEpoch and I'm not entirely sure what the purpose of utcInstanceEpoch would be. If it matches InitialEpoch then it seems kinda useless, as does null...

@epriestley: Sounds good to me, this seems quite sensible in every way.

@epriestley: Jaime, Senior DBA at the WMF, has posted some answers for your list of questions:

Also, reindexing is required after switching to innodb.

Does InnoDB FULLTEXT respect ft_boolean_syntax? If no: is there another similar option? If no: we need to parse queries ourselves and submit the +A +B version to the backend (see also T10642).

That's some pretty awesome support for an unsupported prototype. Kudos!

@vanmeeuwen couldn't you use custom forms to lock/hide the policy controls on the maniphest task submission / edit forms? That's how we handled it at Wikimedia's Phabricator. As mentioned above, Custom Forms is the general way forward for controlling default task policies.

@epriestley: if you still haven't figured out how to trigger the calendar event ui in gmail, maybe these headers are part of the secret sauce? [ 1 ]

I doubt that upstream is interested in adding yet another configuration option, however, in case anyone runs across this issue, the following patch will make phabricator work with newer elasticsearch versions (2+)

@epriestley:
So far innodb is working. I can't say if it's worse than myisam really, seems pretty similar. Stemming would help a lot but the main complaint I have is the ranking algorithm seems really bad. It doesn't return the most relevant results first. myisam had the same problem though.

With InnoDB now mostly finished indexing, search seems to be working and the service isn't getting killed by locked tables. More info at the link I pasted above ^

Wikimedia is considering another stab at elasticsearch because we just hit a fairly serious scalability issue with myisam (https://phabricator.wikimedia.org/T146673) and it looks like innodb isn't a lot better. In addition to that, the mysql fulltext engines don't seem to handle stemming or even simple prefix matching.

+1 for mentions, that would serve the same purpose as see also: or related tasks: would. Primarily it would just be nice to be able to see them in one place instead of hiding in comments...

We use a text field for a 'reference number' which refers to tasks imported from bugzilla reference=bz123, or RT with reference=rt456

Here are 2 use-cases which are both essentially the same in all the important ways:

@epriestley: Are you open to patches that add more information to the calendar.event.search response? It currently does not even include the event time which is a pretty crucial detail to make the results useful.

IMO, Pokémon catching is an essential feature, please implement that first.

T10612: Editing a panel causes it to duplicate in dashboard may be the same root cause as this bug.

Ut seems to be T10145

I'm also seeing this bug.

I think this change broke dashboard editing slightly. Now when adding a panel to a dashboard column, the same panel gets added twice, once for each column. Removing either of the dupes removes both.

This would be awesome.

I think the root problem here is that "Herald added a subscriber: $user" is seen as email-spammy yet people are unwilling to edit their preferences to disable notifications for subscription-changes.

• Don't show commits twice in task details.

I misplaced the end of the if (!$task_graph->isEmpty()) block

I misplaced the end of the if (!$task_graph->isEmpty()) block

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

Needs a check for empty and at least a better error message in DiffusionBrowseQueryConduitAPIMethod.php:115

We are seeing this as well when attempting to browse an empty commit: https://phabricator.wikimedia.org/T140236

@epriestley - this is caused by a downstream patch which intentionally excludes sprints from the displayed groups.

@chad: indeed, word-break: break-all on the .differential-diff td element seems to do the trick.

Regression possibly caused by this: https://phabricator.wikimedia.org/T137394

Relatedly: it would be nice if milestones copied the settings of previous milestones, sort of a pseudo template behavior, where milestone2 copied the defaults from milestone1 automatically (so that if you set a series to default to the workboard, every newly created milestone would share that setting unless you override the default)

Personally I'm using milestones to represent releases and the workboard is the farthest thing from what I'd want to show when clicking on the milestone.

Here's what happens when adding wikidata project tag using the comment form typeahead:

@epriestley: Thanks for the tips. That field is actually a legacy thing at this point and probably should just be hidden everywhere.

Seems to be happening on quite a lot of Wikimedia's phabricator projects: https://phabricator.wikimedia.org/T128160 ... At least I think it's the same bug. I have no idea what might be causing this.

FWIW I really like proposal #2:

But for even more elite productivity, all web pages should implement command interpreters so we can have CLIs in our web pages.

This is almost exactly how I use the internets. Did I win at interneting?

FWIW I've gotten the same feedback about the new design, and I've had the same reaction as well.

This is resolved to my satisfaction by {D15468}. @epriestley: should this remain open to pursue something more elaborate in the future?

I've really never experienced any poor performance when using phabricator. It's not blazing fast but that is mostly due to the complexity of the server side php bits. I have literally never seen slowness in loading static resources.

Wikimedia is definitely interested in this one.

@csteipp was one of the people who originally advocated for such strict file visibility enforcement. He would be the best one to respond with justification for wanting the feature in the first place.

In T10262#165087, @swisspol wrote:

Naive question, but would it be possible to have a new "disable security theater" setting and have Phab then do "Unique URL Hash + Fully Cacheable Resources" like everyone else?

I like the idea of proposing an update but not automatically applying it until the author clicks 'approve.'

In T10584#164843, @epriestley wrote:

An example of a concerning "New Hire" case is a scenario like this:

It's your first day at Big Company, Inc. as a software engineer.
You submit your first a change to fix a bug.
Someone way more senior than you rewrites it, updates over it, then tells you to commit it.

I think this is soul-crushing and incredibly toxic, and want the software to prevent this from being a path-of-least-resistance workflow as much as we reasonably can. The easiest thing should generally be to ask the author to take responsibility/ownership, fix issues, etc., -- the same thing you'd do with a more senior engineer -- so new hires are on equal footing from day one.

FWIW - full time engineers at the WMF do routinely amend each others changes in gerrit, without hesitation.

In T5000#142199, @xclaesse wrote:

I am really attached to git workflow as well, so I wrote my own tool to integrate git and phabricator together:
https://phabricator.freedesktop.org/diffusion/GITPHAB/

With simple commands like "git phab attach" you can submit a git branch to review, creating one differential per commit. It is still "just" a wrapper tool on top of "arc diff", though.

I hope it can help others.

@chad wrote:
There are 3 choices.

1. Put in the subheader like on Ponder, Paste.
2. Put the date in the sidebar with Author somehow.
3. Make the first transaction in Timeline never hide.

+1 for having the second column position:fixed

"implement Gmail in Phabricator"

When searching for a subproject you don't see the parent project in the typeahead results:

I had to add an explicit cast to int when I ran the conversion script, but other than the 3 or 4 tasks which lost their points value, everything else worked nicely.

@epriestley: thanks for the thorough consideration.

In T6502#157400, @epriestley wrote:

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

In T8434#151667, @Krenair wrote:

I think one of the issues was people making a public task, and then deciding they should change it to security, but not having the permissions to do so?

@epriestley: We haven't pushed this to production but my initial impression from configuring forms on https://phab-01.wmflabs.org is that this should work pretty well. The only thing I haven't figured out is a way to easily transition a task between private & security sensitive and public. It seems that will require someone with adequate permissions to manually edit the task policies, which isn't the end of the world. We could possibly continue to use herald rules to make the transition easier, though I am more keen on the idea of totally killing off both the herald rules and the custom event listeners.

In T6683#86272, @epriestley wrote:

On this specific issue, we could also make the whole yellow bar a click target for "show older".

More broadly, given that this use case is extremely narrow, I wonder if we shouldn't consider a "presentation mode" -- which could maybe do things like disable notifications (particularly if we do more chat stuff later), make UI adjustments like this, possibly engage fullscreen mode, and let other users follow along (e.g., the presenter's open pages become shared, and you "follow screen" on the presenter and get the pages they open pushed to you so you can follow along locally, and maybe the pages could be saved for meeting notes or whatever, so you can go back and find stuff).

Although we don't do meetings with projections in the upstream, it's somewhat hard for me to imagine that fumbling with this link is the worst part of presenting stuff from Phabricator.

This class of use case feels wishlisty to me, but I've seen a few similar use cases (broadly, the "presentation" use case) -- for example, T4900 describes something similar. It seems like something we could eventually improve significantly on with relatively little effort.

I'm not sure how useful things like a reviewable list of "all the things we looked at in the meeting" are (and I haven't seen other software trying to build lists like this, so maybe it's not very useful) but it's the kind of thing that seems hard in the common case but easier for us given how broadly integrated we are. I could imagine this being something that doesn't exist because it's usually hard to build, but actually works really well.

Locking the icon field in projects doesn't actually work, it's still possible to edit the icon when that field is locked.

FWIW, at the WMF we make releases that involve hundreds of repositories: one for mediawiki, plus one for each mediawiki extension that we host. I don't think it is an ideal situation, and it causes me all kinds of grief, but it's the current state of affairs. So there is at least one potential use case for a release that encompasses a snapshot of multiple repos.

In T8434#147963, @epriestley wrote:

I ultimately expanded the scope here into a lot of adjacent work in T9132, but a rough version of "better templating" is now available in HEAD and deployed and configured on this server. There's documentation here:

https://secure.phabricator.com/book/phabricator/article/forms/

This is still a bit rough in places and probably has some bugs, but I think the big picture stuff is working reasonably well and mostly usable.

In T4209#69927, @epriestley wrote:

Specifically, performance from the Diffusion browse views.