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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
-*- outline -*-
This file attempts to describe the maintainer-specific notes to follow
when hacking Autoconf. Don't put this file into the distribution.
Don't mention it in the ChangeLog. You may want to first see
README-hacking for more general rules on building Autoconf from
checked-out sources.
* Administrivia
** If you incorporate a change from somebody on the net:
First, if it is a large change, you must make sure they have signed
the appropriate paperwork. Second, be sure to add their name and
email address to THANKS.
** Test fixes
If a change fixes a test, mention the test in the ChangeLog entry.
To this end, the Autotest-mode is handy.
** Bug reports
If somebody reports a new bug, mention his name in the ChangeLog entry
and in the test case you write. Put him into THANKS.
The correct response to most actual bugs is to write a new test case
which demonstrates the bug. Then fix the bug, re-run the test suite,
and check everything in.
** Visible changes
Which include serious bug fixes, must be mentioned in NEWS.
** Portability issues
Discoveries in portability matters should be written down in the
documentation (what fails, why it fails, *where* it fails, and what's
to be written instead?).
** Allow bootstrapping
Make sure that a fresh checkout of Autoconf can be bootstrapped using
the previous stable release of Autoconf. In other words, do not use
newly-added features in configure.ac if doing so would require an
installed git checkout to rerun `autoreconf -i' successfully.
* Test suite
** make check
Use liberally.
** Release checks
Try to run the test suite with more severe conditions before a
release:
- Run `make syntax-check'
This makes sure that the source files follow some consistent rules.
The checks live in maint.mk, which is intended to be shared across
several projects. (Help in merging this to use gnulib's maint.mk
would be appreciated).
- Run `make maintainer-distcheck'
This is quite long. It basically runs the test suite using a C++
compiler instead of a C compiler, and within a severe environment
(POSIXLY_CORRECT).
- Try some real world packages
A good example is the coreutils package.
* Release Procedure
These steps describe what a maintainer does to make a release; they
are not needed for ordinary patch submission.
** Upload Privileges
If you have not yet registered your gpg public key and (preferred)
email address with the FSF in relation to the Autoconf package, send
an email, preferably GPG-signed, to <ftp-upload@gnu.org> that includes
the following:
(a) name of package(s) that you are the maintainer for, and your
preferred email address.
(b) an ASCII armored copy of your GnuPG key, as an attachment.
("gpg --export -a YOUR_KEY_ID > mykey.asc" should give you
this.)
When you have received acknowledgement of your message, the proper GPG
keys will be registered on ftp-upload.gnu.org and only then will you
be authorized to upload files to the FSF ftp machines. Beware; this
process can take several days.
** Mailing list Admin Privileges
If you do not have access to the mailing list administrative
interface, approach the list owners for the password. Be sure to
check the lists (esp. bug-autoconf) for outstanding bug reports also
in the list of pending moderation requests. This step is not strictly
necessary, but helps.
** Preparation for release
Make sure you have GNU make installed. Make sure your PATH includes a
Automake 1.11 or later (preferably not a development snapshot). Make
sure your locale is sane, e.g. by exporting LC_ALL=C. Bootstrap the
checkout, and make sure the testsuite passes. See above for more
hints on the testsuite. If needed, update cfg.mk with details
specific to your environment, such as the location of a gnulib checkout.
** Update the foreign files
Running `make fetch' in the top level should grab it all for you; you
should check the results before committing them in git.
** Set the version number
Update the version number in NEWS (with version, date, and release
type) and ChangeLog, and mention in README whether the release is
stable. Make sure all changes are committed, then run `git tag -s -m
<version> -u <gpg_key> v<version>'. Do not push anything upstream at
this point. At this point, running `make _version', followed by `make
news-date-check changelog-check' will validate that the information is
formatted correctly.
** Update configure
As much as possible, make sure to release an Autoconf that uses
itself. That's easy: just be in the top level, and run
`tests/autoconf'. Or install this autoconf and run `autoreconf -f'.
** Make the release
Run `make {alpha,beta,stable}' depending on which type of release this
is. This runs the various checks, creates delta files, creates a
preliminary announcement in ~/announce-autoconf-<version>, prints
out the command to upload the files, and updates the previous version
file.
If it fails, run `git tag -d v<version>', fix the problems, and go
back to the step of setting the version.
** Upload
Put the tarballs where they should be, using the instructions
regarding gnupload that were printed during the previous step. Verify
that the files are correctly uploaded before sending a release
announcement.
** Push the updates
Run `git push origin refs/tags/v<version>' to push the release tag.
** Announce
Complete/fix the announcement file, and email it at least to
autoconf@gnu.org and autotools-announce@gnu.org. If this is a stable
release, also mail to info-gnu@gnu.org.
** Other web updates
For alpha and beta releases, the process is complete. For stable
releases, there are several other web pages that need updates.
Update the online manual: Run `make web-manual', then copy the
contents of doc/manual into a CVS checkout of the documentation
repository. Remember to use `cvs add -ko' so that RCS keywords in the
generated output do not get expanded improperly.
$ export CVS_RSH=ssh
$ cvs -z3 -d:ext:<user>@cvs.sv.gnu.org:/web/autoconf co autoconf
Post a news blurb on https://savannah.gnu.org/projects/autoconf.
Update the Free Software Directory: browse to:
http://directory.fsf.org/project/autoconf/
and send an email to <bug-directory@gnu.org> mentioning any content
that needs to be updated.
-----
Copyright (C) 2002, 2008-2012 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. This file is offered as-is,
without warranty of any kind.
|
