docs: move source-code-management.txt to README

source-code-management.txt and README had similar content so combine
them in README.

Change Documentation/source-code-management.txt references to README.

Remove Documentation/source-code-management.txt.

Move IRC Channel information to README

Expand information about git branches and tags in README.

Add workflow to README; written by Karel Zak <kzak@redhat.com>

Signed-off-by: J William Piggott <elseifthen@gmx.com>

3 files changed, 5 insertions, 53 deletions

diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index fc2c50330..71b9ed771 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -5,17 +5,16 @@ CONTENTS
  Coding Style
  Various Notes
  Standards Compliance
- IRC Channel
 
 Sending Patches
 
-	* send your patches to the mailing list or to the project maintainer.
+	* send your patches to the mailing list.
 	  See ../README.
 
 	* email is accepted as an inline patch with, or without, a git pull
 	  request. Pull request emails need to include the patch set for review
-	  purposes. See howto-pull-request.txt and source-code-management.txt
-	  for git repository instructions.
+	  purposes. See howto-pull-request.txt and ../README for git repository
+	  instructions.
 
 	* email attachments are difficult to review and not recommended.
 	  Hint: use git send-email.
@@ -64,7 +63,7 @@ Patching Process
 	  Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
 
 	* using a git repository for (re)submissions can make life easier.
-	  See howto-pull-request.txt and source-code-management.txt.
+	  See howto-pull-request.txt and ../README.
 
 	* all patch submissions are either commented, rejected, or accepted.
 	  If the maintainer rejects a patch set it is pointless to resubmit it.
@@ -190,12 +189,3 @@ Standards Compliance
 
 		http://pubs.opengroup.org/onlinepubs/7908799/xcuix.html
 
-IRC Channel
-
-	* #util-linux at freenode.net:
-
-	  irc://chat.freenode.net/util-linux
-
-	  This channel is for developers and project maintainers. For end users
-	  it is recommended to utilize the distribution's IRC channel or support
-	  forum.
diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt
index 728de4d4d..0e126948d 100644
--- a/Documentation/release-schedule.txt
+++ b/Documentation/release-schedule.txt
@@ -39,4 +39,4 @@ For all releases it is required that:
 See also
 --------
 
-Documentation/source-code-management.txt
+../README
diff --git a/Documentation/source-code-management.txt b/Documentation/source-code-management.txt
deleted file mode 100644
index ffa90d055..000000000
--- a/Documentation/source-code-management.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-SCM (source code management):
-
-    Primary repository:
-	git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
-
-    Backup repository:
-	git clone git://github.com/karelzak/util-linux.git
-
-Note that GitHub repository may contain temporary development branches too.
-
-The kernel.org repository contains master (current development) and stable/*
-(maintenance) branches only. All master or stable/* changes are always pushed
-to the both repositories in the same time.
-
-Branches:
-
-    * maintenance (stable) branch
-	- created for every <major>.<minor> release
-	- branch name: stable/v<major>.<minor>
-
-    * master branch
-	- the status of this branch is: "it works for me". It
-	  means useful but not well tested patches.
-	- it's source for occasional snapshots
-	- for long-term development or invasive changes should be
-	  an active development forked into a separate branch
-	  (topic branches) from the tip of "master".
-
-Tags:
-
-    * A new tag object is created for:
-	- every release, tag name: v<version>, see "git tag -l" for
-          more information
-        - all tags are signed by maintainer's PGP key
-
-    * KNOWN BUGS:
-	- don't use tag v2.13.1 (created and published by mistake),
-          use v2.13.1-REAL.