List of potential items to migrate and optimise in Gitaly

Start planning what the next iterations of Gitaly will include and how the process will work.

---

Aside (Andrew Newdigate): As agreed in the status call on 25 Jan, we'll stick with this model for now as it's what everyone understands, however I think that in the long term, targeting the Patch/Optimisation merge requests against the *-stable branches and backmerging to master is a better strategy. Why?

• The code is developed and tested against the stable environment rather than cutting edge. This means that there will be less surprises (read: less downtime) when it's rolled into production intra-release.
• By contrast, the current strategy will inherently test the patch against stable less. By merging into master and then cherry picking, authors can introduce bugs on the cherry pick which will only be discovered once the code is in production.
• When a time-critical production issue occurs, the hotfix process involves targeting master and then cherry picking the change to stable. This will take more time (read: more downtime) than patching the stable branch and using the back merge strategy afterwards.