Adding upstream version 2.39.3.upstream/2.39.3

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

1 files changed, 296 insertions, 0 deletions

diff --git a/Documentation/howto-pull-request.txt b/Documentation/howto-pull-request.txt
new file mode 100644
index 0000000..752e60a
--- /dev/null
+++ b/Documentation/howto-pull-request.txt
@@ -0,0 +1,296 @@
+Introduction
+------------
+
+These instructions are wrote to contributors who tend to send lots of
+changes.  The basics from howto-contribute.txt file are assumed to be
+read and understood by the time this file becomes useful.
+
+
+Setup
+-----
+
+1. Find a git server that can be reached from anywhere in internet
+anonymously.  Github is for example a popular choice.
+
+2. Create your own util-linux contributor repository, and push an upstream
+clone to there.
+
+3. In these instructions the upstream remote repository is called
+'origin' and the 'yourgit' is the contributor repo.
+
+cd ~/projects
+git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
+cd util-linux
+git remote add yourgit git@github.com:yourlogin/util-linux.git
+git push yourgit
+
+
+Branches
+--------
+
+1. Use the name of the subsystem, such as blkid, libmount, misc-utils,
+that is the common thing for changes in the change set.
+
+2. If the changes do not have anything in common use some random name,
+such as YYYY-MM-DD of the first patch in the branch.  Name of the branch
+does not really matter that much, with one exception.
+
+3. Do not use 'master' branch to your contributions.  The 'master' branch
+is needed to stay up to date with upstream.
+
+4. When done push your branch to your remote git server.
+
+git checkout master
+git branch textual
+# spent here most of the effort
+git push yourgit textual:textual
+
+5. Do not worry if you used stupid-and-wrong branch name, it can be fixed
+before submission.
+
+git branch -m stupid-and-wrong brilliant
+git push yourgit brilliant:brilliant :stupid-and-wrong
+
+
+Stay up to date
+---------------
+
+1. Ensure you have the latest from all remote repositories.
+
+2. Merge upstream 'master' branch if needed to your local 'master'.
+
+3. Rebase your working contribution branches.
+
+4. Push the changes to 'yourgit'.
+
+git fetch --all
+git log --graph --decorate --pretty=oneline --abbrev-commit --all
+
+5. If you notice upstream has changed while you were busy with your
+changes rebase on top of the master, but before that:
+
+6. Push a backup of your branch 'textual' to 'yourgit', then
+
+git checkout master
+git merge origin/master
+git checkout textual
+git rebase master
+
+If rebase reports conflicts fix the conflicts.  In case the rebase
+conflict is difficult to fix rebase --abort is good option, or recover
+from 'yourgit', either way there is some serious re-work ahead with the
+change set.
+
+7. Assuming rebase went fine push the latest to 'yourgit'.
+
+git push yourgit master:master
+git push yourgit --force textual:textual
+
+The contributor branch tends to need --force every now and then, don't be
+afraid using it.
+
+8. Push error with master branch
+
+If 'master' needs --force then something is really messed up.  In that
+case it is probably the wise to abandon(*) local clone, and start all
+over from cloning upstream again.  Once the upstream is cloned add again
+'yourgit' remote and
+
+git push --mirror yourgit
+
+But be WARNED.  The --mirror will nuke all of your stuff had in
+'yourgit', that can cause data loss.  (*)So don't remove the local clone,
+just move the directory to broken repos area.
+
+
+Sending pull request
+--------------------
+
+1. When you are happy with your changes sleep over night.  This is not a
+speed competition, and for some reason looking the changes the next day
+often makes one to realize how things could be improved.  The best this
+way you avoid changing the changes (that is always confusing).
+
+2. Check the next day the changes compile without errors or warnings, and
+that regression tests run fine.
+
+make clean &&
+make -j3 &&
+make check
+
+Notice that regression tests will not cover all possible cases, so you
+most likely need to use the commands, features, and fixes you did
+manually.
+
+3. If you need to change something.
+
+git rebase -i master
+# change something
+git push -f yourgit textual:textual
+
+4. You have two ways how to send your pull request:
+
+4.1 Github pull request
+
+This is recommended way for your small and trivial changes, or for
+work-in-progress projects (rewrites, new commands, etc.). All you
+need is to press "pull request" button on GitHub.
+
+4.2. Send your work to the mailing list
+
+Assuming the changes look good send them to mail list.  Yes, the all
+of them!  Sending pull request with github is not visible for project
+contributors, and they will not have change to review your changes.
+
+Sending only the pull request, i.e., not each patch, to mail-list is also
+bad.  Nothing is as good as seeing the changes as they are, and being
+able to find them from with your favourite web search engine from
+mail-list archive.  Obviously the pull request content does not get
+indexed, and that is why it is worse.
+
+git format-patch --cover-letter master..textual
+git request-pull upstream/master https://github.com/yourlogin/util-linux.git textual > tempfile
+
+Take from the 'tempfile' the header:
+
+----------------------------------------------------------------
+The following changes since commit 17bf9c1c39b4f35163ec5c443b8bbd5857386ddd:
+
+  ipcrm: fix usage (2015-01-06 11:55:21 +0100)
+
+are available in the git repository at:
+
+  https://github.com/yourlogin/util-linux.git textual
+----------------------------------------------------------------
+
+and copy paste it to 0000-cover-letter.patch file somewhere near 'BLURB
+HERE'.  Rest of the 'request-pull' output should be ignored.
+
+In same go fix the Subject: line to have reasonable description, for
+example
+
+Subject: [PATCH 00/15] pull: various textual improvements
+
+
+Feedback and resubmissions
+--------------------------
+
+1. Since you sent each patch to mail-list you can see which ones got to
+be responded.  In case the feedback will result in changes to the
+submission then rebase, perform the changes, and push again to your
+remote.
+
+# you probably should use 'Stay up to date' instructions now
+git checkout textual
+git rebase master -i
+# edit something
+git add files
+git commit --amend
+# Add 'Reviewed-by:', 'Tested-by:', 'Signed-off-by:', 'Reference:', and
+# other lines near signoff when needed.  Attributing the reviewers is a
+# virtue, try to do it.
+git rebase --continue
+git push -f yourgit textual:textual
+
+2. Send a message to mail-list that the submitted change has changed, and
+that the new version can be found from
+
+https://github.com/yourlogin/util-linux/commit/0123456789abcdef0123456789abcdef01234567
+
+3. There is no need to update the pull request cover letter.  The project
+maintainer has done enough of this stuff to know what to do.
+
+
+Repository maintenance
+----------------------
+
+1. When your remote branch is merged, or you got final reject, it is time
+to clean it up.
+
+git branch textual -d
+git push yourgit :textual
+
+2. If you have other contributor repositories configured you may also
+want to clean up the branches the others are done with.
+
+for I in $(git remote); do
+  echo "pruning: $I"
+  git remote prune $I
+done
+
+3. When all of your contributions are processed you should tidy up the
+git's guts.
+
+git reflog expire --all
+git gc --aggressive --prune=now
+
+Warning.  That tidying is not good idea while you are actively working
+with the change set.  You never know when you need to recover something
+from reflog, so keep that option available until you know the reflog is
+not needed.
+
+
+More branches, on top of branches, on top of ...
+------------------------------------------------
+
+Here is a one way of laying out multiple branches.
+
+git log --graph --decorate --pretty=oneline --abbrev-commit --all
+* 13bfff3 (HEAD, docs-update) docs: small improvements to howto-contribute.txt
+* 5435d28 (sami/more, more) more: do not call fileno() for std{in,out,err} streams
+* 3e1ac04 more: remove unnecessary braces
+* c19f31c more: check open(3) return value
+* 651ec1b more: move skipping forewards to a function from command()
+* bf0c2a7 more: move skipping backwards to a function from command()
+* 53a438d more: move editor execution to a function from command()
+* b11628b more: move runtime usage output away from command()
+* 6cab04e more: avoid long else segment in prbuf()
+* a2d9fbb more: remove 'register' keywords
+* c6b2d29 more: remove pointless functions
+* b41fe34 more: remove function like preprocessor defines
+* 1aaa1ce more: use paths.h to find bourne shell and vi editor
+* 016a019 more: return is statement, not a function
+* ff7019a more: remove dead code and useless comments
+* 1705c76 more: add struct more_control and remove global variables
+* 3ad4868 more: reorder includes, declarations, and global variables
+* 7220e9d more: remove function declarations - BRANCH STATUS: WORK IN PROGRESS
+* 04b9544 (sami/script) script: add noreturn function attributes
+* e7b8d50 script: use gettime_monotonic() to get timing file timestamps
+* 11289d2 script: use correct input type, move comment, and so on
+* 524e3e7 script: replace strftime() workaround with CFLAGS = -Wno-format-y2k
+* 0465e7f script: move do_io() content to small functions
+* 751edca script: add 'Script started' line always to capture file
+* f831657 script: remove io vs signal race
+* eefc1b7 script: merge doinput() and output() functions to do_io()
+* 9eba044 script: use poll() rather than select()
+* a6f04ef script: use signalfd() to catch signals
+* 4a86d9c script: add struct script_control and remove global variables
+* d1cf19c script: remove function prototypes
+* 6a7dce9 (sami/2015wk00) fsck.minix: fix segmentation fault
+* 5e3bcf7 lslocks: fix type warning
+* 3904423 maint: fix shadow declarations
+* 17bf9c1 (upstream/master, sami/master, kzgh/master, master) ipcrm: fix usage
+[...]
+
+The above gives a hint to maintainer what is the preferred merge order.
+The branches '2015wk00' and 'script' are ready to be merged, and they
+were sent to mail-list.
+
+The 'more' branch was not submitted at the time of writing this text.
+Mark-up the branch is not ready is clearly marked in the commit subject,
+that will need some rebaseing to before submission.
+
+Good order of the branches is;
+
+1. First the minor & safe changes.
+2. Then the ready but less certain stuff.
+3. Followed by work-in-progress.
+
+If you go down this route you will get used to typing a lot of
+
+git rebase previous-branch
+git push -f yourgit branch:branch
+
+Alternatively rebase each branch on top of origin/master, which is not
+quite as good.  How do you ensure your own changes are not in conflict
+with each other?  And there is no hint of preferred merging order.