[go: up one dir, main page]

Page MenuHomePhabricator

Phacility (Maintainer of Phabricator) is winding down. Upstream support ending.
Closed, ResolvedPublic

Assigned To
Authored By
Matthewrbowker
May 29 2021, 11:01 PM
Referenced Files
F34475108: image.png
May 30 2021, 7:03 AM
Tokens
"Heartbreak" token, awarded by Ash_Crow."Heartbreak" token, awarded by Vukky."Heartbreak" token, awarded by Don-vip."Heartbreak" token, awarded by Inductiveload."Heartbreak" token, awarded by Niharika."Pterodactyl" token, awarded by FriedrickMILBarbarossa."Heartbreak" token, awarded by YavBav09."Heartbreak" token, awarded by Trizek-WMF."Heartbreak" token, awarded by IKhitron."Heartbreak" token, awarded by Tacsipacsi."Heartbreak" token, awarded by Cyberpower678."Heartbreak" token, awarded by Universal_Omega."Stroopwafel" token, awarded by Sario528."Heartbreak" token, awarded by RhinosF1."Heartbreak" token, awarded by ArielGlenn."Heartbreak" token, awarded by Legoktm."Heartbreak" token, awarded by MusikAnimal."Heartbreak" token, awarded by TheDJ."Meh!" token, awarded by zeljkofilipin."Heartbreak" token, awarded by tobiaswiese."Heartbreak" token, awarded by kostajh."Heartbreak" token, awarded by Ladsgroup."Burninate" token, awarded by AikoChou."Burninate" token, awarded by hashar."Heartbreak" token, awarded by valerio.bozzolan."Heartbreak" token, awarded by IN."Heartbreak" token, awarded by thcipriani."Heartbreak" token, awarded by MarcoAurelio."Heartbreak" token, awarded by Asartea."Heartbreak" token, awarded by Isochrone."Heartbreak" token, awarded by stjn."Heartbreak" token, awarded by Premeditated."Heartbreak" token, awarded by xSavitar."Heartbreak" token, awarded by Daimona."Heartbreak" token, awarded by Chlod."Heartbreak" token, awarded by Pcoombe."Heartbreak" token, awarded by MGChecker."Heartbreak" token, awarded by matej_suchanek."Heartbreak" token, awarded by Mainframe98."Heartbreak" token, awarded by simnalamburt."Heartbreak" token, awarded by Frostly."Heartbreak" token, awarded by Kaartic."Heartbreak" token, awarded by Soda."Heartbreak" token, awarded by Marostegui."Heartbreak" token, awarded by Zppix."Heartbreak" token, awarded by Rubin16."Heartbreak" token, awarded by TheSandDoctor."Heartbreak" token, awarded by Hydriz."Pirate Logo" token, awarded by CptViraj."Heartbreak" token, awarded by Ebe123."The World Burns" token, awarded by Jayprakash12345."The World Burns" token, awarded by DLynch."Heartbreak" token, awarded by Kizule."Heartbreak" token, awarded by Lens0021."Heartbreak" token, awarded by Izno."The World Burns" token, awarded by Krenair."Heartbreak" token, awarded by stwalkerster."Heartbreak" token, awarded by AntiCompositeNumber.

Description

Phacility is closing operations and has declared Phabricator EOL. It sounds like Phabricator will be maintained for a while, but it might be wise to have a task about this development.

Email statement from WMF Director of Engineering:

References:

Let's please not discuss random pieces of other software here. This isn't particularly helpful.
A single ticket in some issue tracker with no conversation threading etc. is not suited for having such a complex discussion.
See https://www.mediawiki.org/wiki/Project_management_tools/Review and stuff. (quote cut down for clarity)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I propose we keep this task open for a week or so to let people land tokens of appreciation to Phabricator / Phacility @epriestley (creator of Phabricator and founder of Phacility) and then close it. Surely we would have a project / working group to discuss about the future.

I'd appreciate if this does not happen behind closed doors but at some place where volunteers can read along and give input.

Definitely. My 2c: perhaps a community maintained fork would be better? Presumably migration would be easier and it would ease the pressure on existing power users for migration.

Much love to @epriestley for starting this project, helping us move to it, and incorporating our feedback and contributions. In my opinion, moving to Phab was the best decision we've made in the almost 9 years I've been here. Thank you, @epriestley, for your part in that.

I also want to appreciate @epriestley for all that he's done over the years.

I have really, really enjoyed using Phabricator here. I assume that we will eventually migrate to another task management solution, but I'm a bit nervous about it since I think it will be hard to find something as good. That's a testament to Phabricator's quality and strong vision. Thanks for the years we shared 🤝

Phabricator is a great piece of software and while it's unfortunate that Phalicity, Inc. is closing, it does not mean the end of Phabricator, nor should it. That's the true marvel of free and open source software.

+1

There are already several companies and open source projects maintaining their own Phabricator forks. I've been maintaining Wikimedia's fork for 6 years and I've been an upstream contributor even before I worked for Wikimedia. I wouldn't be surprised if other organizations or individuals are interested in collaborating on a shared, community-maintained fork. Even without development of a new upstream, Wikimedia's fork is currently maintained and doesn't need an upstream to continue in a stable state for quite some time.

Can you share a bit about how much Wikimedia's install is forked from upstream? Are most other installs also forks or vanilla Phabricator?

I'm currently running (as of this week) wiki media's phab fork on an install without issues

Can you share a bit about how much Wikimedia's install is forked from upstream?

https://www.mediawiki.org/wiki/Phabricator/Code (in theory)

It's fairly minimal, quite a few small changes and a couple of fairly large ones. Some of the changes became obsolete by upstream eventually fixing things or otherwise changing the code such that the local patch didn't make sense anymore. Overall I think the difference in the code base is very small.

mmodell renamed this task from Phabricator has been declared EOL to Phacility (Maintainer of Phabricator) is winding down. Upstream support ending..Jun 2 2021, 6:27 AM

Sounds like it's time to create one if one doesn't yet exist, then.

As a MediaWiki user, I would not be happy if WMF's developers move to phab project, because phab is a project as large as MediaWiki (or larger than) and the resources are limited always. In my sight, there are not enough things which are shareable betweet mediawiki and phab. If it becomes inevitable, the features not used in this phab instance should be removed in the fork, for example, code review.

I wonder if there is another organization (Linux Foundation?) that Wikimedia could partner with in order to continue maintaiance and development of Phabricator?

I don't think Wikimedia have enough resource to maintain Phabricator independently.

Considering how Phabricator was maintained so far, I think that it might be possible for a small team to maintain it.

I mean for what purpose are we collecting donations if we do not do anything with it…

I wonder if there is another organization (Linux Foundation?) that Wikimedia could partner with in order to continue maintaiance and development of Phabricator?

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

As a MediaWiki user, I would not be happy if WMF's developers move to phab project, because phab is a project as large as MediaWiki (or larger than) and the resources are limited always. In my sight, there are not enough things which are shareable betweet mediawiki and phab. If it becomes inevitable, the features not used in this phab instance should be removed in the fork, for example, code review.

Don't worry, we aren't diverting any developers from MediaWiki work to instead work on Phabricator. That hasn't happened and I don't expect to see that happen.

I don't think Wikimedia have enough resource to maintain Phabricator independently.

We've been maintaining a fork for a long time now. We don't have resources to maintain the upstream project as it was but that isn't what's being proposed.

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

+1 to the name suggestion, but is there also any public documentation about this discussion and fork? I'd be interested in following along (and I'm sure others on this task would be too)

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

+1 to the name suggestion, but is there also any public documentation about this discussion and fork? I'd be interested in following along (and I'm sure others on this task would be too)

https://discourse.phabricator-community.org/t/ongoing-communications-fork-etc/4836/2

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

(The Phork Phoundation. [Terrible for SEO but too attractive to pass up.] Even phork.org sounds cool.)

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name. I hope that Wikimedia will be a part of that effort, at least by sponsoring some of my time towards it, however, I intend to contribute in a personal capacity as much as I can.

Please name it Phork. Please name it Phork.

(The Phork Phoundation. [Terrible for SEO but too attractive to pass up.] Even phork.org sounds cool.)

Yup, Phork sounds cool

Several of Phabricator's users and long time contributors are coming together to fork phabricator, with @epriestley's blessing and under a new name.

Nice to do it in a coordinated fashion, but why a new name? Can't the trademark and other assets be transferred to a suitable entity, for instance the Apache Foundation or SPI Inc. or whatever, so that it can be continued with less disruption?

Nice to do it in a coordinated fashion, but why a new name? Can't the trademark and other assets be transferred to a suitable entity, for instance the Apache Foundation or SPI Inc. or whatever, so that it can be continued with less disruption?

Apparently Evan isn't ready to abandon Phabricator entirely, he's just stopping paid support and focusing his attention on other endeavors. I've been assured that the upstream will continue to exist with irregular updates at his discretion. Trusted committers (such as myself) will be able to merge minor patches, e.g. security patches & small/non-disruptive fixes.

Some of the discussions that have been ongoing are summarized in this summary/chatlog:

1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2!!! !!!
3!!! Unless someone asks, I won't bother updating this anymore, as it has been superseded by !!!
4!!! https://docs.google.com/document/d/1YxQ_JGdhWYPSdoaI_m1TLzwbGLZdtOD7ux2SVL263Ow/ !!!
5!!! !!!
6!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
7
8
9Based on conversations in ircs://irc.libera.chat:6697/#phabricator
10Last updated at 2021-06-04T04:26:49+00:00
11
12
13= Summary
14
15* Evan Priestley (@epriestley) will no longer actively maintain Phabricator.
16* Security issues will continue to be addressed, so !!self-hosted installs can continue as before!!.
17* The [upstream version](https://secure.phabricator.com/) will continue to conditionally accept patches for some time.
18* Features cannot be requested, but will occasionally be added by @epriestley to the upstream version.
19* At this point, it's not obvious how a fork to continue development might look.
20
21
22= Upstream maintenance
23
24The existing infrastructure will stay up, and some people other than @epriestley will have access to it:
25```
262021-06-01 09:32:44 <twentyafterfour> 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.
272021-06-01 09:34:11 <twentyafterfour> if evan is willing to host the repository in the existing upstream that wouldn't involve "forking" or renaming anything.
282021-06-01 15:01:28 <epriestley> I'm open to providing direct access to the GitHub project to reduce how critical `secure.phabricator.com` is, too.
292021-06-01 15:07:06 <epriestley> 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.
302021-06-01 20:00:37 <roguelazer> (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?
312021-06-01 20:07:00 <epriestley> For (1), about 50 people already technically have commit access, including a bunch of people in this channel (<https://secure.phabricator.com/project/members/1338/>). 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.
32```
33
34The [HackerOne bug bounty program](https://hackerone.com/phabricator) is likely to continue:
35```
362021-06-01 14:48:43 <epriestley> 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.
372021-06-01 14:50:20 <epriestley> 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.
382021-06-01 15:00:20 <epriestley> 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.
39```
40
41
42= Trademarks
43
44Phacility has [trademarks](https://phacility.com/trademarks/) for "Phabricator" and the eye logo:
45```
462021-06-01 20:08:10 <epriestley> 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.
472021-06-01 20:38:24 <roguelazer> 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.
482021-06-01 20:39:46 <epriestley> It's just "Phabricator" (and "Phacility"), which Phacility has a trademark registration for and some historical contractual obligations around.
492021-06-01 20:41:59 <epriestley> 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.
502021-06-03 16:56:06 <cburroughs> 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.
512021-06-03 17:07:10 <epriestley> 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.
52```
53
54
55= Plans for future development
56
57The current state of affairs is probably sufficient for most users:
58```
592021-06-01 19:03:15 <twentyafterfour> 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.
60```
61
62Despite this, it might be nice to fix up some components:
63```
642021-06-01 08:29:49 <twentyafterfour> From my perspective, a few things that I think need attention:
652021-06-01 08:29:54 <twentyafterfour> Conduit apis - there are a few missing pieces of data that make the apis significantly less useful than they would be otherwise.
662021-06-01 08:31:19 <twentyafterfour> 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.
672021-06-01 08:33:28 <twentyafterfour> 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.
68```
69
70However, overall, no low-hanging fruit remains on the original roadmap:
71```
722021-06-01 05:43:06 <epriestley> 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
732021-06-01 05:43:06 <epriestley> 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.
742021-06-01 20:01:16 <roguelazer> (2) are there people who are interested in more serious forking / ongoing changes? is there anyone who knows as much PHP as epriestley?
752021-06-01 20:11:07 <epriestley> 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.
762021-06-01 20:12:43 <epriestley> Or maybe there are a bunch of people who want to work on Phabricator full time for free, I suppose.
772021-06-01 20:14:46 <Sario> At a rough guess, how many devs do you think would be needed to maintain the current roadmap?
782021-06-01 20:17:50 <epriestley> 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.
792021-06-01 20:20:43 <epriestley> 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.
80```
81
82There are several possible routes for the future development of Phabricator (should anyone take on the challenge), but they all involve forking:
83```
842021-06-01 15:04:05 <epriestley> 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.
85```
86
87Many self-hosted installs already have their own private forks that follow upstream:
88```
892021-06-01 09:35:44 <twentyafterfour> 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.
902021-06-01 09:36:09 <twentyafterfour> We have most of our custom code in an extension repo and just a few small patches to the core
91```
92
93Some forks could be much simpler than the current version:
94```
952021-06-02 18:03:08 <epriestley> 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.
96```
97
98The problem with combining all these changes from different users into a central repository is that everybody has different needs:
99```
1002021-06-01 05:37:12 <epriestley> 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.
101```
102
103Previously, changes were guided by a single vision, so the project remained consistent:
104```
1052021-06-01 06:18:05 <epriestley> 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".
1062021-06-01 06:18:05 <epriestley> That sanity check is approximately "don't build features that aren't useful to at least two different organizations".
1072021-06-01 06:19:11 <epriestley> 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.
1082021-06-01 06:20:08 <epriestley> 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.
1092021-06-01 06:21:08 <epriestley> 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.
1102021-06-01 06:21:59 <epriestley> The original "Facebook feature" request was <https://secure.phabricator.com/T1969>, where Facebook put different service components on different coasts with a 5-minute replication lag between them.
1112021-06-01 06:27:07 <epriestley> 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.
112```
113
114It would be great if a community fork could continue this tradition, but is that feasible?

This happened in a really short time after the whole IRC debacle, why can't there be a Phabricator hosted by the Wikimedia Foundation? A big issue is also all the links to Phabricator tasks in Wikimedia archives as a lot of discussions happened on this website rather than any other.

I honestly thought that this website was already a Wikimedia website as it has "Wikimedia" in its URL. Can all past Phabricator tasks be migrated from this website onto another? The problem with being dependent on third parties is that once they fall, you fall as well. The Phabricator is VERY important to Wikimedia websites and almost all technical error documentation exists here (likely even more than on the MediaWiki website), migrating to "a native server" (thus a Wikimedia website) also means that people can receive notifications via their Wikimedia SUL accounts and we could be sure that 50 (fifty) or a hundred (100) years from now any Wikimedia links to the Phabricator will be unbroken. It's time for third party dependence to stop.

This happened in a really short time after the whole IRC debacle, why can't there be a Phabricator hosted by the Wikimedia Foundation? A big issue is also all the links to Phabricator tasks in Wikimedia archives as a lot of discussions happened on this website rather than any other.

I honestly thought that this website was already a Wikimedia website as it has "Wikimedia" in its URL. Can all past Phabricator tasks be migrated from this website onto another? The problem with being dependent on third parties is that once they fall, you fall as well. The Phabricator is VERY important to Wikimedia websites and almost all technical error documentation exists here (likely even more than on the MediaWiki website), migrating to "a native server" (thus a Wikimedia website) also means that people can receive notifications via their Wikimedia SUL accounts and we could be sure that 50 (fifty) or a hundred (100) years from now any Wikimedia links to the Phabricator will be unbroken. It's time for third party dependence to stop.

It is hosted on Wikimedia servers.

This happened in a really short time after the whole IRC debacle, why can't there be a Phabricator hosted by the Wikimedia Foundation?

We do host our own deployment of the upstream Phabricator software. The issue is not that our hosting is disappearing, it is that the founder and primary maintainer of an upstream software project has announced that they will no longer be maintaining the software.

Can all past Phabricator tasks be migrated from this website onto another?

We will certainly try when we get to that point, yes. You may or may not remember, but all of our bug tracking used to be done using Bugzilla. We migrated from Bugzilla to Phabricator in 2014 (https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla) and in the process moved all the bug reports and comments here.

It's time for third party dependence to stop.

A "not invented here is bad" attitude is fairly unhelpful in solving technical problems. Where does one stop in a journey down the stack in the name of self-control?

hashar claimed this task.

Thank you for all the tokens and friendly messages.

The suggestion, ideas, questions etc have been noticed but at this point they can't be addressed immediately and definitely not via a single task. We have acknowledged the issue and are aware of the situation. Actions, if any, will follow eventually.

I am thus closing the task, stay tuned to the usual communication channels (I guess wikitech-l ) for the future.