[5/5] flink git commit: [FLINK-6937] [docs] Fix broken link in Production Readiness Checklist

[tz...@apache.org]

[FLINK-6937] [docs] Fix broken link in Production Readiness Checklist

This closes #4134.


Project: http://git-wip-us.apache.org/repos/asf/flink/repo
Commit: http://git-wip-us.apache.org/repos/asf/flink/commit/87e1e8fc
Tree: http://git-wip-us.apache.org/repos/asf/flink/tree/87e1e8fc
Diff: http://git-wip-us.apache.org/repos/asf/flink/diff/87e1e8fc

Branch: refs/heads/master
Commit: 87e1e8fc350544d81b751efd87f725a1413da1f9
Parents: d1ee819
Author: Juan Paulo Gutierrez <ju...@gmail.com>
Authored: Tue Jun 13 14:31:40 2017 +0900
Committer: Tzu-Li (Gordon) Tai <tz...@apache.org>
Committed: Thu Jun 22 17:40:04 2017 +0800

----------------------------------------------------------------------
 docs/ops/production_ready.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/87e1e8fc/docs/ops/production_ready.md
----------------------------------------------------------------------
diff --git a/docs/ops/production_ready.md b/docs/ops/production_ready.md
index e3e6353..2cce8d0 100644
--- a/docs/ops/production_ready.md
+++ b/docs/ops/production_ready.md
@@ -64,7 +64,7 @@ parallelism as a function of the parallelism when the job is first started:
 
 ### Set UUIDs for operators
 
-As mentioned in the documentation for [savepoints]({{ site.baseurl }}/setup/savepoints.html, users should set uids for
+As mentioned in the documentation for [savepoints]({{ site.baseurl }}/setup/savepoints.html), users should set uids for
 operators. Those operator uids are important for Flink's mapping of operator states to operators which, in turn, is 
 essential for savepoints. By default operator uids are generated by traversing the JobGraph and hashing certain operator 
 properties. While this is comfortable from a user perspective, it is also very fragile, as changes to the JobGraph (e.g.
@@ -85,4 +85,4 @@ very important for large states because they do not block the operators and Flin
 stream processing. However, RocksDB can have worse performance than, for example, the memory-based state backends. If
 you are sure that your state will never exceed main memory and blocking the stream processing to write it is not an issue,
 you **could consider** to not use the RocksDB backends. However, at this point, we **strongly recommend** using RocksDB
-for production.
\ No newline at end of file
+for production.