Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitaly.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJacob Vosmaer <jacob@gitlab.com>2018-11-27 16:58:48 +0300
committerZeger-Jan van de Weg <git@zjvandeweg.nl>2018-11-27 16:58:48 +0300
commit9d6c4c4158db75fbd57a59b91a3d91df89a4c5cd (patch)
tree97f865cba89d6a17ba65f4d9cfe7f1d4a1fdbbad /doc/PROCESS.md
parente5e58f04284a3ae524aa2b85d750b8a9597d779a (diff)
Clean up process documentation
Diffstat (limited to 'doc/PROCESS.md')
-rw-r--r--doc/PROCESS.md74
1 files changed, 14 insertions, 60 deletions
diff --git a/doc/PROCESS.md b/doc/PROCESS.md
index fe3e7fd45..b750a79c1 100644
--- a/doc/PROCESS.md
+++ b/doc/PROCESS.md
@@ -2,75 +2,29 @@
We use our issues board for keeping our work in progress up to date in a single place. Please refer to it to see the current status of the project.
-### [Version 1.0][v1.0-milestone]
-
-Version 1.0 is what we need to run gitlab.com 100% on Gitaly, with no
-NFS access to Git repositories anymore.
-
-We expect that gitlab.com will only use a subset of all endpoints. We
-may choose to defer migrating some endpoints until version 1.1.
-
-Version 1.0 will not be done until all included endpoints are in
-opt-out state, meaning that they are sufficiently performant and
-bug-free.
-
-### [Version 1.1][v1.1-milestone]
-
-Version 1.1 will conclude the migration project. This means that that
-the only production (i.e. non-test) code in anywhere in GitLab that
-touches Git repositories is in Gitaly. There will be no configuration
-'knowledge' in the main GitLab Rails application anymore on where the
-repositories are stored.
-
-After version 1.1 we will stop vendoring gitlab-git into Gitaly.
-
-### Backlog
-
-Any feature that is not essential to version 1.0 (gitlab.com 100%
-Gitaly) or version 1.1 (0% Git in gitlab-ee) will be deferred until
-after version 1.1.
-
-### Order of Migration
-
-Current priorities:
-
-1. Work that gets us closer to version 1.0: issues with the [v1.0 milestone][v1.0-milestone]
-1. Work towards version 1.1: issues with the [v1.1 milestone][v1.1-milestone]
-
## Gitaly Team Process
-Gitaly is a fairly unique service in GitLab in that is has no dependencies on [gitlab-rails](https://gitlab.com/gitlab-org/gitlab-ce) or its SQL database.
-
-This means that we can iterate faster than the gitlab-rails project, adding improvements (particularly optimisations) at a faster rate.
-
### Gitaly Releases
-Gitaly is still below 1.0.0. We increment the minor version when adding new features, or the patch version for bug fixes.
-
-### Iterative Process
-
-![](https://docs.google.com/drawings/d/11KY4ef2A1w1cie_um-ROUJ1N3GyFuWwhNEHjCzglzbA/pub?w=1440&h=810)
-[Edit this diagram](https://docs.google.com/drawings/d/11KY4ef2A1w1cie_um-ROUJ1N3GyFuWwhNEHjCzglzbA/edit)
-
-The diagram explains most of the process.
-
-* Two week long iterations, kickoff on a Wednesday
-* Two milestones per iteration
+Gitaly uses [SemVer](https://semver.org) version numbering.
## Branching Model
-Like other GitLab projects, Gitaly uses the [GitLab Workflow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html) branching model.
-
-![](https://docs.google.com/drawings/d/1VBDeOouLohq5EqOrht_9IGgNGQ2D6WgW_O6TgKytU2w/pub?w=960&h=720)
+All tags get created on the `master` branch, except patch releases for
+older minor versions. Such patches get an "on-demand stable branch".
-[Edit this diagram](https://docs.google.com/a/gitlab.com/drawings/d/1VBDeOouLohq5EqOrht_9IGgNGQ2D6WgW_O6TgKytU2w/edit)
+### Example:
-* Merge requests will target the master branch.
-* If the merge request is an optimisation of the previous stable branch, i.e. the branch currently running on GitLab.com, the MR will be cherry picked across to the stable branch and deployed to Gitlab.com from there.
+Suppose we have the following sequence of tags on Gitaly `master`:
-# Migration Process
+- v6.0.0
+- v5.4.4
+- v5.4.3
-The Gitaly team aim to migrate each feature across to Gitaly according to a standardised process - read about the [Gitaly Migration Process here](MIGRATION_PROCESS.md)
+Now imagine GitLab `12-3-stable` uses Gitaly 5.4.3 and we have a Gitaly
+bug fix we want to include in GitLab `12-3-stable`. We will create an
+"on-demand stable branch" in Gitaly for this:
-[v1.0-milestone]: https://gitlab.com/gitlab-org/gitaly/milestones/54
-[v1.1-milestone]: https://gitlab.com/gitlab-org/gitaly/milestones/55
+1. Create `5-4-stable` in Gitaly from the latest 5.4.x tag:
+ `git checkout -b 5-4-stable v5.4.4`.
+2. Create Gitaly `v5.4.5` on the `5-4-stable` branch.