]> git.ipfire.org Git - thirdparty/util-linux.git/blobdiff - README
lscpu: add --bytes
[thirdparty/util-linux.git] / README
diff --git a/README b/README
index 13d13e3a173d5e5359497503d9724daba91f06ef..7f07d7d3ff2218e787b45a567c4e76c69b537d10 100644 (file)
--- a/README
+++ b/README
 
-                          util-linux-ng
-           (fork of util-linux, based on version 2.13-pre7)
+                                 util-linux
 
-         util-linux is a random collection of Linux utilities
+               util-linux is a random collection of Linux utilities
 
-WEB PAGE:
+     Note: for the years 2006-2010 this project was named "util-linux-ng".
 
-     http://kernel.org/~kzak/util-linux-ng/
+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/
 
-MAILING LIST:
+      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
 
-      E-MAIL: util-linux-ng@vger.kernel.org
-      URL:    http://vger.kernel.org/vger-lists.html#util-linux-ng
+IRC CHANNEL:
 
+      #util-linux at freenode.net:
 
-DOWNLOAD:
+      irc://chat.freenode.net/util-linux
 
-      ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
+      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:
 
-SOURCE CODE:
+      E-MAIL: util-linux@vger.kernel.org
+      Web:    https://github.com/karelzak/util-linux/issues
 
-      Web interface:
-          http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git
-      Checkout:
-          git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng
+      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:
-          http://translationproject.org/domain/util-linux-ng.html
+         http://translationproject.org/domain/util-linux.html
 
-NEUTRALITY:
+VERSION SCHEMA:
 
-      The stuff in util-linux-ng should be rather distribution-neutral.
-      No RPMs/DEBs/... are provided - get yours from your distributor.
+      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>
 
-VERSION SCHEMA:
+SOURCE CODE:
 
-      Standard releases:
+ Download archive:
+         https://www.kernel.org/pub/linux/utils/util-linux/
 
-          <major>.<minor>[.<maint>[.<bugfix>]]
+ SCM (Source Code Management) Repository:
 
-             major = fatal and deep changes
-             minor = typical release with new fetures
-             maint = maintenance releases; bug fixes only
-             bugfix = unplanned releases for critical/security bugs
+    Primary repository:
+         git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
 
-      Development releases:
+    Backup repository:
+         git clone git://github.com/karelzak/util-linux.git
 
-         <major>.<minor><suffix>
+    Web interfaces:
+         http://git.kernel.org/cgit/utils/util-linux/util-linux.git
+         https://github.com/karelzak/util-linux
 
-             suffix = "devel" or "-rc<N>"
+      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.
 
-COMPILATION:
+    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'.
 
-      See the INSTALL file for more details.
+         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'
 
-      Notes:
-            * use SUID_CFLAGS and SUID_LDFLAGS when you want to define special
-              compiler options for typical suid programs, for example:
+    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.
 
-                  ./configure SUID_CFLAGS="-fpie" SUID_LDFLAGS="-pie"
+    Known Bugs:
+       - don't use tag v2.13.1 (created and published by mistake),
+         use v2.13.1-REAL instead.
 
-              This feature is currently supported for chfn, chsh, newgrp,
-              write, mount, and umount.
+WORKFLOW EXAMPLE:
 
+ 1) development (branch: <master>)
 
-STATIC LINKING:
+ 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
 
-      Use --enable-static-programs[=LIST] configure option when you want to use
-      statically linked programs.
+ 3) development (work on v2.30, branch: <master>)
 
-      Note, mount(8) uses get{pw,gr}nam() and getpwuid() functions for
-      translation from username and groupname to UID and GID. These functions
-      could be implemented by dynamically loaded independent modules (NSS) in
-      your libc (e.g. glibc). These modules are not statically linked to
-      mount(8) and mount.static is still using dlopen() like dynamically
-      linked version.
+ 4) fork -- create a new branch <stable/v2.29> based on tag v2.29
 
-      The translation won't work in environment where NSS modules are
-      not installed.
+     4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
 
-      For example normal system (NSS modules are available):
+     4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
 
-              # ./mount.static -v -f -n -ouid=kzak /mnt/foo
-              LABEL=/mnt/foo on /mnt/foo type vfat (rw,uid=500)
-                                                       ^^^^^^^
-      and without NSS modules:
+     4c) more patches; another release (tag: v2.29.2, branch: <stable/v2.29>)
 
-              # chroot . ./mount.static -v -f -n -ouid=kzak /mnt/win
-              LABEL=/mnt/win on /mnt/win type vfat (rw,uid=kzak)
-                                                       ^^^^^^^^
+ 5) master release v2.30 (branch: <master>)
+    ...
 
+where 3) and 4) happen simultaneously.