Some ideas here:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

If I have to write code and drop it into my local install to reproduce the issue, it's custom development and it's not supported. The documentation may be incorrect, but like a prototype, it's not intended to be ready for end-user use (only internal developers).

I did not ask for support in third party development.

See T5447 for more details on the state of app development,

Damn man you're good.

We don't support third party app development.

Run your-package-manager install php-xml or php5-xml or php7-xml or whatever it's called on your system.

Relatedly: it would be nice if milestones copied the settings of previous milestones, sort of a pseudo template behavior, where milestone2 copied the defaults from milestone1 automatically (so that if you set a series to default to the workboard, every newly created milestone would share that setting unless you override the default)

Personally I'm using milestones to represent releases and the workboard is the farthest thing from what I'd want to show when clicking on the milestone.

Thanks asherkin! I was looking for it!

I saw the issues about windows being generally broken. I sympathize with the team's plight having been there too many times with cygwin and git bash over the years. FWIW I think the best approach is to normalize the path references back to unix format as fast as possible. The approach of mapping driver letters C:\ D:\ to /c and /d etc is reasonable. Beyond that there is the usual handling of spaces and () {} etc to consider where php/bash might get confused.

So I managed to resolve this eventually. It looks like the underlying cause of all the problems was that the SSH daemon on the build server itself had got into a weird state where it would accept connections, but not initiate an actual SSH session.

So I manually set the resource to a destroyed status, cleared out drydock_command and saw Drydock attempt to start allocating a new resource. However, now I'm getting:

@epriestley no i dont have any relationship with core Sandstorm, I'm a user and a fan of both apps. I'm just a student who wants to make life easier for the end user , and you create as much repercussion about it, I want to help phabricator and all other tools that I believe I send this text.

I followed up on this in #sandstorm on Freenode but this isn't officially sanctioned as far as anyone there knew. They're not particularly happy about this either, but obviously there's little anyone can do about users going vigilante with evangelism.

Oh, you've just been spamming tons and tons and tons of projects with the same message:

I noticed you posted the exact same message that you posted here to Drupal, with the same spelling error of "Oasis":

@chad yes, and want to help who don't know how to deploy Phabricator to use Phabricator and Sandstorm is perfect to that.

@MatheusVieira are you asking us to support it because you're a Phabricator user?

Link to the Sandstorm Vagrant SPK documentation - https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/

Ok, but nowhere in your first message did you mention Phabricator. It looks like cut and paste spam to me.

No not a mistake, i think that Phabricator could be on Sandstorm Market.

Did you post here by mistake? This doesn't look intended for us.

Custom domains probably need a way to link to an alternate root (e.g., the main company site).

The major custom domain issue is that there's no way to specify a protocol (HTTP vs HTTPS) or port (although this is less important). In particular, http://blog.phacility.com/ works and is the default live URI for that blog, but we would prefer https://blog.phacility.com/ to be the default URI and for http to redirect to https.

@epriestley Any of what's left reasonable for me to accomplish? Or are they all super technical?

I saved "Ignore Conflict" here and on phabricator.wikimedia.org , but a few hours later the warning message overlay has reappeared. Im going to ignore it here, so that the devs can see when I last saved "Ignore Conflict".

Hit by this again on a trip to a nearby country. Can the "Ignore Conflict" option be moved out of the list so the user doesnt have to click "Save Timezone" to in fact register they want no change. I instinctively want to hit the Cancel button on this popup/overlay, as I dont want to change my timezone. I just want the message to stop.

If you're trying to create projects here, you don't have permission. This is the Phabricator upstream (for building Phabricator). It's not a test install.

I don't know who this task is intended for. Are you looking for a different Phabricator install perhaps?

Awesome response, also fair that this won't be primary functionality. I feel our case is extremely edge due to poor environmental composition, which phabricator shouldn't be attempting to solve for us.

This is sort of exceptionally stupid and probably fairly broken until T10769 is further along, but we have a cluster read-only mode now (used when the master database is lost in a cluster configuration). Rather than using it as a disaster recovery / availability mechanism, you could force users into read-only mode explicitly, by doing something like this:

Might not be a strong use case, but we stumbled on this while talking internally about it. In our environment we've got many developers using phabricator, and an external 'manager' that basically just wants to see activity, but none of the developers want that manger to have direct interaction with their objects.

I just encountered the same problem and this solution worked for me as well. Thanks @DheerendraRathor !

In T4631#181162, @epriestley wrote:

you'll need to figure out how to get users to upgrade arc on your own until T5055.

It's probably the correct solution to create ancestor slugs automatically if you so choose. I believe this is what you're running in to?

After D16145, Harbormaster should immediately release resources which no remaining (running or queued) build step takes as an input.

Ah sorry for the confusion. I was trying to keep up to date on the weekly updates and didn't realize this flow had changed. I'll look at upgrading in the following week or two.

There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

there's no way to change "Edit Policy" from the initial form page

Is that not the same thing as "Editable By" during repository creation?

It's also insanely trivial to allow empty pages too though.

I'm hesitant to pursue any feature that really just serves as a temporary band-aid for one install. It's probably the correct solution to create ancestor slugs automatically if you so choose.

This would work now, except that there's no way to change "Edit Policy" from the initial form page.

Nevermind I am wrong. Anyways, @epriestley can explain policies better. I think this is correct on our side.

Our corporate wiki is around 400 documents at the moment, around 15-20% of the documents are rather folders and me or our team members are adding a few new documents per week.
I understand second paragraph is not very easy to do, but first I guess is easy. Is there any reason to make the body for documents obligatory? Why the body can't be just an empty string if the person, who created the document wants so?

If I set "Can Edit" to Noone and "Can Create" to Admins, I can create repositories. But this is current Phabricator.

Yea I'm really sorry about March 4th. I'll probably look at upgrading in the following weeks. I slowed down updating because of the new UI layout to differential revisions which I thought would upset some people, needed to wait for warmer weather, etc. :x)

Anyways... this sounds correct. Why should a user be able to create something they can't edit?

March 4th?

Are customizing styles and retaining the Phabricator brand altogether mutually exclusive?

Specifically CelerityPostprocessor will let you globally change probably 99% of colors, backgrounds, and fonts. Then your local users can either select the built in default or the optional one you just built.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.
Form -> Header Color #______
Phabricator CSS -> .header_color { color: YOURCOLORFROMFORM};

I can't reproduce this on your linked install.

Nope. We don't add padding to the outer container, it's handled on an object by object basis.

T10433?

I feel like he should be "N + 1 Raccoon" instead of "No 1 Raccoon"

Yes, this was implemented in T10694.

I'll comment on the remainder later.