Add latest changes from gitlab-org/gitlab@master

4 files changed, 97 insertions, 16 deletions

diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 8a1db615022..746618be50f 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -56,6 +56,13 @@ for more details.
 Make sure that in case that your migration job is going to be retried data
 integrity is guaranteed.
 
+## Background migrations for EE-only features
+
+All the background migration classes for EE-only features should be present in GitLab CE.
+For this purpose, an empty class can be created for GitLab CE and for GitLab EE it can be extended
+For this purpose, an empty class can be created for GitLab CE,  and it can be extended for GitLab EE
+as explained in the [guidelines for implementing Enterprise Edition features](ee_features.md#code-in-libgitlabbackground_migration).
+
 ## How It Works
 
 Background migrations are simple classes that define a `perform` method. A
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 672ae5e7b27..7fdda7fab27 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -350,6 +350,55 @@ resolve when you add the indentation to the equation.
 EE-specific views should be placed in `ee/app/views/`, using extra
 sub-directories if appropriate.
 
+### Code in `lib/gitlab/background_migration/`
+
+When you create EE-only background migrations, you have to plan for users that
+downgrade GitLab EE to CE. In other words, every EE-only migration has to be present in
+CE code but with no implementation, instead you need to extend it on EE side.
+
+GitLab CE:
+
+```ruby
+# lib/gitlab/background_migration/prune_orphaned_geo_events.rb
+
+module Gitlab
+  module BackgroundMigration
+    class PruneOrphanedGeoEvents
+      def perform(table_name)
+      end
+    end
+  end
+end
+
+Gitlab::BackgroundMigration::PruneOrphanedGeoEvents.prepend_if_ee('EE::Gitlab::BackgroundMigration::PruneOrphanedGeoEvents')
+```
+
+GitLab EE:
+
+```ruby
+# ee/lib/ee/gitlab/background_migration/prune_orphaned_geo_events.rb
+
+module EE
+  module Gitlab
+    module BackgroundMigration
+      module PruneOrphanedGeoEvents
+        extend ::Gitlab::Utils::Override
+
+        override :perform
+        def perform(table_name = EVENT_TABLES.first)
+          return if ::Gitlab::Database.read_only?
+
+          deleted_rows = prune_orphaned_rows(table_name)
+          table_name   = next_table(table_name) if deleted_rows.zero?
+
+          ::BackgroundMigrationWorker.perform_in(RESCHEDULE_DELAY, self.class.name.demodulize, table_name) if table_name
+        end
+      end
+    end
+  end
+end
+```
+
 #### Using `render_if_exists`
 
 Instead of using regular `render`, we should use `render_if_exists`, which
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index 903ca6ada4a..386baf825b8 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -195,6 +195,31 @@ For example use `%{created_at}` in Ruby but `%{createdAt}` in JavaScript. Make s
   // => When x == 2: 'Last 2 days'
   ```
 
+The `n_` method should only be used to fetch pluralized translations of the same
+string, not to control the logic of showing different strings for different
+quantities. Some languages have different quantities of target plural forms -
+Chinese (simplified), for example, has only one target plural form in our
+translation tool. This means the translator would have to choose to translate
+only one of the strings and the translation would not behave as intended in the
+other case.
+
+For example, prefer to use:
+
+```ruby
+if selected_projects.one?
+  selected_projects.first.name
+else
+  n__("Project selected", "%d projects selected", selected_projects.count)
+end
+```
+
+rather than:
+
+```ruby
+# incorrect usage example
+n_("%{project_name}", "%d projects selected", count) % { project_name: 'GitLab' }
+```
+
 ### Namespaces
 
 Sometimes you need to add some context to the text that you want to translate
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index 70a4cab39e2..cc86a4b91a0 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -104,10 +104,10 @@ GitLab.com](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7356).
 
 There are several strategies to provide high-availability and redundancy:
 
-1. Write-ahead logs (WAL) streamed to object storage (e.g. S3, Google Cloud
-   Storage).
-1. Read-replicas (hot backups)
-1. Delayed replicas
+- Write-ahead logs (WAL) streamed to object storage (e.g. S3, Google Cloud
+  Storage).
+- Read-replicas (hot backups).
+- Delayed replicas.
 
 To restore a database from a point in time, a base backup needs to have
 been taken prior to that incident. Once a database has restored from
@@ -145,9 +145,9 @@ saturate a single core, which can result in slower response times for
 background job and/or Web requests. There are two ways to address this
 limitation:
 
-1. Run multiple PgBouncer instances
-1. Use a multi-threaded connection pooler (e.g.
-   [Odyssey](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7776).
+- Run multiple PgBouncer instances.
+- Use a multi-threaded connection pooler (e.g.
+  [Odyssey](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7776).
 
 On some Linux systems, it's possible to run [multiple PgBouncer instances on
 the same port](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4796).
@@ -158,9 +158,9 @@ avoid saturating a single core.
 In addition, the PgBouncer instances that communicate with the primary
 and secondaries are set up a bit differently:
 
-1. Multiple PgBouncer instances in different availability zones talk to the
-   PostgreSQL primary
-1. Multiple PgBouncer processes are colocated with PostgreSQL read replicas
+- Multiple PgBouncer instances in different availability zones talk to the
+  PostgreSQL primary.
+- Multiple PgBouncer processes are colocated with PostgreSQL read replicas.
 
 For replicas, colocating is advantageous because it reduces network hops
 and hence latency. However, for the primary, colocating is
@@ -211,10 +211,10 @@ Redis process.
 
 #### High availability/Risks
 
-1. Single-core: Like PgBouncer, a single Redis process can only use one
+Single-core: Like PgBouncer, a single Redis process can only use one
 core.  It does not support multi-threading.
 
-1. Dumb secondaries: Redis secondaries (aka slaves) don't actually
+Dumb secondaries: Redis secondaries (aka slaves) don't actually
 handle any load. Unlike PostgreSQL secondaries, they don't even serve
 read queries. They simply replicate data from the primary and take over
 only when the primary fails.
@@ -240,10 +240,10 @@ Sidekiq is a multi-threaded, background job processing system used in
 Ruby on Rails applications. In GitLab, Sidekiq performs the heavy
 lifting of many activities, including:
 
-1. Updating merge requests after a push
-1. Sending e-mails
-1. Updating user authorizations
-1. Processing CI builds and pipelines
+- Updating merge requests after a push.
+- Sending e-mails.
+- Updating user authorizations.
+- Processing CI builds and pipelines.
 
 The full list of jobs can be found in the
 [app/workers](https://gitlab.com/gitlab-org/gitlab/tree/master/app/workers)