Version 1 vs 43
Version 1 vs 43
Edits
Edits
- Delete by epriestley, Version 43
- May 29 2021 9:43 PM
- Edit by epriestley, Version 1
- Jun 5 2012 8:34 PM
Edit Older Version 1... |
Content Changes
Content Changes
This document describes the Phabricator roadmap at a high level.
== User Requests
Our roadmap is dictated largely by user requests for features and bugfixes. These change day-to-day.
== Drydock (Software Resource Management)
Drydock is a "software resource management" system. It will satisfy requests like "allocate a working copy of repository X //somewhere//", and manage leases and resource reuse and destruction. Being able to satisfy this sort of request in a scalable way opens the door to many other tools.
Drydock is important because we want to build a number of tools that will face similar resource management problems: continuous integration, commit management, build tools and sandcastles all need temporary, exclusive locks on working copies. Having them check out fresh working copies for each operation is very slow, while having them share a few working copies doesn't scale. Drydock solves this problem by treating it as a resource allocation problem.
Drydock works something like this:
- Some tool needs a working copy of repository X -- to run a build step, run unit tests, host a sandcastle, or whatever else. It builds a description of the resource and asks Drydock to allocate it.
- Drydock tries to satisfy the request from the pool of existing but unallocated resources. If it can, it just issues a lease and hands the resource back to the tool. This is very fast and should be the common case.
- If it can't satisfy the request from the pool of existing resources, it figures out how much of the request it can satisfy and how much new work it needs to do. For instance, it will try to use a host which has already been allocated if it has enough system resources. If it can't find a matching host, it can allocate a new one (e.g., by bringing up a machine in EC2).
- It does the work to build the resource, then issues a lease on it to the original tool.
- When the tool is done, it releases the lease.
- Eventually, Drydock may GC the resource.
In detail, the major parts of Drydock are:
- Resources, which represent allocated software or hardware.
- Interfaces, which expose capabilities on resources (e.g., command execution, filesystem access, webserver management).
- Blueprints, which are scripts for building new resources.
Drydock is blocking a lot of other stuff right now and is a relatively high priority.
== Phacility (Phabricator SaaS)
- {T1315}
We're building a SaaS version of Phabricator. This is primarily blocked by Drydock, but also by a lot of other missing components. The goal is to offer a paid, hosted version of the software and line our pockets with tens of dollars; wealth unimaginable.
== Policy (Permissions, Roles and Privacy)
- {T603}
We're in the process of implementing object visibility policies, so you can lock objects down to certain groups of permitted viewers.
== Harbormaster (Continuous Integration)
- {T1049}
We're building a CI tool, similar to Jenkins. This is blocked almost entirely by Drydock.
== Releeph (Release Management)
Facebook is open sourcing their release management tool. Releeph helps release engineers manage which changes get picked into which releases. This is partly blocked by Drydock. This does not currently include tools to handle actual deployment of software, but may evolve that way once we get this landed.
== Notifications, Chat, Chatlog, and Webhooks
- {T974}
- {T1271}
- {T944}
- {T305}
We have a student team at Stanford working on implementing real-time notifications. These will work similarly to the notifications on Facebook, and alert you when content you're subscribed to is updated. As we integrate notifications, we plan to add more communication preferences and let users reduce the amount of email they receive, as well as export notifications through external channels.
We have a basic chat bot and a basic chat log which we want to improve, generalize, and offer more transports for (like HipChat support, and webhook support).
== Calendar
- {T407}
- {T406}
We have a very basic calendar application, which we want to improve and integrate with other tools. Notably, we planning to support user status (so when users are away on vacation, it's visible in the application), and probably things like oncall rotations and tighter integration with Maniphest eventually. Some of this exists already.
== Diviner (Documentation)
- {T988}
Phabricator uses a documentation generator called "Diviner" which we want to merge into Phabricator itself and improve support for.
== Phame (Blogging)
We're writing a blogging engine, then writing a blog.
This document describes the Phabricator roadmap at a high level.
== User Requests
Our roadmap is dictated largely by user requests for features and bugfixes. These change day-to-day.
== Drydock (Software Resource Management)
Drydock is a "software resource management" system. It will satisfy requests like "allocate a working copy of repository X //somewhere//", and manage leases and resource reuse and destruction. Being able to satisfy this sort of request in a scalable way opens the door to many other tools.
Drydock is important because we want to build a number of tools that will face similar resource management problems: continuous integration, commit management, build tools and sandcastles all need temporary, exclusive locks on working copies. Having them check out fresh working copies for each operation is very slow, while having them share a few working copies doesn't scale. Drydock solves this problem by treating it as a resource allocation problem.
Drydock works something like this:
- Some tool needs a working copy of repository X -- to run a build step, run unit tests, host a sandcastle, or whatever else. It builds a description of the resource and asks Drydock to allocate it.
- Drydock tries to satisfy the request from the pool of existing but unallocated resources. If it can, it just issues a lease and hands the resource back to the tool. This is very fast and should be the common case.
- If it can't satisfy the request from the pool of existing resources, it figures out how much of the request it can satisfy and how much new work it needs to do. For instance, it will try to use a host which has already been allocated if it has enough system resources. If it can't find a matching host, it can allocate a new one (e.g., by bringing up a machine in EC2).
- It does the work to build the resource, then issues a lease on it to the original tool.
- When the tool is done, it releases the lease.
- Eventually, Drydock may GC the resource.
In detail, the major parts of Drydock are:
- Resources, which represent allocated software or hardware.
- Interfaces, which expose capabilities on resources (e.g., command execution, filesystem access, webserver management).
- Blueprints, which are scripts for building new resources.
Drydock is blocking a lot of other stuff right now and is a relatively high priority.
== Phacility (Phabricator SaaS)
- {T1315}
We're building a SaaS version of Phabricator. This is primarily blocked by Drydock, but also by a lot of other missing components. The goal is to offer a paid, hosted version of the software and line our pockets with tens of dollars; wealth unimaginable.
== Policy (Permissions, Roles and Privacy)
- {T603}
We're in the process of implementing object visibility policies, so you can lock objects down to certain groups of permitted viewers.
== Harbormaster (Continuous Integration)
- {T1049}
We're building a CI tool, similar to Jenkins. This is blocked almost entirely by Drydock.
== Releeph (Release Management)
Facebook is open sourcing their release management tool. Releeph helps release engineers manage which changes get picked into which releases. This is partly blocked by Drydock. This does not currently include tools to handle actual deployment of software, but may evolve that way once we get this landed.
== Notifications, Chat, Chatlog, and Webhooks
- {T974}
- {T1271}
- {T944}
- {T305}
We have a student team at Stanford working on implementing real-time notifications. These will work similarly to the notifications on Facebook, and alert you when content you're subscribed to is updated. As we integrate notifications, we plan to add more communication preferences and let users reduce the amount of email they receive, as well as export notifications through external channels.
We have a basic chat bot and a basic chat log which we want to improve, generalize, and offer more transports for (like HipChat support, and webhook support).
== Calendar
- {T407}
- {T406}
We have a very basic calendar application, which we want to improve and integrate with other tools. Notably, we planning to support user status (so when users are away on vacation, it's visible in the application), and probably things like oncall rotations and tighter integration with Maniphest eventually. Some of this exists already.
== Diviner (Documentation)
- {T988}
Phabricator uses a documentation generator called "Diviner" which we want to merge into Phabricator itself and improve support for.
== Phame (Blogging)
We're writing a blogging engine, then writing a blog.