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:
parent
0928ca2b59
commit
80008bcae9
|
@ -5,17 +5,16 @@ CONTENTS
|
||||||
Coding Style
|
Coding Style
|
||||||
Various Notes
|
Various Notes
|
||||||
Standards Compliance
|
Standards Compliance
|
||||||
IRC Channel
|
|
||||||
|
|
||||||
Sending Patches
|
Sending Patches
|
||||||
|
|
||||||
* send your patches to the mailing list or to the project maintainer.
|
* send your patches to the mailing list.
|
||||||
See ../README.
|
See ../README.
|
||||||
|
|
||||||
* email is accepted as an inline patch with, or without, a git pull
|
* 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
|
request. Pull request emails need to include the patch set for review
|
||||||
purposes. See howto-pull-request.txt and source-code-management.txt
|
purposes. See howto-pull-request.txt and ../README for git repository
|
||||||
for git repository instructions.
|
instructions.
|
||||||
|
|
||||||
* email attachments are difficult to review and not recommended.
|
* email attachments are difficult to review and not recommended.
|
||||||
Hint: use git send-email.
|
Hint: use git send-email.
|
||||||
|
@ -64,7 +63,7 @@ Patching Process
|
||||||
Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
|
Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
|
||||||
|
|
||||||
* using a git repository for (re)submissions can make life easier.
|
* 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.
|
* all patch submissions are either commented, rejected, or accepted.
|
||||||
If the maintainer rejects a patch set it is pointless to resubmit it.
|
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
|
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.
|
|
||||||
|
|
|
@ -39,4 +39,4 @@ For all releases it is required that:
|
||||||
See also
|
See also
|
||||||
--------
|
--------
|
||||||
|
|
||||||
Documentation/source-code-management.txt
|
../README
|
||||||
|
|
|
@ -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
137
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:
|
MAILING LIST:
|
||||||
|
|
||||||
E-MAIL: util-linux@vger.kernel.org
|
E-MAIL: util-linux@vger.kernel.org
|
||||||
URL: http://vger.kernel.org/vger-lists.html#util-linux
|
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:
|
BUG REPORTING:
|
||||||
|
|
||||||
E-MAIL: util-linux@vger.kernel.org
|
E-MAIL: util-linux@vger.kernel.org
|
||||||
Web: https://github.com/karelzak/util-linux/issues
|
Web: https://github.com/karelzak/util-linux/issues
|
||||||
|
|
||||||
Note that upstream community has no resources to provide support for end
|
This project has no resources to provide support for distribution specific
|
||||||
users with distribution specific issues. It's strongly recommended to
|
issues. For end users it is recommended to utilize the distribution's
|
||||||
report bugs to the distribution (downstream) maintainers by distribution
|
support system.
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
NLS (PO TRANSLATIONS):
|
NLS (PO TRANSLATIONS):
|
||||||
|
|
||||||
PO files are maintained by:
|
PO files are maintained by:
|
||||||
http://translationproject.org/domain/util-linux.html
|
http://translationproject.org/domain/util-linux.html
|
||||||
|
|
||||||
|
|
||||||
VERSION SCHEMA:
|
VERSION SCHEMA:
|
||||||
|
|
||||||
Standard releases:
|
Standard releases:
|
||||||
|
<major>.<minor>[.<maint>]
|
||||||
<major>.<minor>[.<maint>[.<bugfix>]]
|
major = fatal and deep changes
|
||||||
|
minor = typical release with new features
|
||||||
major = fatal and deep changes
|
maint = maintenance releases; bug fixes only
|
||||||
minor = typical release with new features
|
|
||||||
maint = maintenance releases; bug fixes only
|
|
||||||
bugfix = unplanned releases for critical/security bugs
|
|
||||||
|
|
||||||
Development releases:
|
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>
|
|
||||||
|
|
Loading…
Reference in New Issue