I've extracted T15535: Using Differential with plain Git, without requiring Arc for the git-push-for-revision.

In T15096#11546, @avivey wrote:

Interesting.... Herald could probably start the flow, but there's still more parts needed (update vs create revision, extract summary and test plan)

Has anyone experimented with using arcanist in a docker container? I see two people have published these on dockerhub:

• https://hub.docker.com/r/nasqueron/arcanist
• https://hub.docker.com/r/adlogix/arcanist

Interesting.... Herald could probably start the flow, but there's still more parts needed (update vs create revision, extract summary and test plan), and it technically can't delete the branch (it can prevent it from being created, but that shows up as an error in the user-side).
But it should be able to at least trigger the flow and provide a URL for the user to click on.

Could this be solved with a Herald action?

I suspect there's also a problem of motivation: These things are lots of work, and the people who are capable of performing them - people who are comfortable with working with these tools - will not personally benefit from this stuff. The people who would benefit the most are people who are not involved in the project at all...

I think the current actionable steps we can take are:

I posted this in a separate thread, but it is definitely related: https://we.phorge.it/T15524

more details about arc land - https://we.phorge.it/T15364

I've got a docker-compose setup working which runs mariadb and phabricator/phorge against shared/mounted phabricator/arcanist folders to allow easy local-modifications+. The readme outlines basic steps to get running. I've tried to keep it as minimal as possible while also making sure standard/default configurations are made so you can get up and running as soon as possible. Currently it's setup with php 7.4 but I'll be looking to update to 8.1 or 8.2. There are probably other minor things that I'll need to update with it as I use it more but I think this should generally work.

Relevant links:

@ton welcome, glad to have your input here.

Having been invited to chime in from Q46 I will leave my 2 cents here:

Indeed. Thanks for cleaning. Having said that "Moving a file" is not a "specific" use-case for Subversion users. That kind of bug is an indicator that probably shows to us that this component is essentially not usable by a majority of Subversion* cases.

@valerio.bozzolan - marking all bugs in Arcanist as subtasks of this task is not helpful. This task is about discussing users not being happy about arcanist; No specific bug or specific broken use-case is actually relevant to having users not want to use it, because in almost all cases users either refuse to even try it (so they are not effected the bug).
Bugs that are found and are causing any discomfort are fixed.

In T15096#2230, @20after4 wrote:

Honestly the effort to set up arcanist isn't huge (the flow for setting up your CLI cert couldn't be more perfect and user friendly IMO) and it's all worth it because of the productivity gained by automatic lint fixes, easy patch submission and code review checkouts (arc patch is awesome!)

Checked using Incognito window, the default time is UTC and 24 hours format.

I added that sub-task since it is a bit hypocritical for us to ask why many people don't use Arcanist... if Arcanist does not support any official stable version of PHP.

@Ekubischta if you want to continue the discussion about the GitHub→Phorge bot, feel free to continue together here:

In T15096#3967, @valerio.bozzolan wrote:

One thing that could help a lot for my survival, for example, is the creation of a small bot able to convert the GitHub/GitLab flow to the Phabricator flow - automagically.

So, if I have a repository mirrored to GitHub in read-only, people can just do a pull request, and their stuff is converted to an arc diff, without any intervention from the code contributor.

I only warn that I work on it, because I need it for some personal side-projects hosted in my personal Phabricator - and where I don't want to yell at contributors who send pull requests from elsewhere.

One thing that could help a lot for my survival, for example, is the creation of a small bot able to convert the GitHub/GitLab flow to the Phabricator flow - automagically.

The concept we're aiming for is "Extension Store" - Core to be minimal,. and everything else to be an optional install, with an "app store" somewhere here, and making installing extensions easy.

Isn't it possible to open a branch for that? who decide what feature can be integrated in Phorge? Just a remark, Phrequent *is* the application for time tracking, even quite empty by now

Looks great. I implemented a rough and simple logging feature over Phrequent, your extension looks more precise. I would think its better to merge/replace Phrequent rather than adding more implementations, though

I used Docker environment forked from RedpointGames. Its now migrated on a Ubuntu base and is available on a Github repository.

I just tried it here, and it didn't require any auth. maybe something was wrong with our setup at the time?

There is a thread to translatewiki.net about adding Phorge: https://translatewiki.net/wiki/Thread:Support/Adding_Phorge_for_translation%3F.
Wikimedia must first migrate to Phorge to add it into translatewiki.net.

@avivey has fixed this on the upstream install.

In T15096#2333, @sario528 wrote:

Allowing a user to make quick simple changes with nothing but a web browser is IMO the single best way to encourage new contributors.

In T15096#2329, @avivey wrote:

For new users, support the the magic-ref style of gerrit, but with a web-UI Wizard based next steps, where we walk her through creating/updating the right revision, maybe explain what happens to all the commits and what other users will experience. Treat this as an onboarding experience - with the expectation that full-time contributors will eventually switch to Arcanist.
Maybe upsell Arcanist at this point.

I'd point out that Gerrit was originally intended to work with a client-side tool called repo (Which also manages multi-repo code trees).
The git push ... <magic ref> is kind of a workaround for users that found having a client-side tool annoying to use :)

In T15096#2233, @speck wrote:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Definitely agree that the effort to set up arcanist isn't huge. And at my current work, it's baked into our common Dev PC setup, so it's almost zero effort. But there is an effort, and a dev/user who is just passing by to fix a typo or suggest a one-line change in some code isn't going to be willing to do that effort.

@micax: Good points and it's helpful to hear another perspective on this. From my past experience using Phabricator on a corporate team I definitely think that arcanist helped keep everyone's workflow consistent and simple.

I find this rather interesting (and a little bit weird, to some extent), because IMO the arcanist command line tool is one of the things which IMO _add_ value to Phabricator and sets it apart from it's alternatives.

In T15090#2141, @avivey wrote:

In T15090#2123, @Matthew wrote:

@avivey Would it make sense to add a public announcement to Diviner or Phiction? Or perhaps we use Phame for this use case (Create a "Security Incidents" blog)? I always think of a task as an actionable item, whereas we would want this to exist forever.

Yes, probably. "Announcements"-style thing

In T15090#2123, @Matthew wrote:

In T15090#2127, @Matthew wrote:

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

I don't think having people downgrade is a good idea. I think we should probably cherry-pick Evan's fix from upstream into the phorge codebase.

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

ahh, I was wondering why my Phorge install suddenly broke - seems to be the case here too

We need to cherry-pick and import the changes Evan made into the Phorge repository as well...

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

Interestingly accessing /status on secure.phabricator.com seems to return a json object instead of ALIVE.

For GitHub, they have rolled a merge queue system which is in beta: https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ . When a pull request is approved, it is added in the queue and will be tested with all the other changes ahead in the queue which is exactly the system Zuul is using and @speck gave the link at https://zuul-ci.org/docs/zuul/latest/gating.html

Time tracking is an interesting topic. At my company we addressed this by having a Herald WebHook hit our internal server whenever activity we're interested in tracking happens. Our internal server tracks these activities from multiple sources (not just Phab/Phorge) and users can go in to see all their activity linked up and input the approximate time spent on those activities.

I'd definitely love to see this later. I MIGHT be able to get to this later.

This looks pretty great! - I think T15030 is the general covering task for Extensions

Thanks -- I'm curious as to what makes this not particularly suitable for development, though?

Came across someone else's notes about submit/merge queues - https://epage.github.io/dev/submit-queue/

I think I just set that via "Global Default": https://we.phorge.it/settings/builtin/global/

the only global config option I can find is the timezone, so either way changes to phorge core would be required. Timezone has no default value. (It's typically controlled by the php date.timezone setting)

For the case of email headers

In https://secure.phabricator.com/T13658#256009, @epriestley wrote:

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Depending on how many of these we end up with, I think an email-header-prefix sort of config option might be reasonable.

Leave the default storage namespace as phabricator

I like the idea of having an easily greppeable token...

what about egrohp? ("phorge" backwards)?

Does anyone like, not like, or have additional thoughts on the general idea of making one or more unique identifiers that isn't "phorge", for the purpose of an identifier that is unmistakably greppable? I outlined some notes on this idea here: T15006#831

The Caddyfile boils down to

Confirmed working fine in both Windows 10 and Linux Mint 20

The future plans for the domain landing page are under T15008: Build Welcome Site. I'll close this out for now since the redirect is working.

Looks like that worked I guess. I just went to phorge.it in my mobile browser and apparently redirected to we.phorge.it.

I sent @ toward 198.74.57.92 too.

Looks like @deadalnix may need to update DNS:

$ dig phorge.it
[...]
;; ANSWER SECTION:
phorge.it.              0       IN      A       217.70.184.38

versus

$ dig we.phorge.it
[...]
;; ANSWER SECTION:
we.phorge.it.           0       IN      A       198.74.57.92

Hm I tried updating the nginx configuration to do a temporary redirect to https://we.phorge.it but it doesn't seem to be functioning properly. Someone else with better nginx experience might need to lend a hand -- @Matthew maybe?

Here is a proof-of-concept for a Vagrant pattern.

I think both solutions work well

I've used both docker containers and vagrantfiles for development, though not too extensively. In my experience they're both pretty involved for something that requires multiple services running. I think vagrantfile might be a little more accessible for developers. Using docker will eventually require additional understanding of docker/docker-compose and how containers interact whereas virtual machines I think are easier to reason about. For example I think it will be very common for a developer to want to get to a command-line on the system running their phorge services. Doing so with docker requires knowing which container you want (docker container ls) and running an interactive bash (docker exec --it {id} bash). With vagrant it automatically sets up ssh (and handling keys, somehow) so you can do something like vagrant ssh and it drops you into bash on a single machine that has all services running.

In T15011#370, @willson556 wrote:

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

I want to also mention on this topic... Using a pre-packaged VirtualBox image can be a straightforward distribution route, with a drawback being filesize... Perhaps Torrents could be a neat way alternative to distribute something like that, though there would be a few options including sponsored mirrors, etc... VirtualBox is a common Vagrant provider, so oftentimes it is a prerequisite anyway...

We should consider a Vagrantfile

@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.

Caddy looks interesting - if you get it going, can you make a small instructions writeup?

Yep! I have it setup where almost everything is configured using environment variables/docker secrets. Currently the only configuration file that needs to be passed into the Phorge container is for Configuring Outbound Email since that can vary quite a bit. NGINX has a config file but the only modifications it needs are sections to be commented/uncommented if it's used for SSL termination, otherwise everything is set using environment variables. Of course NGINX could be swapped out for your web server of choice. I might look into providing a example that uses Caddy for the web server as it has native support for ACME and should be pretty easy to do.