docs: add a roadmap

README.md

@@ -11,11 +11,13 @@
 
 **[Homepage]   •  **
 **[Installation]   •  **
-**[Getting Started]**
+**[Getting Started]   •  **
+**[Roadmap]**
 
 [Homepage]: https://martinvonz.github.io/jj
 [Installation]: https://martinvonz.github.io/jj/latest/install-and-setup
 [Getting Started]: https://martinvonz.github.io/jj/latest/tutorial
+[Roadmap]: https://martinvonz.github.io/jj/latest/roadmap
 
 </div>
 

docs/roadmap.md

@@ -0,0 +1,91 @@
+# Roadmap
+
+This documents some of the goals we have. Many of them are quite independent.
+
+> **Note:** Most people contributing to Jujutsu do so in their spare time, which
+>  means that we cannot attach any target dates to any of the goals below.
+
+## Support for copies and renames
+
+We want to support copy tracing in a way that leaves it up to the commit backend
+to either record or detect copies. That should let us work with existing Git
+repos (Git does not record copies, it detects them on the fly) as well as with
+very large repos where detection would be too slow. See
+[design doc][copy-design-doc].
+
+## Forge integrations
+
+We would like to make it easier to work with various popular forges by providing
+something like `jj github submit`, `jj gitlab submit`, and `jj gerrit send`. For
+popular forges, we might include that support by default in the standard `jj`
+binary.
+
+## Submodule support
+
+Git submodules are used frequently enough in large Git repos that we will
+probably need to [support them][submodules]. There are still big open
+questions around UX.
+
+## Better Rust API for UIs
+
+UIs like [gg] currently have to duplicate quite a bit of logic from `jj-cli`. We
+need to make this code not specific to the CLI (e.g. return status objects
+instead of printing messages) and move it into `jj-lib`.
+
+## RPC API
+
+One problem with writing tools using the Rust API is that they will only work
+with the backends they were compiled with. For example, a regular [gg] build
+will not work on Google repos because it doesn't have the backends necessary to
+load them. We want to provide an RPC API for tools that want to work with an
+unknown build of `jj` by having the tool run something like `jj api` to give it
+an address to talk to.
+
+In addition to helping with the problem of unknown backends, having an RPC API
+should make it easier for tools like VS Code that are not written in Rust. The
+RPC API will probably be at a higher abstraction level than the Rust API.
+
+See [design doc][api-design-doc].
+
+## Open-source cloud-based repos (server and daemon process)
+
+Google has an internal Jujutsu server backed by a database. This server allows
+commits and repos (operation logs) to be stored in the cloud (i.e. the database).
+Working copies can still be stored locally.
+
+In order to reduce latency, there is a local daemon process that caches reads
+and writes. It also prefetches of objects it thinks the client might as for
+next. In also helps with write latency by optimistically answering write
+requests (it therefore needs to know the server's hashing scheme so it can
+return the right IDs).
+
+We (the project, not necessarily Google) want to provide a similar experience
+for all users. We would therefore like to create a similar server and daemon.
+The daemon might be the same process as for the RPC API mentioned above.
+
+## Virtual file system (VFS)
+
+For very large projects and/or large files, it can be expensive to update the
+working copy. We want to provide a VFS to help with that. Updating the working
+copy to another commit can then be done simply by telling the VFS to use the
+other commit as base, without needing to download any large files in the target
+commit until the user asks for them via the file system. A VFS can also make it
+cheap to snapshot the working copy by keeping track of all changes compared to
+the base commit.
+
+Having a VFS can also be very benefial for [`jj run`][jj-run], since we can then
+cheaply create temporary working copies for the commands to run in.
+
+## Better support for large files
+
+We have talked about somehow using content-defined chunking (CDC) to reduce
+storage and transfer costs for large files. Maybe we will store files in our
+future cloud-based server using the same model as [XetHub][xet-storage].
+
+
+[api-design-doc]: https://docs.google.com/document/d/1rOKvutee5TVYpFhh_UDNZDxfUKyrJ8rjCNpFaNHOHwU/edit?usp=sharing&resourcekey=0-922ApyoAjuXN_uTKqmCqjg
+[copy-design-doc]: design/copy-tracking.md
+[gg]: https://github.com/gulbanana/gg
+[jj-run]: https://github.com/martinvonz/jj/issues/1869
+[submodules]: https://github.com/martinvonz/jj/issues/494
+[xet-storage]: https://xethub.com/assets/docs/concepts/xet-storage