!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! !!! !!! Unless someone asks, I won't bother updating this anymore, as it has been superseded by !!! !!! https://docs.google.com/document/d/1YxQ_JGdhWYPSdoaI_m1TLzwbGLZdtOD7ux2SVL263Ow/ !!! !!! !!! !!! See also: https://temp-community-phab.zulipchat.com/ !!! !!! https://we.phorge.it/ !!! !!! !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Based on conversations in ircs://irc.libera.chat:6697/#phabricator Last updated at 2021-06-04T04:26:49+00:00 = Summary * Evan Priestley (@epriestley) will no longer actively maintain Phabricator. * Security issues will continue to be addressed, so !!self-hosted installs can continue as before!!. * The [upstream version](https://secure.phabricator.com/) will continue to conditionally accept patches for some time. * Features cannot be requested, but will occasionally be added by @epriestley to the upstream version. * At this point, it's not obvious how a fork to continue development might look. = Upstream maintenance The existing infrastructure will stay up, and some people other than @epriestley will have access to it: ``` 2021-06-01 09:32:44 I think I can devote a bit of time to reviewing patches and preparing maintenance releases and dealing with security patching. If we get at least two or three of us able to do that I think we'd have a sustainable situation for bare-minimum maintenance without actually evolving the product any. 2021-06-01 09:34:11 if evan is willing to host the repository in the existing upstream that wouldn't involve "forking" or renaming anything. 2021-06-01 15:01:28 I'm open to providing direct access to the GitHub project to reduce how critical `secure.phabricator.com` is, too. 2021-06-01 15:07:06 I spend very little time doing operations stuff and expect `secure` will probably continue to function for years (maybe until the credit cards on the AWS account expire?) even if I get hit by a bus tomorrow, but it's easy infrastructure to de-risk. 2021-06-01 20:00:37 (1) epriestley, are you open to giving people "maintainer" access on secure.phabricator.com? Would you prefer that any ongoing maintenance be done in forks on github, or on phabricator instances that someone else hosts? 2021-06-01 20:07:00 For (1), about 50 people already technically have commit access, including a bunch of people in this channel (). I'm open to de-risking Phabricator in the short/medium term by extending access (e.g., to HackerOne and GitHub) to a few people, so the `secure.phabricator.com` service isn't a strict technical dependency. ``` The [HackerOne bug bounty program](https://hackerone.com/phabricator) is likely to continue: ``` 2021-06-01 14:48:43 I currently plan to leave it up indefinitely. It's pretty low-volume and something like 95% of reports don't read the "mongoose" rule so they only take a few seconds to process. 2021-06-01 14:50:20 The researchers who read the "mongoose" rule are pretty much all competent and pleasant to interact with. I think I'd only be tempted to get rid of it if it became significantly more difficult to manage. 2021-06-01 15:00:20 I'm not necessarily committing to doing anything about reports, but I'd potentially be open to adding a couple of people who I trust (e.g. twentyafterfour) to the HackerOne program, at least as a short/medium term measure. ``` = Trademarks Phacility has [trademarks](https://phacility.com/trademarks/) for "Phabricator" and the eye logo: ``` 2021-06-01 20:08:10 In the longer term, I don't want any community effort or fork to use the Phabricator or Phacility names or maintain "as" Phabricator/Phacility, so if some more organized effort arises I'd encourage it to fork, rebrand, and run all of its own infrastructure. 2021-06-01 20:38:24 When you say you don't want forks to use the "phabricator" names, how far do you extend that, epriestley? I feel like if forks had to rebrand, e.g., Differential to, I dunno, Fauxerential, that would be a pretty big re-training cost for downstream users; if it's just the literal word "phabricator" that you're concerned about, that seems less invasive. 2021-06-01 20:39:46 It's just "Phabricator" (and "Phacility"), which Phacility has a trademark registration for and some historical contractual obligations around. 2021-06-01 20:41:59 I'm also conceptually fine with whitelabeling the name "Phabricator" in the upstream so a fork with a different name can differ by ~one line of configuration code, but I haven't looked at how involved that is. 2021-06-03 16:56:06 A similar question of where between "${NAME}: A Community phork of Phabricator" and "${NAME}: Tools for the World's Greatest Role Playing Game" we ought to be around the Trademark. That is can the lineage be stated directly or must be obscured. 2021-06-03 17:07:10 cburroughs: "A Fork of Phabricator" is fine, just not "Phabricator: Community Edition". As long as a reasonable user would understand that the project is a fork, it's fine to use the term "Phabricator" to describe the original project. ``` = Plans for future development The current state of affairs is probably sufficient for most users: ``` 2021-06-01 19:03:15 indeed phabricator is very stable. Not a lot has changed in the codebase for a couple of years now so it seems reasonable to conclude that it can run for quite a long time to come. Future changes to PHP could cause some issues but probably nothing too difficult to work through. ``` Despite this, it might be nice to fix up some components: ``` 2021-06-01 08:29:49 From my perspective, a few things that I think need attention: 2021-06-01 08:29:54 Conduit apis - there are a few missing pieces of data that make the apis significantly less useful than they would be otherwise. 2021-06-01 08:31:19 Forms: managing subtypes and form configurations is a nightmare when you start to have a lot of variations. This is probably a problem unique to wikimedia's use. 2021-06-01 08:33:28 Arcanist: people hate it. I think it's great but it's the one thing that I can point to as a reason that wikimedia is in the process of moving from gerrit to gitlab instead of moving from gerrit to differential several years ago. ``` However, overall, no low-hanging fruit remains on the original roadmap: ``` 2021-06-01 05:43:06 Another general issue is that I believe Phabricator has almost no flaws which are easy to fix. Since roughly the beginning of the project, if something took ~30 minutes to fix, I just fixed it. A useful change today is, for example, to modify the way push events are recorded so that repository cluster versioning can respect synthetic push events generated by maintenance operations. I don't think anyone can make this 2021-06-01 05:43:06 kind of change (or most of the other relevant changes that improve Phabricator in a sustainable, long-term way) without investing a great deal of time in becoming familiar with Phabricator's systems first. 2021-06-01 20:01:16 (2) are there people who are interested in more serious forking / ongoing changes? is there anyone who knows as much PHP as epriestley? 2021-06-01 20:11:07 I don't know about (2). I think it would be difficult to execute the Phabricator roadmap as it exists today (e.g., complete tasks described on "secure.phabricator.com") without working on Phabricator full time. But I might be wrong, or that roadmap might be less interesting than some easier roadmap. 2021-06-01 20:12:43 Or maybe there are a bunch of people who want to work on Phabricator full time for free, I suppose. 2021-06-01 20:14:46 At a rough guess, how many devs do you think would be needed to maintain the current roadmap? 2021-06-01 20:17:50 The issue is that almost nothing on the roadmap is "fix a typo"; it's mostly stuff that I think you really have to wrap your head around. It's very hard, at least for me, to sit down for an hour or two in the evening or on a weekend and make any headway on anything. 2021-06-01 20:20:43 So "one", but if they want to make any changes to, say, repositories they likely need to know Mercurial, Git, Subversion, HTTP, SSH, a bunch of Linux stuff, MySQL, the clustering engine, etc. ``` There are several possible routes for the future development of Phabricator (should anyone take on the challenge), but they all involve forking: ``` 2021-06-01 15:04:05 In the long term, I don't want to have a community effort that is publishing changes "as" Phabricator/Phacility -- so I'm not open to just giving the GitHub project to a community project -- but as long as expectations are clear I'm comfortable clearing a path for things like security fixes to be published on existing channels without my involvement. ``` Many self-hosted installs already have their own private forks that follow upstream: ``` 2021-06-01 09:35:44 Wikimedia has been very successful in keeping our fork 99% vanilla and compatible with the upstream changes so that merges have always been easy to resolve. 2021-06-01 09:36:09 We have most of our custom code in an extension repo and just a few small patches to the core ``` Some forks could be much simpler than the current version: ``` 2021-06-02 18:03:08 A fork also creates an opportunity to make the project at least slightly more manageable: you could drop Subversion and Mercurial support, drop like 5-10 applications that see very little use (e.g., Releeph is broken; Phortune is unlikely to be useful for a non-commercial maintainer). You could drop Arcanist entirely. ``` The problem with combining all these changes from different users into a central repository is that everybody has different needs: ``` 2021-06-01 05:37:12 And a sort of food-for-thought question: what customer do you want to serve? At least some casual and open source installs want features like "fix typos directly from the web UI", "push with git to create revisions / delete arc", and "bridge everything to GitHub". These features are useless (or harmful, perhaps significantly) for most installs in commercial organizations. ``` Previously, changes were guided by a single vision, so the project remained consistent: ``` 2021-06-01 06:18:05 Roughly, I've pursued features that will save professional software engineers as much time as possible, with an understanding that reducing errors and/or catching errors earlier saves time. This is difficult to measure directly. The only useful proxy function I found was features that companies would pay money for, filtered through a general common sense sanity check to avoid building a lot of "Facebook features". 2021-06-01 06:18:05 That sanity check is approximately "don't build features that aren't useful to at least two different organizations". 2021-06-01 06:19:11 That is, most users making feature requests believe that their features are very good ideas and quite valuable. You can't ask users to self-rate the importance of their feature request relative to other feature requests, or you'll just build the features requested by the most delusional users and/or the users most willing to lie. 2021-06-01 06:20:08 Way back in the day, one self-styled C-level exec believed that his feature requests were so valuable that I should pay him for his great ideas. 2021-06-01 06:21:08 And by "Facebook features", I mean features that solve a self-inflicted problem created by organizational deficiencies, and not likely to exist in other organizations and/or organizations with their act together. 2021-06-01 06:21:59 The original "Facebook feature" request was , where Facebook put different service components on different coasts with a 5-minute replication lag between them. 2021-06-01 06:27:07 These things are usually fairly obvious (the problem and/or solution are just ridiculous technically). The biggest grey area I've run into is probably around regulatory/compliance stuff, where a problem and/or solution may be ridiculous but it isn't really the organization's fault. ``` It would be great if a community fork could continue this tradition, but is that feasible?