X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FDeveloperPolicy.rst;h=17baf2d27b134b2f7e15e8b97ad747f2996ca185;hb=ee7970e77ea2553aa5cd1a26f40296f1b7cf4305;hp=5a83f5e43a8787af99b8b4b11e899242104872c9;hpb=e4b68811b11a691215ea6b7e787b69f313ce8294;p=oota-llvm.git

diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
index 5a83f5e43a8..17baf2d27b1 100644
--- a/docs/DeveloperPolicy.rst
+++ b/docs/DeveloperPolicy.rst
@@ -529,28 +529,28 @@ C API Changes
 ----------------
 
 * Stability Guarantees: The C API is, in general, a "best effort" for stability.
-This means that we make every attempt to keep the C API stable, but that
-stability will be limited by the abstractness of the interface and the stability
-of the C++ API that it wraps. In practice, this means that things like "create
-debug info" or "create this type of instruction" are likely to be less stable
-than "take this IR file and JIT it for my current machine".
+  This means that we make every attempt to keep the C API stable, but that
+  stability will be limited by the abstractness of the interface and the
+  stability of the C++ API that it wraps. In practice, this means that things
+  like "create debug info" or "create this type of instruction" are likely to be
+  less stable than "take this IR file and JIT it for my current machine".
 
-* Release stability: We won’t break the C API on the release branch with patches
-that go on that branch, with the exception that if we will fix an unintentional
-C API break that will keep the release consistent with both the previous and next
-release.
+* Release stability: We won't break the C API on the release branch with patches
+  that go on that branch, with the exception that we will fix an unintentional
+  C API break that will keep the release consistent with both the previous and
+  next release.
 
 * Testing: Patches to the C API are expected to come with tests just like any
-other patch.
+  other patch.
 
 * Including new things into the API: If an LLVM subcomponent has a C API already
-included, then expanding that C API is acceptable. Adding C API for subcomponents
-that don't currently have one is fine, and the details of how best to design that
-API should be discussed on the mailing list.
+  included, then expanding that C API is acceptable. Adding C API for
+  subcomponents that don't currently have one needs to be discussed on the
+  mailing list for design and maintainability feedback prior to implementation.
 
 * Documentation: Any changes to the C API are required to be documented in the
-release notes so that it’s clear to external users who do not follow the project
-how the C API is changing and evolving.
+  release notes so that it's clear to external users who do not follow the
+  project how the C API is changing and evolving.
 
 .. _copyright-license-patents: