From: Benno Schulenberg <bensberg@justemail.net>
Date: Sat, 5 Oct 2013 16:08:59 +0000 (+0200)
Subject: docs: improve grammar and wording of the release-schedule text
X-Git-Tag: v2.24-rc2~31
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=55fb046138ab563c2e03403c270960c06daa921b;p=thirdparty%2Futil-linux.git

docs: improve grammar and wording of the release-schedule text

Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
---

diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt
index 6077735b14..8f5b3ad57c 100644
--- a/Documentation/release-schedule.txt
+++ b/Documentation/release-schedule.txt
@@ -1,37 +1,38 @@
 Release schedule
 ----------------
 
-The util-linux uses <major>.<minor>.<maint> version numbering.
-Since the major version is pretty much fixed the release means an
-upgrade of minor number. Minor version is update roughly twice
-per year. Easiest way to estimate when next version will occur is
-to see time stamp of previous release.
-
-Before a release there are few release candidates, which will be
-collectively tested. During test period changes to code base are
-restricted. Usually there are two release candidates.
-
-  what	 length		what will be accepted to upstream
-  -------------------------------------------------------
+The util-linux package uses the <major>.<minor>.<maintenaince> version
+numbering scheme.  Since the major version is pretty much fixed, any
+release means an increment of the minor number.  The minor version is
+incremented roughly twice per year.  The easiest way to estimate when
+the next version will appear, is to look at the time stamp of the last
+release.
+
+Before each release there are a few release candidates, which will be
+collectively tested.  During the test period changes to the code base
+are restricted.  Usually there are two release candidates.
+
+  what	 length		what will be accepted into upstream
+  ---------------------------------------------------------
   rc1	 1-2 weeks	bug fixes only
   rc2	 1-2 weeks	translations, fatal/trivial bug fixes
 
-The period between a release and next release candidate can be considered as
-merge window.
+The period between a release and the next release candidate can be considered
+as the merge window.
 
 Release criteria
 ----------------
 
-For all releases is required:
+For all releases it is required that:
 
-   - make checkincludes pass
-   - make checkconfig pass
-   - make distcheck pass
-   - cd tests && ./run.sh pass
-   - out-of-tree build works
-     cd .. && mkdir build && cd build && ../util-linux/configure && make
+   - make checkincludes passes
+   - make checkconfig passes
+   - make distcheck passes
+   - cd tests && ./run.sh passes
+   - an out-of-tree build works
+     (cd .. && mkdir build && cd build && ../util-linux/configure && make)
 
-   - ideally: build with uClibc, --with-slang
+   - ideally: a build with uClibc works, and --with-slang works
 
 See also
 --------