Do you work at Facebook? If you do, we should walk through some context about Releeph. If you don't, I'd discourage trying to use Releeph until it's more mature.

Yes, I do. I'm just trying to pull together some information on our pull/pick requests for display elsewhere (like on IRC).

A very high level summary of the situation is:

• Facebook is currently running a version of Phabricator which is somewhat out of date, so even if we fix this now, stuff it won't be available until Facebook is up to date (see T4465). Last we heard things are getting updated, but we don't know exactly what the timeline is.
• In very vague terms, Releeph was committed to the upstream and then there was a lot of very sudden churn around Facebook's involvement with the Phabricator project. We eventually had some tentative direction on it and made some progress, but then the point of contact for Releeph changed, the new point of contact was traveling for about a month, and things never picked back up. Consequently, Releeph is kind of in limbo: we want to modernize it so we can support it, but don't want to do so in a way that breaks Facebook, and don't currently have anyone on the Facebook side who is involved with the project to help with that. You can see some of the changes we'd like to make to Releeph by looking for tasks tagged with the Releeph project.
• Without a way forward, it's hard to make changes like this. For example, we'd like to rename "pick requests" to "pull requests" (see T3644) and make them more powerful, so they can serve both the Facebook use case (pick one commit) and the use case that users coming from GitHub expect (pull an entire branch). Changes like this should inform the API, and we can move forward with fewer API breaks if we have a better sense of the end state.

Upshot:

• If you want to run any new code in the Phabricator upstream, at a minimum you need to figure out what the upgrade schedule at Facebook looks like and plan around that, since there's nothing we can do to deliver code to you faster than that.
• We want to modernize Releeph and fix a number of infrastructure issues (for example, T3663, T3718, T3722, T3551) before doing feature development. To do this, we need a point of contact on the Facebook side who can answer questions ("do you use feature x?", "would feature y be an acceptable substitute?") and facilitate changes ("anything hard-coding this URI should move to this instead") so we don't break you or remove features you depend on.
  • If you or someone you work with would be comfortable doing this, we can start moving this forward at any time. I don't think this will take much time -- a couple hours a week of answering questions, and some interfacing with the devtools team and any other teams building on top of Releeph. I think our earlier estimate was that we had about a month of work left on Releeph to modernize it, although I haven't touched that code in a while (and the rest of the codebase has moved forward in the meantime, which may have made things better or worse).
  • If Facebook doesn't have the bandwidth to support this, we can move Releeph forward on our own, but may break things (some changes we'd like to pursue will definitely break things, although we're not certain all that stuff is in use).
  • We'd also be happy to help if Facebook wants to pull Releeph back out of the upstream and support it internally. This is somewhat easier now than it used to be, as we've improved support for third-party applications along many dimensions in the last year.
  • Generally, we're open to talking about options here -- the current state of affairs isn't good for anyone. We have a lump of code we can't really touch, and you have a lump of code that you can't easily change.

Thanks for the detailed info, much appreciated! I agree fully on the fact that the state of limbo isn't good. I'll ping some people on this side and see if we can agree on a direction for both us and Phabricator.

Sounds good, thanks! (I'm epriestley@phacility.com if that's useful, and I'm happy to swing by Menlo Park if getting people in a room together would be easier.)