* [PATCH 1/4] docs: update v2.30-ReleaseNotes
2017-05-31 18:45 [PATCH 0/4] pull request J William Piggott
@ 2017-05-31 18:50 ` J William Piggott
2017-05-31 18:51 ` [PATCH 2/4] docs: update howto-contribute.txt J William Piggott
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: J William Piggott @ 2017-05-31 18:50 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
Documentation/releases/v2.30-ReleaseNotes | 38 ++++++++++++++++---------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/Documentation/releases/v2.30-ReleaseNotes b/Documentation/releases/v2.30-ReleaseNotes
index 3702178..f9a45a1 100644
--- a/Documentation/releases/v2.30-ReleaseNotes
+++ b/Documentation/releases/v2.30-ReleaseNotes
@@ -1,39 +1,41 @@
-Util-linux 2.30 Release Notes
-=============================
+Util-linux 2.30 Release Notes
+=============================
-The libblkid library has been fixed to extract LABEL= and UUID= from UDF
-rather than from ISO9660 header on hybrid CDROM/DVD media. This changes
-makes UDF media on Linux user-space more compatible with another operation
-systems. Unfortunately, this change may introduce regression for (unusual)
-hybrid CDROM/DVDs where ISO and UDF use a different LABEL=.
+The libblkid library has been improved for hybrid CDROM/DVD media by extracting
+the LABEL and UUID values from the UDF header, rather than the ISO9660 header.
+This change makes hybrid CDROM/DVD media created on other operating systems more
+compatible in Linux user-space. Unfortunately, this change may introduce a
+regression for (unusual) hybrid CDROM/DVDs where the ISO and UDF headers use a
+different LABEL.
The deprecated command tailf has been removed. Use "tail -f" from coreutils.
-blkzone -- NEW COMMAND to run zone commands on block device that support Zoned
+blkzone -- NEW COMMAND to run zone commands on block devices that support Zoned
Block Commands (ZBC) or Zoned-device ATA Commands (ZAC). The currently
supported functionality is 'report' and 'reset'.
[thanks to Shaun Tancheff (Seagate), Damien Le Moal (WD)]
-fincore -- NEW COMMAND to count pages of file contents in core (memory).
+fincore -- NEW COMMAND to count pages of file contents in core (memory).
[thanks to Masatake YAMATO (Red Hat)]
lsmem -- NEW COMMAND to list the ranges of available memory with their online
-status (originally implemented in Perl for s390-tools). [thanks to Clemens von Mann
+status (originally implemented in Perl for s390-tools). [thanks to Clemens von Mann
and Heiko Carstens (IBM)]
chmem -- NEW COMMAND to set memory online/offline status [thanks to Heiko
Carstens (IBM)]
-The old and dead Alpha and Cmos code has been removed from hwclock command.
+Removed Alpha and dead code from hwclock's --directisa option.
-The command fallocate supports "insert range" operation now.
+The command fallocate supports an "insert range" operation now.
-The command "column -t|--table" has been modified to use libsmartcols. Now it
-provides almost all functionality of the library on command line, for example
-print header for table, reorder columns, align columns to the right, print
-tree-like output, wrap lines in cells, truncate text in cells, etc.
+The command "column -t|--table" has been modified to use libsmartcols. It now
+provides nearly all of that library's functionality from the command line. For
+example: printing a table header, reordering columns, aligning columns
+to the right, printing tree-like output, wrapping lines in cells, truncating
+text in cells, etc.
-The libmount library provides API to generate exit codes and error/warning
+The libmount library now provides an API to generate exit codes and error/warning
messages compatible with mount(8).
@@ -48,7 +50,7 @@ CVE-2016-2779 - This security issue is NOT FIXED yet. It is possible to
disable the ioctl TIOCSTI by setsid() only. Unfortunately, setsid()
has well-defined use cases in su(1) and runuser(1) and any changes
would introduce regressions. It seems we need a better way -- ideally
- another ioctl to disable TIOCSTI without setsid() or in userspace
+ another ioctl to disable TIOCSTI without setsid() or in a userspace
implemented pty container (planned as experimental su(1) feature).
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 2/4] docs: update howto-contribute.txt
2017-05-31 18:45 [PATCH 0/4] pull request J William Piggott
2017-05-31 18:50 ` [PATCH 1/4] docs: update v2.30-ReleaseNotes J William Piggott
@ 2017-05-31 18:51 ` J William Piggott
2017-05-31 18:53 ` [PATCH 3/4] " J William Piggott
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: J William Piggott @ 2017-05-31 18:51 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
Grammar fixes and some clarification changes.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
Documentation/howto-contribute.txt | 154 +++++++++++++++++++------------------
1 file changed, 81 insertions(+), 73 deletions(-)
diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index 6d3e789..729f4cb 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -1,43 +1,50 @@
Patches
- * send your patches to the mailing list or to the upstream maintainer
- (see the README file in project root directory).
+ * send your patches to the mailing list or to the project maintainer.
+ See ../README.
- * don't include generated (autotools) stuff to your patches (hint:
- use git clean -Xd)
+ * don't include generated (autotools) files in your patches.
+ Hint: use 'git clean -Xd'.
- * neutrality; The stuff in util-linux should be rather
- distribution-neutral. No RPMs/DEBs/... are provided - get yours
- from your distributor.
+ * neutrality: the files in util-linux should be distribution-neutral.
+ Packages like RPMs, DEBs, and the rest, are not provided. They should
+ be available from the distribution.
- * patches are delivered via email or git remote repository only.
- Downloading them from internet servers is a pain. See
- howto-pull-request.txt for remote repository instructions.
+ * 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.
- * one patch per email, with the changelog in the body of the email.
+ * one patch per email.
+ See Email Format.
- * mail attachments are difficult. Tip:
- git send-email --to util-linux@vger.kernel.org origin/master..yourbranch
+ * email attachments are difficult to review and not recommended.
+ Hint: use 'git send-email'.
- * many small patches are favoured over one big. Break down is done on
- basis of logical functionality; for example #endif mark ups,
- compiler warning and exit codes fixes all should be individual
+ * many small patches are preferred over a single large patch. Split
+ patch sets based upon logical functionality. For example: #endif mark
+ ups, compiler warnings, and exit code fixes should all be individual
small patches.
- * 'Subject: [PATCH] subsystem: description'. See also 'Patching
- process'.
+Email Format
+
+ * Subject: [PATCH] subsystem: description.
+
+ * Start the message body with an explanation of the patch, that is, a
+ changelog/commit entry.
* if someone else wrote the patch, they should be credited (and
- blamed) for it. To communicate this, add a line:
+ blamed) for it. To communicate this, add a line like:
From: John Doe <jdoe@wherever.com>
- * add a Signed-off-by line (hint: use "git commit -s")
+ * add a Signed-off-by line.
+ Hint: use git commit -s
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the
right to pass it on as a open-source patch. The rules are pretty
- simple: if you can certify the below:
+ simple; if you can certify the following:
By making a contribution to this project, I certify that:
@@ -64,92 +71,94 @@ Patches
consistent with this project or the open source license(s)
involved.
- then you just add a line saying
+ Then you just add a line like:
Signed-off-by: Random J Developer <random@developer.example.org>
- using your real name (sorry, no pseudonyms or anonymous
- contributions.)
+ Use your real name (sorry, no pseudonyms or anonymous contributions.)
+
+ * Next a single line beginning with three hyphen-minus characters (---)
+ and nothing else.
+
+ * Followed by the unified diff patch.
Before sending a patch
- * make sure that after patching source files will compile without
- errors.
+ * make sure that after applying your patch the file(s) will compile
+ without errors.
- * test that previously existed program behavior is not
- unintentionally alterred. If you alter the behavior tell about
- it in commit message.
+ * test that the previously existing program behavior is not altered. If
+ the patch intentionally alters the behavior explain what changed, and
+ the reason for it, in the changelog/commit message.
Coding style
- * the preferred coding style is based on the linux kernel
- Documentation/CodingStyle. For more details see:
+ * the preferred coding style is based on the linux kernel coding-style.
+ Available here:
- http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle
+ http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/coding-style.rst
- * Use `FIXME:' and a good description if want to inform others
- something is not quite right, and you are unwilling to fix the
+ * use 'FIXME:' with a good description, if you want to inform others
+ that something is not quite right, and you are unwilling to fix the
issue in the submitted change.
Patching process
- * Tell in mail list when you are going to work with some particular
- piece of code for long time. This helps other to avoid massive
- merge conflicts. Small or quick work does not need to be
+ * announce it on the mailing list when you are going to work with some
+ particular piece of code for a long time. This helps others to avoid
+ massive merge conflicts. Small or quick work, does not need to be
announced.
- * Submit only changes that you think are ready to merge. If you only
- want change review tell your intention clearly in change cover
- letter, and/or in each patch subject to review-only.
+ * only submit changes that you believe are ready to merge. To post a
+ patch for peer review only, state it clearly in the email and use
+ the Subject: [PATCH RFC] ...
- * When getting comments align the changes with them. Resubmission
- without changes is as good as ignoring advice, and is neither
- recommended nor polite.
+ * incorporate reviewer comments in the patches. Resubmitting without
+ changes is neither recommended nor polite.
- * Resubmission can be partial or complete. If only few alterations
- are needed here and there resubmit particular patches. When
- comments cause greater effect resubmit everything again.
+ * resubmission can be partial or complete. If only a few alterations are
+ needed then resubmit those particular patches. When comments cause a
+ greater effect then resubmit the entire patch set.
- * Mark resubmission with [PATCH v2]. Hint:
- git format-patch origin/master..yourbranch --subject-prefix='PATCH v2'
+ * When resubmitting use the email Subject: [PATCH v2] ...
+ Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
- * Use of remote repository for resubmission can be good idea.
- See also howto-pull-request.txt
+ * using a git repository for (re)submissions can make life easier.
+ See howto-pull-request.txt and source-code-management.txt.
- * All patch submissions, big or small, are either commented, reject,
- or merge. When maintainer rejects a patch (series) it is pointless
- to resubmit.
+ * all patch submissions are either commented, rejected, or accepted.
+ If the maintainer rejects a patch set it is pointless to resubmit it.
Various notes
- * The util-linux does not use kernel headers for file system super
+ * util-linux does not use kernel headers for file system super
blocks structures.
- * Patches relying on features that are not in Linus' tree
- are not accepted.
+ * patches relying on kernel features that are not in Linus Torvalds's
+ tree are not accepted.
- * Do not use `else' after non-returning functions. For
- example
+ * do not use `else' after non-returning functions. For
+ example:
if (this)
err(EXIT_FAIL, "this failed");
else
err(EXIT_FAIL, "that failed");
- is wrong and should be wrote
+ Is wrong and should be written:
if (this)
err(EXIT_FAIL, "this failed");
err(EXIT_FAIL, "that failed");
- * When you use if shortshort hand make sure it is not wrapped to
- multiple lines. In case the shorthand does not look good on one
- line use normal "if () else" syntax.
+ * when you use 'if' short-shorthand make sure it does not wrap into
+ multiple lines. In case the shorthand does not look good on one line
+ use the normal "if () else" syntax.
-Standards compliancy
+Standards compliance
Some of the commands maintained in this package have Open Group
- requirements. These commands are;
+ requirements. These commands are:
cal
col
@@ -164,11 +173,10 @@ Standards compliancy
pg
renice
- If you change these tools please make sure a change does not
- conflict with the latest standard. For example it is
- recommendable not to add short command line options before they
- are part of standard. Introducing new long options is
- acceptable.
+ If you change these tools please make sure it does not create a conflict
+ with the latest standard. For example, it is not recommended to add
+ short command line options before they are part of the standard.
+ Introducing new long options is acceptable.
The Single UNIX(TM) Specification, Version 2
Copyright (C) 1997 The Open Group
@@ -177,10 +185,10 @@ Standards compliancy
IRC channel
- * We have a new #util-linux IRC channel at freenode.net.
+ * #util-linux at freenode.net:
irc://chat.freenode.net/util-linux
- the channel is for developers or upstream maintainers. User
- support is recommended to go to distribution channels or
- forums.
+ This channel is for developers and project maintainers. For end users
+ it is recommended to utilize the distribution's IRC channel or support
+ forum.
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 3/4] docs: update howto-contribute.txt
2017-05-31 18:45 [PATCH 0/4] pull request J William Piggott
2017-05-31 18:50 ` [PATCH 1/4] docs: update v2.30-ReleaseNotes J William Piggott
2017-05-31 18:51 ` [PATCH 2/4] docs: update howto-contribute.txt J William Piggott
@ 2017-05-31 18:53 ` J William Piggott
2017-05-31 18:54 ` [PATCH 4/4] docs: move source-code-management.txt to README J William Piggott
2017-06-01 8:54 ` [PATCH 0/4] pull request Karel Zak
4 siblings, 0 replies; 6+ messages in thread
From: J William Piggott @ 2017-05-31 18:53 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
This patch does not change any wording or grammar. It
only shuffles the order of things and adds a table of
contents. For example: it moves coding related bullet
points into the Coding Style Chapter; it groups email
related Chapters together, and so fourth.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
Documentation/howto-contribute.txt | 123 ++++++++++++++++++++-----------------
1 file changed, 65 insertions(+), 58 deletions(-)
diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index 729f4cb..fc2c503 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -1,31 +1,74 @@
-Patches
+CONTENTS
+ Sending Patches
+ Patching Process
+ Email Format
+ Coding Style
+ Various Notes
+ Standards Compliance
+ IRC Channel
+
+Sending Patches
* send your patches to the mailing list or to the project maintainer.
See ../README.
- * don't include generated (autotools) files in your patches.
- Hint: use 'git clean -Xd'.
-
- * neutrality: the files in util-linux should be distribution-neutral.
- Packages like RPMs, DEBs, and the rest, are not provided. They should
- be available from the distribution.
-
* 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.
+ * email attachments are difficult to review and not recommended.
+ Hint: use git send-email.
+
* one patch per email.
See Email Format.
- * email attachments are difficult to review and not recommended.
- Hint: use 'git send-email'.
-
* many small patches are preferred over a single large patch. Split
patch sets based upon logical functionality. For example: #endif mark
ups, compiler warnings, and exit code fixes should all be individual
small patches.
+ * don't include generated (autotools) files in your patches.
+ Hint: use 'git clean -Xd'.
+
+ * neutrality: the files in util-linux should be distribution-neutral.
+ Packages like RPMs, DEBs, and the rest, are not provided. They should
+ be available from the distribution.
+
+Patching Process
+
+ * announce it on the mailing list when you are going to work with some
+ particular piece of code for a long time. This helps others to avoid
+ massive merge conflicts. Small or quick work, does not need to be
+ announced.
+
+ * make sure that after applying your patch the file(s) will compile
+ without errors.
+
+ * test that the previously existing program behavior is not altered. If
+ the patch intentionally alters the behavior explain what changed, and
+ the reason for it, in the changelog/commit message.
+
+ * only submit changes that you believe are ready to merge. To post a
+ patch for peer review only, state it clearly in the email and use
+ the Subject: [PATCH RFC] ...
+
+ * incorporate reviewer comments in the patches. Resubmitting without
+ changes is neither recommended nor polite.
+
+ * resubmission can be partial or complete. If only a few alterations are
+ needed then resubmit those particular patches. When comments cause a
+ greater effect then resubmit the entire patch set.
+
+ * When resubmitting use the email Subject: [PATCH v2] ...
+ 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.
+
+ * all patch submissions are either commented, rejected, or accepted.
+ If the maintainer rejects a patch set it is pointless to resubmit it.
+
Email Format
* Subject: [PATCH] subsystem: description.
@@ -82,16 +125,7 @@ Email Format
* Followed by the unified diff patch.
-Before sending a patch
-
- * make sure that after applying your patch the file(s) will compile
- without errors.
-
- * test that the previously existing program behavior is not altered. If
- the patch intentionally alters the behavior explain what changed, and
- the reason for it, in the changelog/commit message.
-
-Coding style
+Coding Style
* the preferred coding style is based on the linux kernel coding-style.
Available here:
@@ -102,41 +136,6 @@ Coding style
that something is not quite right, and you are unwilling to fix the
issue in the submitted change.
-Patching process
-
- * announce it on the mailing list when you are going to work with some
- particular piece of code for a long time. This helps others to avoid
- massive merge conflicts. Small or quick work, does not need to be
- announced.
-
- * only submit changes that you believe are ready to merge. To post a
- patch for peer review only, state it clearly in the email and use
- the Subject: [PATCH RFC] ...
-
- * incorporate reviewer comments in the patches. Resubmitting without
- changes is neither recommended nor polite.
-
- * resubmission can be partial or complete. If only a few alterations are
- needed then resubmit those particular patches. When comments cause a
- greater effect then resubmit the entire patch set.
-
- * When resubmitting use the email Subject: [PATCH v2] ...
- 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.
-
- * all patch submissions are either commented, rejected, or accepted.
- If the maintainer rejects a patch set it is pointless to resubmit it.
-
-Various notes
-
- * util-linux does not use kernel headers for file system super
- blocks structures.
-
- * patches relying on kernel features that are not in Linus Torvalds's
- tree are not accepted.
-
* do not use `else' after non-returning functions. For
example:
@@ -155,7 +154,15 @@ Various notes
multiple lines. In case the shorthand does not look good on one line
use the normal "if () else" syntax.
-Standards compliance
+Various Notes
+
+ * util-linux does not use kernel headers for file system super
+ blocks structures.
+
+ * patches relying on kernel features that are not in Linus Torvalds's
+ tree are not accepted.
+
+Standards Compliance
Some of the commands maintained in this package have Open Group
requirements. These commands are:
@@ -183,7 +190,7 @@ Standards compliance
http://pubs.opengroup.org/onlinepubs/7908799/xcuix.html
-IRC channel
+IRC Channel
* #util-linux at freenode.net:
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 4/4] docs: move source-code-management.txt to README
2017-05-31 18:45 [PATCH 0/4] pull request J William Piggott
` (2 preceding siblings ...)
2017-05-31 18:53 ` [PATCH 3/4] " J William Piggott
@ 2017-05-31 18:54 ` J William Piggott
2017-06-01 8:54 ` [PATCH 0/4] pull request Karel Zak
4 siblings, 0 replies; 6+ messages in thread
From: J William Piggott @ 2017-05-31 18:54 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
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>
---
Documentation/howto-contribute.txt | 18 +----
Documentation/release-schedule.txt | 2 +-
Documentation/source-code-management.txt | 38 ----------
README | 121 +++++++++++++++++++++++--------
4 files changed, 96 insertions(+), 83 deletions(-)
delete mode 100644 Documentation/source-code-management.txt
diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index fc2c503..71b9ed7 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 728de4d..0e12694 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 ffa90d0..0000000
--- 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.
diff --git a/README b/README
index 803f5dd..81e0504 100644
--- a/README
+++ b/README
@@ -1,67 +1,128 @@
- util-linux
+ util-linux
- util-linux is a random collection of Linux utilities
+ util-linux is a random collection of Linux utilities
- Note that in years 2006-2010 this project used the name "util-linux-ng".
+ Note: for the years 2006-2010 this project was named "util-linux-ng".
MAILING LIST:
E-MAIL: util-linux@vger.kernel.org
URL: http://vger.kernel.org/vger-lists.html#util-linux
+IRC CHANNEL:
-DOWNLOAD:
+ #util-linux at freenode.net:
- https://www.kernel.org/pub/linux/utils/util-linux/
+ irc://chat.freenode.net/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/karelzak/util-linux/issues
- Note that upstream community has no resources to provide support for end
- users with distribution specific issues. It's strongly recommended to
- report bugs to the distribution (downstream) maintainers by distribution
- bug tracking systems.
+ 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.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:
- See also Documentation/howto-contribute.txt
- Documentation/source-code-management.txt
+ Download archive:
+ https://www.kernel.org/pub/linux/utils/util-linux/
+
+ SCM (Source Code Management) Repository:
- Web interface:
- http://git.kernel.org/cgit/utils/util-linux/util-linux.git
- https://github.com/karelzak/util-linux
+ Primary repository:
+ git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
- Checkout:
- 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.
+ Web interfaces:
+ http://git.kernel.org/cgit/utils/util-linux/util-linux.git
+ https://github.com/karelzak/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 the both repositories in the same time.
+ 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'.
-NLS (PO TRANSLATIONS):
+ 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'
- PO files are maintained by:
- http://translationproject.org/domain/util-linux.html
+ 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.
-VERSION SCHEMA:
+WORKFLOW EXAMPLE:
- Standard releases:
+ 1) development (branch: <master>)
- <major>.<minor>[.<maint>[.<bugfix>]]
+ 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
- major = fatal and deep changes
- minor = typical release with new features
- maint = maintenance releases; bug fixes only
- bugfix = unplanned releases for critical/security bugs
+ 3) development (work on v2.30, branch: <master>)
- Development releases:
+ 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.
- <major>.<minor>-rc<N>
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 0/4] pull request
2017-05-31 18:45 [PATCH 0/4] pull request J William Piggott
` (3 preceding siblings ...)
2017-05-31 18:54 ` [PATCH 4/4] docs: move source-code-management.txt to README J William Piggott
@ 2017-06-01 8:54 ` Karel Zak
4 siblings, 0 replies; 6+ messages in thread
From: Karel Zak @ 2017-06-01 8:54 UTC (permalink / raw)
To: J William Piggott; +Cc: util-linux
On Wed, May 31, 2017 at 02:45:23PM -0400, J William Piggott wrote:
> git@github.com:jwpi/util-linux.git 170529
Applied, thanks.
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread