commit:     fee3ef8459482d515a4cfaf2308558ac8d279ccf
Author:     Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Sat Jul 16 07:02:45 2022 +0000
Commit:     Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Sat Jul 16 07:02:45 2022 +0000
URL:        https://gitweb.gentoo.org/data/glep.git/commit/?id=fee3ef84

glep-0083: Whitespace

Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>

 glep-0083.rst | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/glep-0083.rst b/glep-0083.rst
index 3f9b259..f2a55a3 100644
--- a/glep-0083.rst
+++ b/glep-0083.rst
@@ -22,17 +22,17 @@ Motivation
 ==========
 
 So far, old EAPIs were deprecated by the Gentoo Council in an ad-hoc
-manner. No fixed criteria were used, resulting in very different
-deprecation times after approval of newer EAPIs. Standardized criteria
-for deprecation and banning will make the life cycle of EAPIs more
-predictable.
+manner.  No fixed criteria were used, resulting in very different
+deprecation times after approval of newer EAPIs.  Standardized
+criteria for deprecation and banning will make the life cycle of EAPIs
+more predictable.
 
 
 Specification
 =============
 
 A *deprecated EAPI* is no longer required for the upgrade path of
-users' systems. Its use is discouraged, and tools like pkgcheck will
+users' systems.  Its use is discouraged, and tools like pkgcheck will
 warn about this [#COUNCIL-20130409]_.
 
 A *banned EAPI* must no longer be used, neither for new ebuilds, nor
@@ -60,8 +60,8 @@ complexity, e.g. in eclasses.
 
 On the other hand, an upgrade path to a stable system is guaranteed
 for one year, plus limited support for systems that are outdated more
-than a year [#COUNCIL-20091109]_. Therefore, previous EAPIs are still
-required during that time. A period of 24 months before deprecation
+than a year [#COUNCIL-20091109]_.  Therefore, previous EAPIs are still
+required during that time.  A period of 24 months before deprecation
 has been chosen, which is more than the required minimum and will
 allow projects to support a longer upgrade path.
 
@@ -70,8 +70,8 @@ are otherwise seldom updated to be bumped to the next but one 
EAPI
 immediately.
 
 A delay of 24 months between deprecation and ban will give ebuild
-authors enough time to update. This is especially relevant for
-overlays and downstream distributions. Since a banned EAPI is
+authors enough time to update.  This is especially relevant for
+overlays and downstream distributions.  Since a banned EAPI is
 sufficient reason for updating an ebuild, an additional threshold of
 5 % is required, in order to keep the number of such updates (and bug
 reports requesting them) manageable.

Reply via email to