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:

Ah, there are really a couple of issues here.

Come on, Evan, seriously? :-/

Please please please please please please please please please please please please read Describing Root Problems carefully and think about what it is asking for.

In T11312#188006, @Danny_B wrote:

there is no (preferably customizable) real feed (Atom, RSS). [...] there was some task here about it but I can't find it now.

A small (partially off-topic) note about feed - in such a high traffic Phabricator instance like ours (WMF), it is nearly unusable. Fortiori if there is no (preferably customizable) real feed (Atom, RSS). Lack of feed support in Phabricator is one of its biggest disadvantages. I know there was some task here about it but I can't find it now.

As I was asked to provide some input here:

In T11312#187893, @epriestley wrote:

• Why aren't they using "Send me an email" rules?

That is what I am currently doing via Herald in our Maniphest installation. :)

• Why aren't they using Feed?

As a bugmaster, my workflow is primarily email-based (describing a fact here that likely could be challenged). I receive notifications on Maniphest task changes which interest me and filter / process them. I abuse the "Unread" status of certain emails to mark stuff I'd like to follow up on later. I have not played with Feed (or an application to consume feeds) to be able to judge whether that would also suit my needs on processing large amounts of information and acting on some of that.

• Why do they want all of this information in the first place?

As a bugmaster, I'd like to get informed of most / nearly all changes on tasks, to allow me clarifying task descriptions (steps to reproduce etc), escalate issues that seem important, manage expectations, etc., to support our many stakeholders.

That looks broadly correct to me, I just want to try to remove the assumption that the first object's first field's storage is universally the right storage in fixing this upstream. It's always true today and for the foreseeable future, just obviously not a Fundamental Axiom of the System. Let me review D16346 and I'll spend 10 minutes on this, I'm pretty sure it's straightforward, not a weird snowbally mess, and that the upstreamable patch is only cosmetically different from that one.

This is brittle but it works if your objects all use the native storage.

I think the issue is that there's no callable thing for bulk-loading custom fields right now, which is why SearchEngineExtension doesn't have a hook for it. Other SearchEngine extensions don't need it since none currently load any data.

T10635 is vaguely related, too.

See Planning for help understanding timelines and priorities.

I can't reproduce this here, locally, or in the Phacility cluster. Can you? You should be able to push to rGITTEST on this install, or launch a test instance from admin.phacility.com and create a repository there.

Is this still actively being worked on, is there a different solution than View Options->Set Tab Width, or should I apply the patch referenced by raman.rathod?

It would probably help if I knew what 'refs' git was trying to push and failed on. Normally git is meant to tell you what failed if I read all the git pages/help - but it seems git isn't telling me anything about the failure!

Thanks for feedback so far :)

(ノಠ益ಠ)ノ彡 sboן ʇsǝʇ ʇıun

Yeah, unit messages are stored in a different table.

Is this different than T5822?