docs: integrate release-schedule.txt into HOWTO-CONTRIBUTING.md

Move the release schedule and RC cadence information into the
HOWTO-CONTRIBUTING.md file. Drop the "Release criteria" section
as tests should always pass regardless of release status.

Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/Documentation/HOWTO-CONTRIBUTING.md b/Documentation/HOWTO-CONTRIBUTING.md
index 1d2d6c54991249b0781433fd2502808dc110120e..93c2e2be8515cc5cf1e9e36c1fdd2e98a8a7c6ed 100644 (file)
--- a/Documentation/HOWTO-CONTRIBUTING.md
+++ b/Documentation/HOWTO-CONTRIBUTING.md
@@ -19,6 +19,18 @@ Branches:
 
 Since version 2.40, stabilization is done exclusively in `stable/` branches.
 
+## Release Schedule
+
+The versioning scheme is `<major>.<minor>.<maintenance>`. The minor version
+is incremented roughly twice per year.
+
+Before each release there are typically two release candidates:
+
+- `rc1` (1-2 weeks) — bug fixes only
+- `rc2` (1-2 weeks) — translations, fatal/trivial bug fixes
+
+The period between a release and the next rc1 is the merge window.
+
 ## Sending Patches
 
 - Send patches via GitHub pull request (recommended) or to the mailing

diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt
deleted file mode 100644 (file)
index cca3bca..0000000
--- a/Documentation/release-schedule.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Release schedule
-----------------
-
-The util-linux package uses the <major>.<minor>.<maintenance> 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 the next release candidate can be considered
-as the merge window.
-
-The release tarball is generated by "make distcheck" command.
-
-Release criteria
-----------------
-
-For all releases it is required that:
-
-   - 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: a build with uClibc works, and --with-slang works
-
-See also
---------
-
-../README