Change Details

=== Context As discussed in the phorge [[ /w/planning_meetings/april_19%2C_2022/ | april 19 2022 meeting ]] and with much history recorded in [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] : === The Problem Arcanist is a significant barrier to adoption for many potential Phabricator and thus Phorge users. === The sad story of almost adopting Differential at the Wikimedia Foundation Some thoughts from @20after4. This is a very sore subject for me personally, however, I'm trying to overcome my bitterness for the greater good. I'm trying to convey a rough outline of the issues I came up against during my very difficult and years-long battle against the Arcanist haters which ultimately ended with me leaving the Wikimedia foundation just as they are adopting Gitlab to replace Gerrit for code review. This comes more than 7 years after a public decision making process concluded with the decision to adopt Phabricator and I, a new Wikimedia employee, set out to make it happen. The original plan was to start by adopting Maniphest in place of Bugzilla. Differential was to follow once the Bugzilla migration was completed. This never happened. The migration to Differential was ultimately hamstrung by a significant push-back against Arcanist and a widespread view (among at least a large minority of existing staff) that a pure git workflow was vastly superior. So much so that, at least in the minds of many influential Wikimedia developers, Phabricator was seen as completely unfit to replace Gerrit. Ultimately the project died and I went on to work on other things, spirit crushed, burned out and disillusioned. I never really recovered. Ultimately I tried and failed to win people over to the benefits that Differential has to offer. This is despite the fact that Gerrit and Phabricator share a nearly identical workflow. I believe that the major sticking point was Arcanist which is slightly baffling since Wikimedia user's typically use `git review` to interact with Gerrit. `git review` is a client side tool which is conceptually and superficially similar to Arcanist, just much simpler and providing much less functionality. The important distinction however, is that gerrit does not require `git review`, it's purely optional and really just provides a few CLI shortcuts for interfacing with gerrit. Seemingly the other major advantage is that git review isn't written in PHP. I guess what I'm trying to say is that some people really hate PHP and will avoid it at all costs. I am a long time user of gerrit and a believer in Phabricator's superiority in nearly every important measure. Nonetheless, I will still concede that gerrit's git interface is pretty nice to use and vastly easier to get started as compared to installing Arcanist and learning the nuances of `arc diff`. With gerrit it's rather pleasant to push a change even without using `git review` to do so. A developer can mostly treat gerrit as just another `git remote` that happens to use an unconventional naming convention for remote refs: All it takes to submit a new code review to gerrit is this incantation: `git push gerrit-server HEAD:refs/for/{branch-name}` After which, gerrit creates a new revision for review as a diff against the branch named by `{branch-name}` in the fictitious ref named by the push. It's slightly ugly but conceptually it's fairly clean and it just works. Everything else about gerrit is pretty much one disaster after another but the interface between the git client and the gerrit server is pretty decent. So with all that baggage out of the way, a bit more commentary and hopefully some opportunities for progress: From what I've gathered, Wikimedia folks weren't the only ones who had an allergic reaction to Arcanist coupled with a strong preference for a "pure" git interface. A careful reading of [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] will reveal that several potential Phabricator migrations were killed by users hostile to the idea of Arcanist as a front end to their code review system. === A Phorge without client-side arcanist? That same upstream task also discusses a potential path to supporting a git-based interface to Differential, it's just a bit more than trivial to implement. It's totally tractable though and should probably be considered as one possible way forward - essentially it boils down to just running arcanist server side against a branch that is pushed to some temporary place on the server. Pretty much exactly what gerrit does if you overlook the fact that gerrit is 100% java and completely re-invents the low level details instead of using native git. There are still some advantages to running tests and Linters all on the client side for faster iteration instead of pushing and waiting for the remote CI system to spit back errors at you asynchronously. I don't peronally think that we should kill `arc` so much as maybe offer an alternative `arc`-free mode of operation. === An outline of the problems with Arcanist the constellation of somewhat-related barriers to adoption of Phorge in 2022: 1. The need to install something client side in order to have a reasonable code review interface is off-putting to many people. 1. A lot of people seem to especially dislike that it is a PHP application. 1. Windows support is second-class for various reasons. 1. This could likely be partially alleviated if Arcanist were to be written in GO, however, that's a huge undertaking and only a partial solution. 1. There is a pretty compelling argument to be made for the way which gerrit works with git. It's really not far of in practice from the Phabricator workflow, however, `git push origin HEAD:refs/for/main` is pretty elegant and requires no custom client side stuff. 1. It seems that the pull request workflow, specifically the GitHub & Gitlab implementations of it, have overwhelmingly won out in the minds of the vast majority of younger developers. 1. The war may have already been lost, however, I still believe there is value in [[ https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ | write, review, merge, publish ]]. 1. Phorge might be doomed to obscurity unless we address the on-boarding friction and general confusion that someone experiences when attempting to use the Phorge workflow after coming from a GitHub-dominated world. 1. The mental models are different enough that Phorge can be very confusing and counter-intuitive to someone who has only ever experienced a PR-based code review process. 1. This results in an initial hostility towards the tool and many wind up hating the tool and never getting over the learning curve to appreciate the benefits that Phorge can offer.

=== Context As discussed in the phorge [[ /w/planning_meetings/april_19%2C_2022/ | april 19 2022 meeting ]] and with much history recorded in [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] : === The Problem Arcanist is a significant barrier to adoption for many potential Phabricator and thus Phorge users. === The sad story of almost adopting Differential at the Wikimedia Foundation Some thoughts from @20after4. This is a very sore subject for me personally, however, I'm trying to overcome my bitterness for the greater good. I'm trying to convey a rough outline of the issues I came up against during my very difficult and years-long battle against the Arcanist haters which ultimately ended with me leaving the Wikimedia foundation just as they are adopting Gitlab to replace Gerrit for code review. This comes more than 7 years after a public decision making process concluded with the decision to adopt Phabricator and I, a new Wikimedia employee, set out to make it happen. The original plan was to start by adopting Maniphest in place of Bugzilla. Differential was to follow once the Bugzilla migration was completed. This never happened. The migration to Differential was ultimately hamstrung by a significant push-back against Arcanist and a widespread view (among at least a large minority of existing staff) that a pure git workflow was vastly superior. So much so that, at least in the minds of many influential Wikimedia developers, Phabricator was seen as completely unfit to replace Gerrit. Ultimately the project died and I went on to work on other things, spirit crushed, burned out and disillusioned. I never really recovered. Ultimately I tried and failed to win people over to the benefits that Differential has to offer. This is despite the fact that Gerrit and Phabricator share a nearly identical workflow. I believe that the major sticking point was Arcanist which is slightly baffling since Wikimedia user's typically use `git review` to interact with Gerrit. `git review` is a client side tool which is conceptually and superficially similar to Arcanist, just much simpler and providing much less functionality. The important distinction however, is that gerrit does not require `git review`, it's purely optional and really just provides a few CLI shortcuts for interfacing with gerrit. Seemingly the other major advantage is that git review isn't written in PHP. I guess what I'm trying to say is that some people really hate PHP and will avoid it at all costs. I am a long time user of gerrit and a believer in Phabricator's superiority in nearly every important measure. Nonetheless, I will still concede that gerrit's git interface is pretty nice to use and vastly easier to get started as compared to installing Arcanist and learning the nuances of `arc diff`. With gerrit it's rather pleasant to push a change even without using `git review` to do so. A developer can mostly treat gerrit as just another `git remote` that happens to use an unconventional naming convention for remote refs: All it takes to submit a new code review to gerrit is this incantation: `git push gerrit-server HEAD:refs/for/{branch-name}` After which, gerrit creates a new revision for review as a diff against the branch named by `{branch-name}` in the fictitious ref named by the push. It's slightly ugly but conceptually it's fairly clean and it just works. Everything else about gerrit is pretty much one disaster after another but the interface between the git client and the gerrit server is pretty decent. So with all that baggage out of the way, a bit more commentary and hopefully some opportunities for progress: From what I've gathered, Wikimedia folks weren't the only ones who had an allergic reaction to Arcanist coupled with a strong preference for a "pure" git interface. A careful reading of [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] will reveal that several potential Phabricator migrations were killed by users hostile to the idea of Arcanist as a front end to their code review system. === A Phorge without client-side arcanist? That same upstream task also discusses a potential path to supporting a git-based interface to Differential, it's just a bit more than trivial to implement. It's totally tractable though and should probably be considered as one possible way forward - essentially it boils down to just running arcanist server side against a branch that is pushed to some temporary place on the server. Pretty much exactly what gerrit does if you overlook the fact that gerrit is 100% java and completely re-invents the low level details instead of using native git. There are still some advantages to running tests and Linters all on the client side for faster iteration instead of pushing and waiting for the remote CI system to spit back errors at you asynchronously. I don't peronally think that we should kill `arc` so much as maybe offer an alternative `arc`-free mode of operation. === An outline of the problems with Arcanist the constellation of somewhat-related barriers to adoption of Phorge in 2022: 1. The need to install something client side in order to have a reasonable code review interface is off-putting to many people. 1. A lot of people seem to especially dislike that it is a PHP application. 1. Windows support is second-class for various reasons. 1. This could likely be partially alleviated if Arcanist were to be written in GO, however, that's a huge undertaking and only a partial solution. 1. There is a pretty compelling argument to be made for the way which gerrit works with git. It's really not very different from the Phabricator workflow, however, `git push origin HEAD:refs/for/main` is fairly straightforward, nearly elegant even, using only the standard git client tools with no further dependencies. 1. It seems that the pull request workflow, specifically the GitHub & Gitlab implementations of it, have almost completely won in the minds of the vast majority of younger developers. 1. The war may have already been lost, however, I still believe there is value in [[ https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ | write, review, merge, publish ]]. 1. Phorge might be doomed to obscurity if we fail to address the on-boarding friction and general confusion that new users experience when learning the Phorge workflow with expectations set by their git(hub/lab) prior experience. 1. The mental models are different enough that Phorge can be very confusing and counter-intuitive to someone who has only ever experienced a PR-based code review process. 1. This results in an initial hostility towards the tool and many wind up hating the tool and never getting over the learning curve to appreciate the benefits that Phorge can offer.

=== Context As discussed in the phorge [[ /w/planning_meetings/april_19%2C_2022/ | april 19 2022 meeting ]] and with much history recorded in [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] : === The Problem Arcanist is a significant barrier to adoption for many potential Phabricator and thus Phorge users. === The sad story of almost adopting Differential at the Wikimedia Foundation Some thoughts from @20after4. This is a very sore subject for me personally, however, I'm trying to overcome my bitterness for the greater good. I'm trying to convey a rough outline of the issues I came up against during my very difficult and years-long battle against the Arcanist haters which ultimately ended with me leaving the Wikimedia foundation just as they are adopting Gitlab to replace Gerrit for code review. This comes more than 7 years after a public decision making process concluded with the decision to adopt Phabricator and I, a new Wikimedia employee, set out to make it happen. The original plan was to start by adopting Maniphest in place of Bugzilla. Differential was to follow once the Bugzilla migration was completed. This never happened. The migration to Differential was ultimately hamstrung by a significant push-back against Arcanist and a widespread view (among at least a large minority of existing staff) that a pure git workflow was vastly superior. So much so that, at least in the minds of many influential Wikimedia developers, Phabricator was seen as completely unfit to replace Gerrit. Ultimately the project died and I went on to work on other things, spirit crushed, burned out and disillusioned. I never really recovered. Ultimately I tried and failed to win people over to the benefits that Differential has to offer. This is despite the fact that Gerrit and Phabricator share a nearly identical workflow. I believe that the major sticking point was Arcanist which is slightly baffling since Wikimedia user's typically use `git review` to interact with Gerrit. `git review` is a client side tool which is conceptually and superficially similar to Arcanist, just much simpler and providing much less functionality. The important distinction however, is that gerrit does not require `git review`, it's purely optional and really just provides a few CLI shortcuts for interfacing with gerrit. Seemingly the other major advantage is that git review isn't written in PHP. I guess what I'm trying to say is that some people really hate PHP and will avoid it at all costs. I am a long time user of gerrit and a believer in Phabricator's superiority in nearly every important measure. Nonetheless, I will still concede that gerrit's git interface is pretty nice to use and vastly easier to get started as compared to installing Arcanist and learning the nuances of `arc diff`. With gerrit it's rather pleasant to push a change even without using `git review` to do so. A developer can mostly treat gerrit as just another `git remote` that happens to use an unconventional naming convention for remote refs: All it takes to submit a new code review to gerrit is this incantation: `git push gerrit-server HEAD:refs/for/{branch-name}` After which, gerrit creates a new revision for review as a diff against the branch named by `{branch-name}` in the fictitious ref named by the push. It's slightly ugly but conceptually it's fairly clean and it just works. Everything else about gerrit is pretty much one disaster after another but the interface between the git client and the gerrit server is pretty decent. So with all that baggage out of the way, a bit more commentary and hopefully some opportunities for progress: From what I've gathered, Wikimedia folks weren't the only ones who had an allergic reaction to Arcanist coupled with a strong preference for a "pure" git interface. A careful reading of [[ https://secure.phabricator.com/T5000 | Phabricator T5000 ]] will reveal that several potential Phabricator migrations were killed by users hostile to the idea of Arcanist as a front end to their code review system. === A Phorge without client-side arcanist? That same upstream task also discusses a potential path to supporting a git-based interface to Differential, it's just a bit more than trivial to implement. It's totally tractable though and should probably be considered as one possible way forward - essentially it boils down to just running arcanist server side against a branch that is pushed to some temporary place on the server. Pretty much exactly what gerrit does if you overlook the fact that gerrit is 100% java and completely re-invents the low level details instead of using native git. There are still some advantages to running tests and Linters all on the client side for faster iteration instead of pushing and waiting for the remote CI system to spit back errors at you asynchronously. I don't peronally think that we should kill `arc` so much as maybe offer an alternative `arc`-free mode of operation. === An outline of the problems with Arcanist the constellation of somewhat-related barriers to adoption of Phorge in 2022: 1. The need to install something client side in order to have a reasonable code review interface is off-putting to many people. 1. A lot of people seem to especially dislike that it is a PHP application. 1. Windows support is second-class for various reasons. 1. This could likely be partially alleviated if Arcanist were to be written in GO, however, that's a huge undertaking and only a partial solution. 1. There is a pretty compelling argument to be made for the way which gerrit works with git. It's really not far of in practicevery different from the Phabricator workflow, however, `git push origin HEAD:refs/for/main` is fairly straightforward, nearly elegant even, `git push origin HEAD:refs/for/main` is pretty elegant and requiresusing only the standard git client tools with no custom client side stufffurther dependencies. 1. It seems that the pull request workflow, specifically the GitHub & Gitlab implementations of it, have overwhelmingalmost completely won out in the minds of the vast majority of younger developers. 1. The war may have already been lost, however, I still believe there is value in [[ https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/ | write, review, merge, publish ]]. 1. Phorge might be doomed to obscurity unless weif we fail to address the on-boarding friction and general confusion that someonenew users experiences when attempting to uselearning the Phorge workflow after coming from a GitHub-dominated worldwith expectations set by their git(hub/lab) prior experience. 1. The mental models are different enough that Phorge can be very confusing and counter-intuitive to someone who has only ever experienced a PR-based code review process. 1. This results in an initial hostility towards the tool and many wind up hating the tool and never getting over the learning curve to appreciate the benefits that Phorge can offer.