Adding upstream version 2.39.3.upstream/2.39.3

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 146 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..b7c723d
--- /dev/null
+++ b/README
@@ -0,0 +1,146 @@
+
+				  util-linux
+
+		util-linux is a random collection of Linux utilities
+
+     Note: for the years 2006-2010 this project was named "util-linux-ng".
+
+COMPILE & INSTALL:
+
+      See Documentation/howto-compilation.txt.
+
+MAILING LIST:
+
+      E-MAIL:  util-linux@vger.kernel.org
+      URL:     http://vger.kernel.org/vger-lists.html#util-linux
+      ARCHIVE: https://lore.kernel.org/util-linux/
+
+      The mailing list will reject email messages that contain:
+       - more than 100K characters
+       - html
+       - spam phrases/keywords
+      See: http://vger.kernel.org/majordomo-info.html#taboo
+
+IRC CHANNEL:
+
+      #util-linux at libera.chat:
+
+      irc://irc.libera.chat/util-linux
+
+      The IRC channel and Mailing list are for developers and project
+      maintainers. For end users it is recommended to utilize the
+      distribution's support system.
+
+BUG REPORTING:
+
+      E-MAIL: util-linux@vger.kernel.org
+      Web:    https://github.com/util-linux/util-linux/issues
+
+      Bug reports with sensitive or private information: Karel Zak <kzak@redhat.com>
+
+      This project has no resources to provide support for distribution specific
+      issues. For end users it is recommended to utilize the distribution's
+      support system.
+
+NLS (PO TRANSLATIONS):
+
+      PO files are maintained by:
+	  https://translationproject.org/domain/util-linux.html
+
+VERSION SCHEMA:
+
+      Standard releases:
+	  <major>.<minor>[.<maint>]
+	     major = fatal and deep changes
+	     minor = typical release with new features
+	     maint = maintenance releases; bug fixes only
+
+      Development releases:
+	 <major>.<minor>-rc<N>
+
+SOURCE CODE:
+
+ Download archive:
+	  https://www.kernel.org/pub/linux/utils/util-linux/
+
+ See also:
+     Documentation/howto-contribute.txt
+     Documentation/howto-build-sys.txt
+     Documentation/howto-pull-request.txt
+
+ SCM (Source Code Management) Repository:
+
+    Primary repository:
+	  git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
+
+    Backup repository:
+	  git clone https://github.com/util-linux/util-linux.git
+
+    Web interfaces:
+	  https://git.kernel.org/cgit/utils/util-linux/util-linux.git
+	  https://github.com/util-linux/util-linux
+
+      Note: the 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 both repositories at the same time.
+
+    Repository Branches: 'git branch -a'
+	  master branch
+	   - current development
+	   - the source for stable releases when deemed ready.
+	   - day-to-day status is: 'it works for me'. This means that its
+	     normal state is useful but not well tested.
+	   - long-term development or invasive changes in active development are
+	     forked into separate 'topic' branches from the tip of 'master'.
+
+	  stable/ branches
+	   - public releases
+	   - branch name: stable/v<major>.<minor>.
+	   - created from the 'master' branch after two or more release
+	     candidates and the final public release. This means that the stable
+	     releases are committed, tagged, and reachable in 'master'.
+	   - these branches then become forked development branches. This means
+	     that any changes made to them diverge from the 'master' branch.
+	   - maintenance releases are part of, and belong to, their respective
+	     stable branch. As such, they are tags(<major>.<minor>.<maint>) and
+	     not branches of their own. They are not part of, visible in, or
+	     have anything to do with the 'master' development branch. In git
+	     terminology: maintenance releases are not reachable from 'master'.
+	   - when initially cloned (as with the 'git clone' command given above)
+	     these branches are created as 'remote tracking branches' and are
+	     only visible by using the -a or -r options to 'git branch'. To
+	     create a local branch use the desired tag with this command:
+	     'git checkout -b v2.29.2 v2.29.2'
+
+    Tags: 'git tag'
+	   - a new tag object is created for every release.
+	   - tag name: v<version>.
+	   - all tags are signed by the maintainer's PGP key.
+
+    Known Bugs:
+	- don't use tag v2.13.1 (created and published by mistake),
+	  use v2.13.1-REAL instead.
+
+WORKFLOW EXAMPLE:
+
+ 1) development (branch: <master>)
+
+ 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
+
+ 3) development (work on v2.30, branch: <master>)
+
+ 4) fork -- create a new branch <stable/v2.29> based on tag v2.29
+
+     4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
+
+     4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
+
+     4c) more patches; another release (tag: v2.29.2, branch: <stable/v2.29>)
+
+ 5) master release v2.30 (branch: <master>)
+    ...
+
+where 3) and 4) happen simultaneously.
+