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>
This commit is contained in:
J William Piggott 2017-05-29 20:47:34 -04:00
parent 0928ca2b59
commit 80008bcae9
4 changed files with 104 additions and 91 deletions

View File

@ -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.

View File

@ -39,4 +39,4 @@ For all releases it is required that:
See also
--------
Documentation/source-code-management.txt
../README

View File

@ -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.

137
README
View File

@ -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.
SOURCE CODE:
See also Documentation/howto-contribute.txt
Documentation/source-code-management.txt
Web interface:
http://git.kernel.org/cgit/utils/util-linux/util-linux.git
https://github.com/karelzak/util-linux
Checkout:
git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
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.
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
http://translationproject.org/domain/util-linux.html
VERSION SCHEMA:
Standard releases:
<major>.<minor>[.<maint>[.<bugfix>]]
major = fatal and deep changes
minor = typical release with new features
maint = maintenance releases; bug fixes only
bugfix = unplanned releases for critical/security bugs
<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/
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 git://github.com/karelzak/util-linux.git
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 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.
<major>.<minor>-rc<N>