File: README

package info (click to toggle)
util-linux 2.33.1-0.1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 44,712 kB
  • sloc: ansic: 126,306; sh: 15,468; yacc: 1,170; makefile: 383; xml: 348; python: 316; csh: 37; sed: 16; perl: 15
file content (135 lines) | stat: -rw-r--r-- 4,546 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135

				  util-linux

		util-linux is a random collection of Linux utilities

     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
      ARCHIVE: https://lore.kernel.org/util-linux/

      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

IRC CHANNEL:

      #util-linux at freenode.net:

      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

      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:

 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.