diff --git a/Documentation/config-gerrit.txt b/Documentation/config-gerrit.txt
index 0488085..b8b66ef 100644
--- a/Documentation/config-gerrit.txt
+++ b/Documentation/config-gerrit.txt
@@ -3054,11 +3054,6 @@
 
 For further information about Elasticsearch security, please refer to the documentation:
 
-* link:https://www.elastic.co/guide/en/x-pack/5.6/security-getting-started.html[Elasticsearch 5.6]
-* link:https://www.elastic.co/guide/en/x-pack/6.2/security-getting-started.html[Elasticsearch 6.2]
-* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.3/security-getting-started.html[Elasticsearch 6.3]
-* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.4/security-getting-started.html[Elasticsearch 6.4]
-* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.5/security-getting-started.html[Elasticsearch 6.5]
 * link:https://www.elastic.co/guide/en/elastic-stack-overview/6.6/security-getting-started.html[Elasticsearch 6.6]
 
 [[elasticsearch.username]]elasticsearch.username::
diff --git a/Documentation/dev-contributing.txt b/Documentation/dev-contributing.txt
index d54c9fa..23ecd67 100644
--- a/Documentation/dev-contributing.txt
+++ b/Documentation/dev-contributing.txt
@@ -1,10 +1,12 @@
+:linkattrs:
 = Gerrit Code Review - Contributing
 
 [[cla]]
 == Contributor License Agreement
 
 In order to contribute to Gerrit a link:dev-cla.html[Contributor
-License Agreement] must be completed before contributions are accepted.
+License Agreement,role=external,window=_blank] must be completed before
+contributions are accepted.
 
 [[contribution-processes]]
 == Contribution Processes
@@ -19,27 +21,28 @@
 The lightweight contribution process has little overhead and is best
 suited for small contributions (documentation updates, bug fixes, small
 features). Contributions are pushed as changes and
-link:dev-roles.html#maintainer[maintainers] review them adhoc.
+link:dev-roles.html#maintainer[maintainers,role=external,window=_blank]
+review them adhoc.
 
 For large/complex features, it is required to follow the
 link:#design-driven-contribution-process[design-driven contribution
 process] and specify the feature in a link:dev-design-docs.html[design
-doc] before starting with the implementation.
+doc,role=external,window=_blank] before starting with the implementation.
 
-If link:dev-roles.html#contributor[contributors] choose the
-lightweight contribution process and during the review it turns out
+If link:dev-roles.html#contributor[contributors,role=external,window=_blank]
+choose the lightweight contribution process and during the review it turns out
 that the feature is too large or complex,
-link:dev-roles.html#maintainer[maintainers] can require to follow the
-design-driven contribution process instead.
+link:dev-roles.html#maintainer[maintainers,role=external,window=_blank] can
+require to follow the design-driven contribution process instead.
 
 If you are in doubt which process is right for you, consult the
-link:https://groups.google.com/d/forum/repo-discuss[repo-discuss]
+link:https://groups.google.com/d/forum/repo-discuss[repo-discuss,role=external,window=_blank]
 mailing list.
 
 These contribution processes apply to everyone who contributes code to
 the Gerrit project, including link:dev-roles.html#maintainer[
-maintainers]. When reading this document, keep in mind that maintainers
-are also contributors when they contribute code.
+maintainers,role=external,window=_blank]. When reading this document, keep in
+mind that maintainers are also contributors when they contribute code.
 
 If a new feature is large or complex, it is often difficult to find a
 maintainer who can take the time that is needed for a thorough review,
@@ -56,7 +59,8 @@
 |======================
 |        |Lightweight Contribution Process|Design-Driven Contribution Process
 |Overhead|low (write good commit message, address review comments)|
-high (write link:dev-design-docs.html[design doc] and get it approved)
+high (write link:dev-design-docs.html[design doc,role=external,window=_blank]
+and get it approved)
 |Technical Guidance|by reviewer|during the design review and by
 reviewer/mentor
 |Review  |adhoc (when reviewer is available)|by a dedicated mentor (if
@@ -83,17 +87,17 @@
 be reviewed before they will get submitted to the code base.  To
 start your contribution, please make a git commit and upload it
 for review to the link:https://gerrit-review.googlesource.com/[
-gerrit-review.googlesource.com] Gerrit server.  To help speed up the
-review of your change, review these link:dev-crafting-changes.html[
-guidelines] before submitting your change.  You can view the pending
-Gerrit contributions and their statuses
-link:https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit[here].
+gerrit-review.googlesource.com,role=external,window=_blank] Gerrit server.  To
+help speed up the review of your change, review these link:dev-crafting-changes.html[
+guidelines,role=external,window=_blank] before submitting your change.  You can
+view the pending Gerrit contributions and their statuses
+link:https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit[here,role=external,window=_blank].
 
 Depending on the size of that list it might take a while for
 your change to get reviewed.  Naturally there are fewer
-link:dev-roles.html#maintainer[maintainers], that can approve changes,
-than link:dev-roles.html#contributor[contributors]; so anything that
-you can do to ensure that your contribution will undergo fewer
+link:dev-roles.html#maintainer[maintainers,role=external,window=_blank], that
+can approve changes, than link:dev-roles.html#contributor[contributors,role=external,window=_blank];
+so anything that you can do to ensure that your contribution will undergo fewer
 revisions will speed up the contribution process.  This includes
 helping out reviewing other people's changes to relieve the load from
 the maintainers.  Even if you are not familiar with Gerrit's internals,
@@ -124,26 +128,28 @@
 * think about possibilities how the feature could be evolved over time
 
 This is why for large/complex features it is required to describe the
-feature in a link:dev-design-docs.html[design doc] and get it approved
-by the link:dev-processes.html#steering-committee[steering committee],
+feature in a link:dev-design-docs.html[design doc,role=external,window=_blank]
+and get it approved by the
+link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank],
 before starting the implementation.
 
 The design-driven contribution process has the following steps:
 
-* A link:dev-roles.html#contributor[contributor]
-  link:dev-design-docs.html#propose[proposes] a new feature by
-  uploading a change with a link:dev-design-docs.html[design doc].
-* The design doc is link:dev-design-docs.html#review[reviewed] by
-  interested parties from the community. The design review is public
+* A link:dev-roles.html#contributor[contributor,role=external,window=_blank]
+  link:dev-design-docs.html#propose[proposes,role=external,window=_blank] a new
+  feature by uploading a change with a
+  link:dev-design-docs.html[design doc,role=external,window=_blank].
+* The design doc is link:dev-design-docs.html#review[reviewed,role=external,window=_blank]
+  by interested parties from the community. The design review is public
   and everyone can comment and raise concerns.
 * Design docs should stay open for a minimum of 10 calendar days so
   that everyone has a fair chance to join the review.
 * Within 14 calendar days the contributor should hear back from the
-  link:dev-processes.html#steering-committee[steering committee]
+  link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank]
   whether the proposed feature is in scope of the project and if it can
   be accepted.
 * To be submitted, the design doc needs to be approved by the
-  link:dev-processes.html#steering-committee[steering committee].
+  link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank].
 * After the design was approved, the implementation is done by pushing
   changes for review, see link:#lightweight-contribution-process[
   lightweight contribution process]. Changes that are associated with
@@ -169,7 +175,7 @@
 
 * Accepting the feature when it is implemented.
 * Supporting the feature by assigning a link:dev-roles.html#mentor[
-  mentor] (if requested, see link:#mentorship[mentorship]).
+  mentor,role=external,window=_blank] (if requested, see link:#mentorship[mentorship]).
 
 If the implementation of a feature gets stuck and it's unclear whether
 the feature gets fully done, it should be discussed with the steering
@@ -185,8 +191,8 @@
   design review, feedback from various sides can be collected, which
   likely leads to improvements of the feature.
 * Once a design was approved by the
-  link:dev-processes.html#steering-committee[steering committee], the
-  contributor can be almost certain that the feature will be accepted.
+  link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank],
+  the contributor can be almost certain that the feature will be accepted.
   Hence, there is only a low risk to invest into implementing a feature
   and see it being rejected later during the code review, as it can
   happen with the lightweight contribution process.
@@ -197,12 +203,12 @@
 [[mentorship]]
 == Mentorship
 
-For features for which a link:dev-design-docs.html[design] has been
-approved (see link:#design-driven-contribution-process[design-driven
+For features for which a link:dev-design-docs.html[design,role=external,window=_blank]
+has been approved (see link:#design-driven-contribution-process[design-driven
 contribution process]), contributors can gain the support of a mentor
 if they are committed to implement the feature.
 
-A link:dev-roles.html#mentor[mentor] helps with:
+A link:dev-roles.html#mentor[mentor,role=external,window=_blank] helps with:
 
 * doing timely reviews
 * providing technical guidance during code reviews
@@ -212,12 +218,13 @@
 
 A feature can have more than one mentor. To be able to deliver the
 promised support, at least one of the mentors must be a
-link:dev-roles.html#maintainer[maintainer].
+link:dev-roles.html#maintainer[maintainer,role=external,window=_blank].
 
 Mentors are assigned by the link:dev-processes.html#steering-committee[
-steering committee]. To gain a mentor, ask for a mentor in the
-link:dev-design-docs.html#structure[Implementation Plan] section of the design
-doc or ask the steering committee after the design has been approved.
+steering committee,role=external,window=_blank]. To gain a mentor, ask for a
+mentor in the link:dev-design-doc-template.html#implementation-plan[Implementation
+Plan,role=external,window=_blank] section of the design doc or ask the steering
+committee after the design has been approved.
 
 Mentors may not be available immediately. In this case, the steering
 committee should include the approved feature into the roadmap or
diff --git a/Documentation/dev-crafting-changes.txt b/Documentation/dev-crafting-changes.txt
index c35350f..d101ffa 100644
--- a/Documentation/dev-crafting-changes.txt
+++ b/Documentation/dev-crafting-changes.txt
@@ -107,7 +107,7 @@
 change, so that reviewers will do it for you. Yes, the way to go is to
 extend gerrit CI to take care of this, but it's not yet implemented.
 
-Gerrit generally follows the
+Gerrit follows the
 link:https://google.github.io/styleguide/javaguide.html[Google Java Style
 Guide].
 
@@ -128,19 +128,6 @@
 wrapper script. If you run your own copy, please use the same version,
 as there may be slight differences between versions.
 
-When considering the style beyond just formatting rules, it is often
-more important to match the style of the nearby code which you are
-modifying than it is to match the style guide exactly. This is
-especially true within the same file.
-
-Additionally, you will notice that most of the newline spacing
-is fairly consistent throughout the code in Gerrit, it helps to
-stick to the blank line conventions.  Here are some specific
-examples:
-
-  * Keep a blank line between all class and method declarations.
-  * Do not add blank lines at the beginning or end of class/methods.
-
 When to use `final` modifier and when not (in new code):
 
 Always:
diff --git a/java/com/google/gerrit/elasticsearch/ElasticVersion.java b/java/com/google/gerrit/elasticsearch/ElasticVersion.java
index 82816fb..fb24cb0 100644
--- a/java/com/google/gerrit/elasticsearch/ElasticVersion.java
+++ b/java/com/google/gerrit/elasticsearch/ElasticVersion.java
@@ -18,7 +18,6 @@
 import java.util.regex.Pattern;
 
 public enum ElasticVersion {
-  V6_5("6.5.*"),
   V6_6("6.6.*"),
   V6_7("6.7.*"),
   V6_8("6.8.*"),
@@ -48,7 +47,14 @@
     }
   }
 
-  public static ElasticVersion forVersion(String version) throws UnsupportedVersion {
+  /**
+   * Convert a version String to an ElasticVersion if supported.
+   *
+   * @param version for which to return an ElasticVersion
+   * @return the corresponding ElasticVersion if supported
+   * @throws UnsupportedVersion
+   */
+  public static ElasticVersion forVersion(String version) {
     for (ElasticVersion value : ElasticVersion.values()) {
       if (value.pattern.matcher(version).matches()) {
         return value;
diff --git a/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java b/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java
index e4b45ed..df3ec5e 100644
--- a/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java
+++ b/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java
@@ -38,14 +38,12 @@
 
   private static String getImageName(ElasticVersion version) {
     switch (version) {
-      case V6_5:
-        return "blacktop/elasticsearch:6.5.4";
       case V6_6:
         return "blacktop/elasticsearch:6.6.2";
       case V6_7:
         return "blacktop/elasticsearch:6.7.2";
       case V6_8:
-        return "blacktop/elasticsearch:6.8.8";
+        return "blacktop/elasticsearch:6.8.9";
       case V7_0:
         return "blacktop/elasticsearch:7.0.1";
       case V7_1:
diff --git a/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java b/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java
index e36ff0b..280b884 100644
--- a/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java
+++ b/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java
@@ -22,9 +22,6 @@
 public class ElasticVersionTest {
   @Test
   public void supportedVersion() throws Exception {
-    assertThat(ElasticVersion.forVersion("6.5.0")).isEqualTo(ElasticVersion.V6_5);
-    assertThat(ElasticVersion.forVersion("6.5.1")).isEqualTo(ElasticVersion.V6_5);
-
     assertThat(ElasticVersion.forVersion("6.6.0")).isEqualTo(ElasticVersion.V6_6);
     assertThat(ElasticVersion.forVersion("6.6.1")).isEqualTo(ElasticVersion.V6_6);
 
@@ -70,7 +67,6 @@
 
   @Test
   public void atLeastMinorVersion() throws Exception {
-    assertThat(ElasticVersion.V6_5.isAtLeastMinorVersion(ElasticVersion.V6_7)).isFalse();
     assertThat(ElasticVersion.V6_6.isAtLeastMinorVersion(ElasticVersion.V6_7)).isFalse();
     assertThat(ElasticVersion.V6_7.isAtLeastMinorVersion(ElasticVersion.V6_7)).isTrue();
     assertThat(ElasticVersion.V6_8.isAtLeastMinorVersion(ElasticVersion.V6_8)).isTrue();
@@ -85,7 +81,6 @@
 
   @Test
   public void version6OrLater() throws Exception {
-    assertThat(ElasticVersion.V6_5.isV6OrLater()).isTrue();
     assertThat(ElasticVersion.V6_6.isV6OrLater()).isTrue();
     assertThat(ElasticVersion.V6_7.isV6OrLater()).isTrue();
     assertThat(ElasticVersion.V6_8.isV6OrLater()).isTrue();
@@ -100,7 +95,6 @@
 
   @Test
   public void version7OrLater() throws Exception {
-    assertThat(ElasticVersion.V6_5.isV7OrLater()).isFalse();
     assertThat(ElasticVersion.V6_6.isV7OrLater()).isFalse();
     assertThat(ElasticVersion.V6_7.isV7OrLater()).isFalse();
     assertThat(ElasticVersion.V6_8.isV7OrLater()).isFalse();
diff --git a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js
index bd0486f..142bd6a 100644
--- a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js
+++ b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js
@@ -568,8 +568,7 @@
 
     _goToEditFile() {
       // TODO(taoalpha): add a shortcut for editing
-      const editUrl = Gerrit.Nav.getEditUrlForDiff(
-          this._change, this._path, this._patchRange.patchNum);
+      const editUrl = Gerrit.Nav.getEditUrlForDiff(this._change, this._path);
       return Gerrit.Nav.navigateToRelativeUrl(editUrl);
     },
 
diff --git a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html
index 9c59577..046a153 100644
--- a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html
+++ b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html
@@ -394,6 +394,7 @@
       };
       element._change = {
         _number: 42,
+        project: 'gerrit',
         status: 'NEW',
         revisions: {
           a: {_number: 1, commit: {parents: []}},
@@ -407,6 +408,8 @@
         assert.isTrue(!!editBtn);
         MockInteractions.tap(editBtn);
         assert.isTrue(redirectStub.called);
+        assert.isTrue(redirectStub.lastCall.calledWithExactly(
+            Gerrit.Nav.getEditUrlForDiff(element._change, element._path)));
         done();
       });
     });