-
Notifications
You must be signed in to change notification settings - Fork 3
/
README.maintainer
110 lines (92 loc) · 4.82 KB
/
README.maintainer
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
"README.maintainer"
$Id: README.maintainer,v 1.4 2007/07/31 23:22:25 fang Exp $
This document provide some useful information for HACKT developers,
also useful to some of those who wish to contribute or modify the sources.
-------------------------------------------------------------------------------
For git instructions, please refer to "README.git".
For a list of things to verify before checking in revisions,
please refer to "MAINTAINER-checklist".
===============================================================================
Makefiles:
This section describes the use of Make.stddef and Make.global makefile
fragments. Make.stddef is a makefile header whose purpose is to
define project-wide macros for popular command-line utilities, and to
initialize standard macro variables that are used to accumulate
over a makefile, e.g. CLEANFILES. This relieves one of remembering
where the first definition of some common variables are -- if it's
common, it belongs in Make.stddef. Make.stddef should be the first
thing included by other makefiles, either directly or indirectly.
Make.global contains common project-wide Makefile targets. By including
this at the end of each makefile, you automatically inherit a bunch of
useful targets. Some of the targets depend on variables that accumulate
since their initializations in Make.stddef, such as AUTO_IGNORE.
Make.global should be the last make-fragment included in any makefile.
-------------------------------------------------------------------------------
gitignore (a phony make target to make .gitignore recursively)
git ignore files (.gitignore) are all semi-automatically generated
in this project.
The rationale behind this is that automake already
knows most of the files that should be ignored because they are
built (although there are always exceptions). The Makefile system
uses AUTO_IGNORE as a cumulative list of files to automatically ignore.
In addition, the generated .gitignore files depend on a local.gitignore
file from which it acquires user-defined (non-automatic) files.
local.gitignore is also where wildcard patterns belong.
The local.gitignore file may also be automatically generated by other
means, e.g., copying from an existing .gitignore.
In all cases, "make gitignore" creates .gitignore recursively for all
listed subdirectories, and "make clean-gitignore" removes them.
===============================================================================
COMMIT CHECKLIST
For developers, guidelines of things TODO when checking in revisions.
When in doubt, email one of the maintainers.
DEVELOPMENT COMMITS:
make &&
make check.log &&
make distcheck.log
This MUST pass for commits to the main trunk to guarantee
some sort of stability and functionality at all times.
Commits along branches are more forgiving and may allow
for commits that transiently break things, but such known
breaks should be noted as such in the ChangeLog entry.
src/ChangeLog: Historically, this was the primary source revision log
and was updated with an entry upon most commits.
Nowadays, commit messages live inside the git metadata,
but major changes still deserve ChangeLog entries.
configure.ac:
The version date need not be bumped with every commit.
Occasionally a maintainer will bless a particular snapshot
with a date-bump, which says that "this snapshot has been
more rigorously tested than others."
ChangeLog: $(top_srcdir)
This needs to be updated only when top-level maintainence
files are updated, such as automake, autoconf,
configure/m4 scripts, or other organization stuff.
BRANCH MANAGEMENT:
Use git branches. Send github pull requests from your branches.
RELEASE:
All COMMIT checklist items apply. In addition:
If possible, check for the following items in a release-check script.
configure.ac:
remove the "-devel" string from the version string
for OFFICIAL releases (none have happened yet).
bump the version date to present.
branch:
A release series is isolated from the main development line,
thus all revisions relative to a release belong on a release
branch. The branch should be named with -RELEASE instead
of -main-xx...
shared library versioning: (not applicable yet)
bump library version numbers, following standard
library versioning convention (GNU libtool).
default AM_CFLAGS and AM_CXXFLAGS:
turn OFF paranoid and strict developer flags as the default
compile options because users may use untested compilers.
After release, remember to turn developer flags back on.
ChangeLog: announce release
NEWS: announce release
RELEASE-BRANCH COMMITS:
Release branches will continue to receive bug fixes and documentation
improvements, but no other classes of source revisions.
git Tags: (numbering convention)
===============================================================================