phuix-js builds phabricator-action-view, so that's what I was planning to be king.

This diff will be a wondrous, wandering tale or action, adventure, mystery, intrigue, and touch lots of random stuff that should have been broken apart.

Yeah, I'm not aware of any real difference between them or good reason to have both. Maybe I'm forgetting something but I'm pretty sure we can merge them eventually.

Yeah I think we shouldn't have two types of lists.

I think there are two approaches:

We are still occasionally running into this problem. A queuing system which ensures some kind of fairness would be really useful for us and others in the situation where demand is much greater than the builder resources. (A similar sentiment to T11153#180635)

One thing I haven't been able to build is the ProfileMenuItemConfigurationQuery -> ActionView

These are now in production. I inched some other automation forward but no major changes.

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

ok, probably tomorrow

uhoh

I plan to land several fires

Solid.

Hour or two if nothing's on fire -- probably today, just later this evening.

Awesome. What do you think the time delta will be between release promotion and the fix you have being merged to master?

@jmeador, I think I have a fix for your use case but it touches enough stuff that I'm going to hold it until after release promotion. Your use case is a bit unusual but should be possible to support.

Thanks. I was modifying php version because when it was last deployed PHP 7 wasn't supported so 5.6 was installed as well so there were two PHP versions on the server.

See Contributing Bug Reports and Providing Reproduction Steps for more information on what's required in a bug report.

This isn't a valid bug report. Specifically we require version information and complete reproduction steps. Using a new, clean instance on Phacility, I am not able to reproduce the bug you state.

(I no longer need access to the server.)

Having run the scripts on a new server the only thing I can think of is the fact that the scripts change #!/usr/bin/env php to #!/usr/bin/env php5.6

@aurelijus unfortunately that wasn't it. I had local.json configured.

This was prioritized privately and PHP7 is now supported. Not sure I got everything, but I'm on PHP7 locally now so presumably I'll hit any remaining issues before too long. T12101 is the new informational task. We will now accept bug reports against PHP7. The documentation should regenerate within a day or so. These changes will promote to stable in about 24 hours.

Hopefully Android browsers will hurry up and ignore that tag too..

There are at least some nontrivial effects, like searching for text without "maximum-scale" can imply a zoom:

Yes, the rest of the tag is good. I just don't want pinch-to-zoom to be disabled.

Oh, sorry, you just wanted maximum-scale removed.

Here are some screenshots of Phabricator with this tag removed, as you suggest:

I'm not asking you to implement a new accessibility feature, I'm asking you to stop *preventing* an accessibility feature from being used. Browsers already do this; you just need to stop telling them not to.

As you might already have guessed, this isn't a bug.

Chrome 56 has merged a fix for this so it should be moot in the not-too-distant future, although I'm not exactly sure what the Chrome release schedule looks like. If this only impacts ghost inlines for a few more weeks it's pretty tempting to just wait for it to resolve itself, but I may be digging around in that code soon so perhaps I'll take a more detailed look.

Is it possible that this issue effects Differential but only for inline-comments that have been ported forward from a previous diff (i.e. the ones that are rendered as slightly faded). I see this issue on this instance with this revision: https://secure.phabricator.com/D15675, none of the anchor links in the timeline work for me when I use Chrome 55, but I don't see the same issue on reviews where comments are on the most-recent diff (not faded).

I'm going to switch this view to show overall commit audit status, not weird semi-viewer audit status. At one point it wasn't clear how heavily we were going to try to skew views to account for viewer status, but bucketing changes seem to have reduced the need for this and I think extending the Differential model to Audit now makes sense. See also T9430 for some context.

I'm going to merge this into T7076, which discusses revisions instead of commits/audits, but the resolution for both is likely the same and that task has a more complete discussion of context.

I always thought the Hashicorp projects seemed to cope nicely with a lot of patches and contributors. Projects like Packer and Terraform each process boat load of pull requests.

@BYK Definitely sympathetic here, and we are actively looking to add bodies to the upstream.

I don't think the task detail trivializes this. I expect PHP7 issues will take very little time to resolve, perhaps 2-3 hours? Some installs already run PHP7 with varying degrees of success, which implies there are likely few unknowns lurking in the shadows. I believe this is not a large or complex technical task; it is purely a prioritization issue.

I wasn't trying to create a whole new discussion. I respect your priorities and I also understand the engineers vs. money problem. The only major problem I see with the contribution guidelines is this: to be able to contribute more or affect change, you need clout and to get clout you need to contribute and for those contributions to go into the code or even get some feedback we need time from you guys.

Yep and just as sort of an addition to my previous comment and why I said that: I feel like the current Task Detail trivializes what it probably really means to support PHP 7.

Well, priority and planning documents apply to all 2,600 open tasks, here. But I get what you're saying.

I believe the idea of contribution and input changes are entirely up to the project and what they can support, that said it seems entirely off-topic for this task (imho) and the only thing I would suggest is updating the task detail at the top indicating the statements you've (@epriestley and @chad) made about prioritization and planning so there isn't a comment chain every month about this in this ticket :)

I'll also note that this discussion is moot, anyway: this is not blocked on development resources, and is purely a prioritization issue. If we had 10 full time engineers, this still wouldn't be what any of them would be working on.

We were more open to contributions in the past. The high bar contributions now face is a direct response to the enormous maintenance burden that those changes saddled us with. This is explained in Contributing Code and elsewhere.

I have to agree with @BYK, there's been a lot of interest in getting PHP7 compatibility added. Multiple individuals have offered to work on getting 7.1's async working in Phabricator going back to pre-7.1 release. Phabricator contributors have consistently been absent from the discussion or just shut it down. It's stifling progress and causing interested developers to take their talents to other projects where they can actually get things done.

Honestly, I'd have to disagree. I think us maintaining the roadmap means Phabricator grows faster. Taking detours on external patches daily limits our ability to execute on our own goals, and puts us behind on larger features. I do want to hire a developer or two so accepting patches isn't roadblocked as much, but that means prioritizing $$$ and Phacility first.