In T15008#278, @avivey wrote:

I think we want an Application in an Extension...

• Emails have a bunch of X-Phabricator-* headers, for configuring rules in mail clients.

I think we want an Application in an Extension...

Also won't let me push, because something thinks it's a non-fast-forward (it is, unless I'm drunk):

$ git push phorge 2abd75c162:master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 817 bytes | 408.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: +---------------------------------------------------------------+
remote: |      * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * *     |
remote: +---------------------------------------------------------------+
remote:              \
remote:               \                    ^    /^
remote:                \                  / \  // \
remote:                 \   |\___/|      /   \//  .\
remote:                  \  /V  V  \__  /    //  | \ \           *----*
remote:                    /     /  \/_/    //   |  \  \          \   |
remote:                    @___@`    \/_   //    |   \   \         \/\ \
remote:                   0/0/|       \/_ //     |    \    \         \  \
remote:               0/0/0/0/|        \///      |     \     \       |  |
remote:            0/0/0/0/0/_|_ /   (  //       |      \     _\     |  /
remote:         0/0/0/0/0/0/`/,_ _ _/  ) ; -.    |    _ _\.-~       /   /
remote:                     ,-}        _      *-.|.-~-.           .~    ~
remote:   *     \__/         `/\      /                 ~-. _ .-~      /
remote:    \____(Oo)            *.   }            {                   /
remote:    (    (..)           .----~-.\        \-`                 .~
remote:    //___\\  \ DENIED!  ///.----..<        \             _ -~
remote:   //     \\                ///-._ _ _ _ _ _ _{^ - - - - ~
remote:
remote:
remote: DANGEROUS CHANGE: The change you're attempting to push updates the branch 'master' from '51cb7a3db9e8' to '2abd75c16237', but this is not a fast-forward. Pushes which rewrite published branch history are dangerous.
remote: Dangerous change protection is enabled for this repository.
remote: Edit the repository configuration before making dangerous changes.
remote:
[2021-06-17 15:41:20] EXCEPTION: (Exception) Unable to write to logfile "/var/log/phorge/ssh.log"! at [<arcanist>/src/filesystem/PhutilDeferredLog.php:193]
arcanist(head=master, ref.master=246e604a070f), phabricator(head=master, ref.master=5e3f4e418f5c)
  #0 <#2> PhutilDeferredLog::__destruct()
  #1 phlog(Exception) called at [<arcanist>/src/filesystem/PhutilDeferredLog.php:201]
  #2 PhutilDeferredLog::write() called at [<arcanist>/src/filesystem/PhutilDeferredLog.php:155]
  #3 PhutilDeferredLog::__destruct()
[2021-06-17 15:41:20] EXCEPTION: (Exception) Unable to write to logfile "/var/log/phorge/ssh.log"! at [<arcanist>/src/filesystem/PhutilDeferredLog.php:193]
To ssh://secure.phorge.it:2222/source/phorge.git
 ! [remote rejected]       2abd75c162 -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://secure.phorge.it:2222/source/phorge.git'

There's some issue with the SSH settings here - probably file permissions?

Do we want to make this an application or an extension? I'd lean toward the latter, it might be a good one to seed our new extension library with...

also, if we want to start with something super generic, we could probably get away with just a 'p' wordmark or an icon from fontawesome.

Everyone I've emailed is busy right now, anyone else know some good designers?
@cburroughs: an open contest sounds like it could work.

• stray phabricator

Also for completeness the diff between the pre-deprecation README (from rP95662ae8f1) and the proposed version:

Spotted a leftover Phabricator

This is basically the pre-deprecation README from Phabricator, with some names changed.

./NOTICE has some legal text we might need help with.

<do-it-live.gif>

Just copying my thoughts I wrote from the zulip

IMO our landing page needs to have a summary of our vision statement or something similar that explains what this is and where it’s going, along with screenshots and links to documentation on how to install/configure.

Personally I would prefer having a separate landing page that is primarily static content as I do believe it lends to easier intro of a product (along with some credibility) - however those things are primarily to increase adoption which is not one of our current goals as well it does add overhead and isn’t critical - I wouldn’t mind holding off on that for a while. Phacility’s main website was effectively the landing page for Phabricator. I don’t think it’s still around for reference but it had most of what I described.

I do think we should consider a separate landing page as prerequisite to announcing the product on other websites. Maybe it’s not a strong enough argument but if we’re announcing in other sites then we are probably trying to increase adoption or build the community.

I think we should build it as an Aphront Application, so we can display some interesting objects from the install into the front page, as well as manage any non-static content from within the install.
Also for dogfood value.

I also think we should make this an application / extension of phorge and not try to own something different.

Sorry about the spam... I've gone ahead and made all the component projects of Phorge public. Is there anything else we need to do here?

From IRC a while back, for reference:

From IRC a while back, for reference:

Evan Priestley (and others) wrote:

[01:09] ^[: epriestley: Looking at Phabricator from just the right angle, we can see that it's actually a web application framework which comes bundled with a handful of really sophisticated example applications. In your opinion, how silly would it be to surgically separate Phabricator-the-framework from Phabricator-the-dev-suite?
[01:31] epriestley: Relatively easy-ish. You can already use Phabricator as a web framework by subclassing "PhabricatorSite", and "phacility.com" is an extension that uses Phabricator as a framework.
[01:31] epriestley: Phabricator also sort of uses itself as a framework for public blogs in Phame ("PhameBlogSite").
[01:33] epriestley: Depending on your goals and use case, some details might need to be worked out, and some behaviors might be too Phabricator-flavored and difficult or impossible to override purely in extensions today, but I suspect there aren't many of these.
[01:34] epriestley: For example, extensions can get full control of top-level exception handling behavior by subclassing "AphrontRequestExceptionHandler".
[01:35] epriestley: Previously, a larger portion of "framework" behavior was in libphutil/, while "Phabricator" behavior was in phabricator/. The theory was that if you wanted to use the framework parts, you could depend on just libphutil.
[01:36] epriestley: However, essentially no one actually did this so it just represented an additional maintenance cost and general confusion for end-users, and I merged "libphutil/" into "arcanist/" and "phabricator/" last year.
[01:37] epriestley: The layers are still (for the most part) logically separate, they just live in the same repository now.
[01:42] epriestley: The biggest fundamental issue with thinking of Phabricator as a generic web application framework (internally, "Aphront") is probably that a lot of behavior depends on "PhabricatorUser $viewer", and "PhabricatorUser" is a concrete final class with a fair amount of Phabricator-specific behavior (it depends on the Lisk storage layer, etc). Decoupling that into "ViewerInterface $viewer" and making "PhabricatorUser
[01:42] epriestley: implements ViewerInterface" or similar could separate the layers, but that's probably a very messy change.
[01:46] epriestley: But it's also unnecessary if you're okay with using Phabricator's "system" applications (Auth, daemons, mail, etc) and just building your own user-facing applications. "admin.phacility.com" is a Phabricator application running on Phabricator-as-an-application-framework, using Phabricator auth and infrastructure but with none of the normal applications installed. If you install an app that provides a route for "/" and
[01:46] epriestley: uninstall the upstream "Home" app, your app becomes the new landing app.
[01:47] epriestley: (See also https://secure.phabricator.com/D11753.)

In general, the Welcome message stuff (And most of the concerns I outlined in T15003#216) will be taken care of in a new root / webpage(s) that will live at phorge.it and/or www.phorge.it - See T15000#234 for some background discussion

Just to keep this here for posterity

Looks like we.phorge.it is the winner coming out of that, with a static site hosted at the apex

In T15000#231, @Ekubischta wrote:

my vote would be phorge.it - simpler, easier to market, easier to say and easier to link to. - You could auto-redirect various common www., secure. etc.

my vote would be phorge.it - simpler, easier to market, easier to say and easier to link to. - You could auto-redirect various common www., secure. etc.

+1 for demo instance! - Phorge Playground or something like that

I like the demo instance idea...

Another idea here: Why don't we create a demo instance with all of the defaults? Like, half a dozen sample tasks, some sample repositories, allow users to mess around with it, and wipe it every hour back to a default database. I've seen that in multiple open source projects.

I don’t think it has really started yet. I had some changes on GitHub which I’ve abandoned but I think those changes were copied into the install here.

Reopening, we're not done yet.

• move hostname to https://phorge.it

Or did we decide against it? Do we want to keep it secure.?

In T15000#219, @chris wrote:

Fixed for real this time. I had an error in the sudoers file. Thought the webserver was running under a different user. But just cloned rARC with its HTTPS URI successfully, so should be hunky dory now hopefully.

Is this happening on rP, or on github somewhere?

Fixed for real this time. I had an error in the sudoers file. Thought the webserver was running under a different user. But just cloned rARC with its HTTPS URI successfully, so should be hunky dory now hopefully.

The logged out dashboard is already different from the logged-in default dashboard:

In T15000#211, @chris wrote:

Good catch, thanks!

no problem! Trying to put together a Docker/devcontainer based dev environment to make it easy for potential contributors.

Edit: resolved

So - If I am a brand new user that comes across this main Phorge page

No need to apologize, i wasn't super clear myself, so let me try to make my point in a more cogent manner. The main thing that bothered me with what happen is that our default should be to use the phorge's default (that I happen to find good myself, but it is not super relevant to the point). This comes down to dogfooding. The default configuration is what we are going to put into people's hand. We must ensure this is as good as possible for as many users as possible right out of the bat. This will never happen if the standard phorge install doesn't use the default, because what's out of sight also typically is out of mind.