Like others, I have been bitten by the PHP7 upgrade issue on Ubuntu 16.04.

PHP7 1.1 RC5 was released yesterday. Is there anyone out there using RC versions who can attest to them working?

In my opinion, everything has risks, they will release final 7.1 if it's stable enough. So at the moment, using PHP 7.1 RC 4 is better than commenting out source code with PHP 7.0

@khanhicetea RC5 is out.

But doesn anyone have any evidence that it works with RC releases?

PHP 7.1.0 has been released yesterday, and among the changes;

• Pcntl:
  • Implemented asynchronous signal handling without TICKS.
  • Added pcntl_signal_get_handler() that returns the current signal handler for a particular signal. Addresses FR #72409.
  • Add signinfo to pcntl_signal() handler args (Bishop Bettini, David Walker)

Does this help?

T9235: Add a warning about "always_populate_raw_post_data" being misconfigured is irrelevant on php7, as the setting has been removed. Trying to set it in php.ini appears to silently do nothing.

In T9640#189032, @michaeljs1990 wrote:

@reet- If you are using ppa:ondrej/php they tend to be of higher quality then the official php packages maintained on ubuntus ppa in most cases. You have to trust someone however and in this case it's ondrej instead of canonical.

In fact, the owner of the said PA is the Debian maintainer of the PHP 7 packages, Ondřej Surý.

Speaking of which, was there any progress on this? Debian release is very close, and I have to make phabricator package uninstallable (keeping only Arcanist and libphutil in).

See Planning for more information on understanding timelines and priorities, which also answers your question. Thanks!

Looking forward to support PHP7

In T11270#207025, @chad wrote:

I can't think of a reason to prioritize this. Specifically, it seems like since Phabricator for most (all?) companies is a business critical piece of software, you'd always choose to run it on the most reliable / stable version of PHP. Is there a reason we should consider that not to be the case?

See Planning if you have questions about how we prioritize tasks.

Maybe some users might have a problem with the fact, that the latest Ubuntu LTS that supports PHP 5 (14.04) does not longer provide hardware updates.
Don't know if this is really a problem for users. Just wanted to mention it

Link: https://www.ubuntu.com/info/release-end-of-life

I would recommend those users see Prioritization and have their business consider paying to have the feature built if it's a limitation they are faced with. We have roughly 2,600 open tasks here and 1.5 developers, Planning has more information on understanding timelines and priorities.

@chad - You know how can you get more developers? Being more open to contributions :)

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.

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.

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.

This project's contribution policies are not arbitrary; they are a direct response to our actual experience accepting contributions. We've been an open source project for almost 5 years now, and accepted changes from more than 300 contributors. Our policy is based on this actual data.

If you believe our policy isn't a good one, what are you basing that on? Why do you believe your information shapes a better policy than our information does?

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.

Even if you contribute a patch, you're asking us to take time away from high-priority changes and spend it reviewing and supporting low-priority changes. It doesn't matter if we're spending time writing low-priortiy code or reviewing low-priority code: this is still time spent on a low-priority activity instead of a high-priority activity.

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 :)

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

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.

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.

I honestly think you can do a better job of gathering open source contributors around the goals you are going towards so you can get contributions that help you advance for free. I for once would love to help you guys out but I feel kind of pushed away every time I try to contribute because the feedback I get is dismissive. If you point people to the right direction, I'm sure they'd love to pay back your generosity in some way.

My 2 cents. :)

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.

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

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.

PS. I've been running Phabricator on PHP 7 for about a year now and never encountered any real problems. Were even running it on SmartOS (Solaris) so I guess our Phabricator stack is the poster boy for "non-standard".