The Herald case and the next case (newAutoReviewTransaction()) both have some code duplication around prefiltering reviewers before building transactions for them.

Old-school resigns, accepts, and rejects are still using edges directly (can we get rid of these completely?).

These pathways are still dodging ModularTransactions and thus not getting double writes after D17495:

• The SQL templating should define some new variable like {$FULLTEXT_ENGINE} which evaluates to the appropriate engine at runtime.
• The Quickstart SQL generator should replace the raw engine string output by the build + dump process with this variable in the affected tables. This piece will be a little hacky, but I think that's unavoidable.
• The Quickstart SQL should be regenerated.

The issue might be caused by resources/sql/quickstart.sql still creating tables with ENGINE=MyISAM.
As there's no way to initially create them with MyISAM and then migrate them to InnoDB in case MyISAM isn't supported at all, another solution has to be found.

In T11741#213219, @Firehed wrote:

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

Just a note for the above - the initial DB seed script will need to be updated accordingly as well. Right now, trying to perform a clean install on a 2nd-gen Google Cloud SQL instance (which has the above limitation) simply errors out when it reaches one of the tables coded as MyISAM.

I didn't "ref" it here, but D17401 sort of technically did this. I'd like to clean it up a bit more before calling this resolved, though -- particularly, this is basically a secret that only I know about.

We'll open source everything that's general-purpose. (Currently, the only piece that's closed is the "plan" for Phacility deployments specifically. Since we don't have a generic "SSH" style plan as a starting point yet that plan is currently important, but we'll write generic plans or a general plan-executor or something eventually.)

I totally get the motivation to have a strong collection of highly integrated tools which all work together seamlessly and provide a value that is larger than the sum of it's parts.

It looks like clustershell is doing something pretty similar to Hypershell/Phage in its "gateway" mode (but it looks like it can't bootstrap itself and doesn't have a web UI).

Cool stuff. I didn't see you already had made so much progress before I commented on T12218. You can safely disregard my clustershell suggestion.

This is still a shallow ghost of Hypershell, but I successfully deployed secure with it:

I'm making some amount of progress here, although I've only made it slightly past "run SSH in a loop" so far.

I think we've ended up in a fairly stable place here, and remaining work generally has existing tasks motivating it in terms of features (like T10967 for reviewers, T10574 for acceptance rules, T2543 for revision states, various tasks for inlines, T9713 for commit message parsing). Obsoleted transaction types also need migrations (but they should happen alongside the migrations that other features require so we're minimizing the number of weeks with migrations that need special planning) and this dumb mess got left in PhabricatorModularTransaction.php and will probably be there for an uncomfortably long time:

Per T12218, the Phacility cluster is reaching a scale (~50 devices) where we need to improve tooling over "open a bunch of terminal windows". I want to look at implementing Phage for this use case and see how far I can get.

My testing from D17296 indicates this would also resolve the original problem described in T9639

@epriestley can you have a look at this, please?

I just got this email from Google Cloud:

Our DBAs are currently in the process of testing the a patched mariadb package. I will try to keep you posted on that progress but it looks like the fix is now backported to 10.0

From downstream, MariaDB has a fairly severe bug when indexing tokens with length greater than 127 bytes:

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.

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.

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

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.

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.

Looking forward to support PHP7

If you'd like us to look at it, please file a separate bug report with reproduction instructions, following the guide in Contributing Bug Reports.

I think this might have broken one of our Herald rules. The rule in question is an Object rule for Commits on a Project and will open an Audit whenever a commit is made to a repository that's tagged with this project.
At least it did ~2 month ago and after the upgrade it just won't fire. Just using the test console on a new commit in a repo tagged with the project simply says "Rule failed".
To make sure i already removed all the other conditions from it so it only states "always".

One thought here is that updating variables_order is fine on the server, but I really don't want to force arc users to muck with php.ini. Some possible "solutions":

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

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