Just tried that too, and strangely: it does.

Does it work without the --?

In T12416#215813, @epriestley wrote:

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

Does this command work on your system?

$ git ls-remote -- https://github.com/phacility/libphutil.git

I can't immediately reproduce this, although the systems I have immediate access to are all running Git 2.11.0.

Found these related diffs:
https://secure.phabricator.com/D13557
https://secure.phabricator.com/D12198
https://secure.phabricator.com/D15124

ESLinter it the best linter in the JavaScript world. Are there any plans on adding support for it in the near future?

The setsid() appears to have resolved the issue, in the sense that daemons are now starting cleanly every time without receiving any inexplicable signals.

The MySQL stuff seems to be in the old daemons (them trying to do logging while MySQL restarts), not the new daemons, and not the cause of the issue.

So our only option is to convert all our LFS objects into normal Git objects, increasing both our download times, and increasing your storage and bandwidth costs? Like our Git LFS objects for the entire repository total around 800MB, and without Git LFS, our build server will have to download that from Phacility every single time it does a build.

We have no plans to move this forward or enable it in the Phacility cluster in the near future.

Is this going to be enabled in Phacility soon? We just realised that Phacility doesn't appear to have it on, and this is a major blocker for us moving from our own instance to Phacility:

Even with a very conservative policy, we're going to drop 80% of the instances it sounds like.

Well, I think it's reasonable to possibly not log in for a while like I keep dormant projects on GH. I don't want them to disappear, but I prefer to keep them in the cloud.

We can also do other stuff like "never archive an instance with 2+ users", "after an instance emails us to unsuspend, have a flag to mark it as exempt from cleanup in the future", "don't destroy data for 365 days, instead of 90, if an instance had hosted repositories", or other sorts of things like that, but I suspect measures like that will be largely unnecessary for years to come and that "no one loaded a page for 45 days" is already a nearly perfect signal for "no one cares about this instance".

I'd say 180 day destruction window, and mostly that's just for us to feel good about deleting stuff.

Fair points.

Continuing from above, I queried a subset of instances for session counts to help us understand usage patterns for free instances (see T12217):

Picking a random shard, 80% of the active instances have zero sessions in the last 30 days -- so no user has loaded a single page in at least a month. Most (maybe all?) of these have only one account. These include (anonymized) free instances like "alsdknfasf", "test2", "test2017", "testinstance9", "testforme", "mytest", "myinstance", "bbbbbbb", "ddeemmoo". Of the 20% of active instances which do have activity in the last 30 days, many are recently-launched free instances with only one user session, and I'd guess many of those users are never coming back and these instances will join the boneyard shortly.

My thinking is that v1 would work like this:

I suppose we could get pretty far changing the language from "Disabled" to "Inactive". That is, send a warning after n days, then after 3 warnings, set it to "Inactive" but have a means they can contact us or click a button to re-activate it?

So I've read this a few times and I'm still a little unclear what happens if "activity requirement" isn't met. It sounds like we'll just disable them like we do non-paying instances - which I don't think users expect and feels like a crumby experience. Would it just be possible to "hibernate/sleep" the instance (no daemons run, user has to wait and spin them up to log back in if 90 days later they get back to using the instance)?

I'm going to put D17497 + D17498 into this release even though they don't directly tackle the issue here and I think they're slightly risky changes (mostly because git ls-remote may have odd behaviors in some cases, and we don't currently use it in other workflows). But they may help with T12296 and general cluster load issues, and the followup changes will generally be more complicated to reason about (more locking/concurrency stuff), so I think getting these in earlier spreads risk out somewhat even though they're something to watch out for in this release.

I imagine Facts will have similar workflows. The easier we can make it, the less worried I am about re-using panels.

Yep, that's what I'm thinking too.

Yeah, and the sane version (add to dashboard, not to tab panel) is probably not too awful and won't really make fixing T8033 any harder.

I want it to work like like installing to home does basically, see query, click add, confirm, get take to arrange with the panel built and added.

Yeah maybe I should optimize that workflow first, seems higher leveredged. T5307

Getting rid of all "Select Existing Panel" flows also makes simplifying the "Run a query -> turn it into a panel -> put it on a dashboard" workflow a bit more of a mess, especially if we want to try to do "run a query -> turn it into a panel -> add it to a tab panel". But I think in the long term making the T8033 problem impossible and then trying to do our best with the "query -> panel -> dashboard" flow is the best bet.

frickin' tab panels make everything 10x harder.

As long as you're selecting existing panels in any interface, we're stuck with the problem in T8033. I think we can only fix that elegantly by removing all interfaces where you select panels, and replacing them with interfaces where you create panels.

Or maybe icons... everyone loves icons.

If I add "short name" as an optional Panel field, I could get rid of naming tabs. Then you just have to select a bunch of panels.

The change I imagined there was:

If we make the permission changes discussed elsewhere (T8033, I think?), this might just become something like a containerPHID which points at a Dashboard for panels created from dashboards, another Panel for panels embedded in panels, and null for standalone panels.

Oh I see above you mention using edges too.

I don't think there is much value here in having "appears on", since panels work on dashboards, other panels, or any remarkup, anywhere. Does anyone have a good reason to keep this function? I could create an edge for panel -> panel if we want to keep something like this. But I'm concerned if the point is to "prune" panels, then we'd need to maybe build out mentions as well.

So, we prefer to not use externals, because that makes rebasing difficult.

We don't plan to support this. Large installs often have hundreds or thousands of open revisions, so "build all open revisions" would trigger hundreds or thousands of builds for every push.

Stripe's library is in externals and is not run under arc liberate.

You can use Conpherence or Ponder if you have questions about developing on Phabricator.

We are using Braintree for our payments. This is the error I get when trying to run arc liberate on Braintree SDK:

Thanks! This code has been churning recently (T12298 / T12217) and I likely broke this in D17389. I think I observed this behavior, but this report should save me a great deal of time hunting the bug down.

You can already use third-party externals that use namespaces, and we already bundle some (Twilio, Balanced until it was removed in D12074).

Specifically, we don't provide support for custom libraries or writing your own Phabricator applications, this is "at your own risk". I don't know what you're using Braintree for (Phortune?) or what problem using it solves for you. I think questions about Phabricator development are better suited for Ponder/Conpherence to get started. Plenty of other admins with experience there.

What problem or issue are you currently having with Phabricator that you expect this feature to solve. Please see Contributing Feature Requests and Describing Root Problems for what information we require from feature requests.

(You could also pipe the list into bin/remove destroy --force, equivalently.)

You can re-run the migration explicitly with:

We ran the script provided above to get an audit of at-risk files. Afterwards we upgraded our instance and the upgrade succeeded however its attempts to delete the affected files failed. The failure is due to using a local file store which is accessible to our web service account but not the phabricator phd services account (T4752). After correcting the file permissions so both accounts have appropriate access, running upgrade again doesn't seem to remove the files.

Thank you! This fixed the issue.

Thanks. D17507 should fix this, and will un-stick any tasks stuck in queue.

Thanks! D17506 isn't the most elegant possible patch, but should fix this. Let us know if you're still seeing issues after that lands.

It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.

The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.

We've started using countdowns on our dashboard as well and it's a little distracting/stressful to have that keep updating. It would be cool to have it fully customizable but the compromise plan you posted about would work well for us too.

You can adjust it if you like at https://secure.phabricator.com/source/phabricator/browse/master/src/applications/files/builtin/PhabricatorFilesComposeAvatarBuiltinFile.php;7626ec0ce10e5a9665d84622259e073744c9872d$130

This would be totally great, if our corporate username policy didn't mandate that all usernames start with the same letter 😂

That does make sense; we're using that multi-color approach for the report in the example in https://secure.phabricator.com/T12403. But we also put labels per-category, which is possible in that report because the categories are continuous over time to form ribbons, unlike this chart. For this chart, I think the mental model is that all categories are really sub-categories of the parent category "stuff we have worked on", and users only need to distinguish between high-priority and low-priority, hence the shading.

T9789 has stabilized (the majority of major transaction types now run through ModularTransactions) although it didn't end up providing much clarity here. This is no longer blocked on anything, I just need to develop a specific technical plan to resolve the "adjust" vs "expand" sequence inside transaction application so the "expand" code has access to the old text by the time it runs.

The system described in this task became "ModularTransactions", which feel like they're in a good place.

That sounds reasonable to me. We remain open to more feedback here if it does turn up, but I think we don't have a clear set of next steps otherwise. Thanks for following up!

Currently the workboard has an option for fullscreen display. However this setting is lost when the browser refreshes. Since we're using Chrome + a Chrome autorefresh extension (SuperAutoRefresh) to display a Phabricator workboard on a bigscreen TV it would be useful if this setting is persisted across refreshes. Like ?fullscreen=yes as suggested.