Add latest changes from gitlab-org/gitlab@master

5 files changed, 30 insertions, 28 deletions

diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index b6206b301f7..3bca33b32b7 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -71,7 +71,7 @@ For example, many projects do releases but don't need to do hotfixes.
 ## GitHub flow as a simpler alternative
 
 In reaction to Git flow, GitHub created a simpler alternative.
-[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch:
+[GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) has only feature branches and a `main` branch:
 
 ```mermaid
 graph TD
@@ -341,7 +341,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re
 
 Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts.
 Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once.
-Atlassian has a more thorough explanation of the tradeoffs between merging and rebasing [on their blog](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase).
+Atlassian has [a more thorough explanation of the tradeoffs between merging and rebasing](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase) on their blog.
 
 A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch.
 There are three reasons to merge in `main`: utilizing new code, resolving merge conflicts, and updating long-running branches.
@@ -403,7 +403,7 @@ git commit -m 'Properly escape special characters in XML generation'
 
 An example of a good commit message is: "Combine templates to reduce duplicate code in the user views."
 The words "change," "improve," "fix," and "refactor" don't add much information to a commit message.
-For more information about formatting commit messages, please see this excellent [blog post by Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+For more information, please see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 
 To add more context to a commit message, consider adding information regarding the
 origin of the change. For example, the URL of a GitLab issue, or a Jira issue number,
diff --git a/doc/update/index.md b/doc/update/index.md
index a5aa563a17a..45b5f36bc5a 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -351,7 +351,8 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
   In 14.5 we introduce a set of migrations that wrap up this process by making sure
   that all remaining jobs over the `merge_request_diff_commits` table are completed.
   These jobs will have already been processed in most cases so that no extra time is necessary during an upgrade to 14.5.
-  But if there are remaining jobs, the deployment may take a few extra minutes to complete.
+  However, if there are remaining jobs or you haven't already upgraded to 14.1,
+  the deployment may take multiple hours to complete.
 
   All merge request diff commits will automatically incorporate these changes, and there are no
   additional requirements to perform the upgrade.
@@ -439,6 +440,11 @@ for how to proceed.
   with self-managed installations, and ensure 14.0.0-14.0.4 installations do not
   encounter issues with [batched background migrations](#batched-background-migrations).
 
+- Upgrading to GitLab [14.5](#1450) (or later) may take a lot longer if you do not upgrade to at least 14.1
+  first. The 14.1 merge request diff commits database migration can take hours to run, but runs in the
+  background while GitLab is in use. GitLab instances upgraded directly from 14.0 to 14.5 or later must
+  run the migration in the foreground and therefore take a lot longer to complete.
+
 - See [Maintenance mode issue in GitLab 13.9 to 14.4](#maintenance-mode-issue-in-gitlab-139-to-144).
 
 ### 14.0.0
diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md
index d5777267582..2c9f98b7c45 100644
--- a/doc/user/clusters/agent/troubleshooting.md
+++ b/doc/user/clusters/agent/troubleshooting.md
@@ -11,7 +11,7 @@ When you are using the GitLab Agent for Kubernetes, you might experience issues
 You can start by viewing the service logs:
 
 ```shell
-kubectl logs -f -l=app=gitlab-kubernetes-agent -n gitlab-kubernetes-agent
+kubectl logs -f -l=app=gitlab-agent -n gitlab-kubernetes-agent
 ```
 
 If you are a GitLab administrator, you can also view the [GitLab Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 36c81f8ca9b..a00ac13c87b 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -33,27 +33,14 @@ usernames. A GitLab administrator can configure the GitLab instance to
 
 ## Project members permissions
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219299) in GitLab 14.8, personal namespace owners appear with Owner role in new projects in their namespace. Introduced [with a flag](../administration/feature_flags.md) named `personal_project_owner_with_owner_access`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, personal namespace owners appearing with the Owner role in new projects in their namespace is disabled. To make it available,
-ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `personal_project_owner_with_owner_access`.
-The feature is not ready for production use.
-On GitLab.com, this feature is not available.
-
 A user's role determines what permissions they have on a project. The Owner role provides all permissions but is
 available only:
 
 - For group owners. The role is inherited for a group's projects.
 - For Administrators.
 
-Personal [namespace](group/index.md#namespaces) owners:
-
-- Are displayed as having the Maintainer role on projects in the namespace, but have the same permissions as a user with the Owner role.
-- (Disabled by default) In GitLab 14.8 and later, for new projects in the namespace, are displayed as having the Owner role.
-
-For more information about how to manage project members, see
-[members of a project](project/members/index.md).
+Personal namespace owners have the same permissions as an Owner, but are displayed with the Maintainer role on projects created in their personal namespace.
+For more information, see [projects members documentation](project/members/index.md).
 
 The following table lists project permissions available for each role:
 
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index 408b55a6fe7..0a799843d3c 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -32,24 +32,33 @@ in the search field in the upper right corner:
 
 ### Filter issue and merge request lists
 
-> - Filter by Epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/195704) in GitLab Ultimate 12.9.
-> - Filter by child Epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9029) in GitLab Ultimate 13.0.
-> - Filter by Iterations was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118742) in GitLab 13.6. Moved to GitLab Premium in 13.9.
+> - Filtering by epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/195704) in GitLab 12.9.
+> - Filtering by child epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9029) in GitLab 13.0.
+> - Filtering by iterations was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118742) in GitLab 13.6. Moved from GitLab Ultimate to Premium in 13.9.
+> - Filtering by type was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322755) in GitLab 13.10 [with a flag](../../administration/feature_flags.md) named `vue_issues_list`. Disabled by default.
 
 Follow these steps to filter the **Issues** and **Merge requests** list pages in projects and
 groups:
 
 1. Click in the field **Search or filter results...**.
 1. In the dropdown menu that appears, select the attribute you wish to filter by:
-   - Author
    - Assignee
-   - [Milestone](../project/milestones/index.md)
+   - Author
+   - Confidential
+   - [Epic and child Epic](../group/epics/index.md) (available only for the group the Epic was created, not for [higher group levels](https://gitlab.com/gitlab-org/gitlab/-/issues/233729)).
    - [Iteration](../group/iterations/index.md)
-   - Release
    - [Label](../project/labels.md)
+   - [Milestone](../project/milestones/index.md)
    - My-reaction
-   - Confidential
-   - [Epic and child Epic](../group/epics/index.md) (available only for the group the Epic was created, not for [higher group levels](https://gitlab.com/gitlab-org/gitlab/-/issues/233729)).
+   - Release
+   - Type
+
+     FLAG:
+     On self-managed GitLab, by default filtering by type is not available.
+     To make it available per group, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `vue_issues_list`.
+     On GitLab.com, this feature is not available.
+
+   - Weight
    - Search for this text
 1. Select or type the operator to use for filtering the attribute. The following operators are
    available: