So regular comments on the feed page, nothing to do with differential or inline comments?

Regular comments, not inline comments (Although I haven't checked those yet).

So feed and differential inline comments?

@michaeljs1990, is was actually not possible to install PHP5 on Ubuntu 16.04 through a safe means (an apt repository or similar) for some time.

Ha! It's bad in the feed page.

Sounds like this is resolved? Or should we attempt to catch this case?

Or are you just concerned that they may make mistakes

The whole "identify the packager problem" with composer is indeed a big one and i'm not suggesting you use composer in any way for the arcanist/phabricator packages! Generally i agree that i want to primarily trust the packager and not the developer. This is the way this is handled with os packages (rpm/deb) and companies are used to the workflow: Getting new packages from a somewhat trusted/signed source (e.g. redhat/canonical), testing them yourself, signing them with your own key as well and then distributing to the internal repositories and "end users" only trust your own internal key.

(You can't write "Run Build Plans: ..." personal rules, but you can write them in object rules, which isn't too much different.)

It's also probably bad/inconsistent that you can run builds via Herald which you could not run via the web UI.

I have mixed feelings about relaxing this. I think there are basically two parts to this:

I generally expect all signing to be external, at least for the foreseeable future.

It might be beneficial to generally support gpg signed commits / tags in phabricators git repos and then use the same mechanism for the arcanist packages.
Since github recently started pushing this feature a bit (https://github.com/blog/2144-gpg-signature-verification) quite a few library maintainers started signing their release tags.
And i just recently spoke to a lib maintainer about extending composer to verify all packages (on install or upgrade) against a list of authors trusted by the user (or an enterprise wide list).

It seems likely, as well, until php 7.1 is officially supported that you probably don't want to sign-up for some potential pain points by choosing to roll the dice.

Thanks. Appreciate the quick fix on this.

I think you are using the word "only" wrong @PascalReintjens, @CodeMouse92. What you mean is by default. You can easily install any version of PHP you want this should not be a blocker for anyone. It's a slight annoyance but so is trying to keep track of the release cycle for RHEL, Ubuntu, CentOS, Debian, OSX, ArchLinux, Gentoo, and every other distribution you can think of.

In the case of Debian 9, it looks like it won't even freeze for 6 months. If it ships with PHP 7.1, it may well run Phabricator. It is impossible for us to answer compatibility questions about hypothetical software slated for release the better part of a year from now.

@PascalReintjens, correct, in the same way that it won't run under Ubuntu 16.04 (which also comes with PHP7 only).

Debian Stretch will come with php7 only. Am I right assuming that Phabricator won't run under Debian 9?

Thanks for your help / advice Evan!

Hah, I actually had the page title instead of table of contents but it felt really repetitive

In this particular mock it's slightly confusing to me that the left nav looks like it has a "Table of Contents" header but is showing a document hierarchy (i.e., element that looks like a header does not seem to be labeling the content beneath it). Not sure if that's a mock thing / interaction thing / whatever.

It would also be nice to recognize that "oldname" became "newname" so we could redirect, continue delivering mail, etc. This is a little more involved.

Specifically if you feel this is a Phabricator issue, please provide steps we can follow on a clean/new install on http://phacility.com/. Test instances there are free to spin up any time.

Please see Contributing Bug Reports for how to file a proper bug report. See Support Resources for what resources are available for getting help configuring or using Phabricator.

Oh, I think I made up point (1) above -- that's already the behavior.

I am an admin w/full permissions, but even so I've tried just doing this on my own personal blog that I created myself and can't even do that.

Specifically, if you don't have permissions to edit a blog, you should get a permissions dialog like below. Sounds like someone has been messing with the custom forms.

I can't reproduce this. Can you open a bug report with full reproduction steps?

Maybe link it in the "Explain why" dialog?

Ah, sweet. Thank you!

This question has been coming up rather frequently lately; maybe we should expose the branch configuration more prominently somehow?

Yeah, we don't support or recommend third-party extensions anywhere in the documentation. We're years away from that.

@chad My bad, let me explain.

No, it's not our product. It's a third party extension. Please contact that maintainer for help.

@chad Agree, but it is "in yours product/project". Does this does not count?

This isn't our code:

In T6502#187499, @dpaola2 wrote:

We have no precedents of abuse in Phabricator so far, but looking at our history with Bugzilla I will not be surprised the morning we find a first precedent.

^ I am incredibly jealous of your perspective and am really, really surprised you haven't had this problem yet!

I'd like to make the Diffusion UI more field-focused (T9713). which is maybe adjacent, although not directly related.

Also, please note this:

Example 1: Batch edit of more projects at once - obviously easier to run script than having to click it manually.

In T11405#188030, @epriestley wrote:

How about this: we'll play the "5 whys" game described in Describing Root Problems to get to bottom of this problem. After we figure it out, you tell me why you didn't provide that information in the first place and how to improve the documentation so that it's clear what we're after. Sound good?

Fair enough. I'm totally willing to sprinkle my head with ashes after I'll find out what exactly is causing the misunderstanding of what "root cause" is. ;-) But not knowing it is obviously not helpful and leads to the same situation again.

In case anyone is interested, we just released a first version of "remaim", a tool for migrating Redmine issues to Maniphest tasks. Pull Requests are very welcome! https://github.com/tentwentyfour/remaim

Yeah I have a diff incoming, looks like it's working.

Try now?

See also T11401, although this started life as a Pholio task and that's now a code-specific UI task so I don't know if they're actually the same.

Yeah, I think this is largely an issue of how much space we have in the UI.

I deployed this stuff here. I neglected to get a production timing beforehand so I can't really claim it's actually faster, but it seems fast-ish now. Let me know if things look better and/or I ruined everything when you get around to deploying it.

How about this: we'll play the "5 whys" game described in Describing Root Problems to get to bottom of this problem. After we figure it out, you tell me why you didn't provide that information in the first place and how to improve the documentation so that it's clear what we're after. Sound good?

I don't immediately have an attack on the JIRA thing (it should be less expensive in normal cases), and don't want to do the Auth stuff without more planning, and nothing else leaps out at me as having a similar sort of value for the cost.

There's still quite a bit of room here. Locally, I see a 220ms call for differential.revision.search. Here are savings which look fairly easy to capture:

That sort of leaves you in trouble with custom edge-based fields like the one above, but a reasonable short term approach is the one you've already taken: