summaryrefslogtreecommitdiff
path: root/README.devel
blob: 05300f3bf1637228131b33177c0df3142df954e3 (plain)
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

 Notes for util-linux-ng developers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

AUTOTOOLS:

     * "./autogen.sh" generates all necessary files (run it after checkout from
       git)

     * "make mrproper" removes all generates files. You have to call autogen.sh
       after mrproper.

     * "make distclean" is subset of mrproper. It removes all unnecessary files,
       but code is still possible recompile by "./configure; make"

     * "make dist-gzip" (or -bzip2) creates tarball which is possible use without
      autogen.sh


PATCHES:

     * send your patches to the mailing list or to upstream maintainer
       (see the AUTHORS file)

     * diff -u

     * don't include generated (autotools) stuff to your patches

     * patches are delivered via email only.  Downloading them from internet
       servers is a pain.

     * one patch per email, with the changelog in the body of the email.

     * Subject: [PATCH] subsystem: description

     * if someone else wrote the patch, they should be credited (and blamed) for it.
       To communicate this, add a line:

          From: John Doe <jdoe@wherever.com>

     * add a Signed-off-by line:

          Signed-off-by: Foo Bar <fb@wherever.com>

     * there is a lot of really useful rules. Please, read:

       The perfect patch
                http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt



SCM (source code management):

     git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng


    * maintenance branch(es)
        - created for every <major>.<minor> release, branch name: v<major>.<minor>-mnt

    * 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".

    * A new tag object is created for:
        - every release, tag name: v<version>
        - every public snapshot, tag name: s<version>-YYYYMMDD