mirror of
git://git.sv.gnu.org/autoconf
synced 2024-12-09 02:10:22 +08:00
1d1145256a
* build-aux/announce-gen: Sync from upstream. * build-aux/config.guess: Likewise. * build-aux/config.sub: Likewise. * cfg.mk (gnu_rel_host, url_dir_list): Move... * maint.mk: ...here, copying ideas from gnulib. (major): Rename... (stable): ...to this, copying gnulib. * HACKING (release): Document changes in process. Signed-off-by: Eric Blake <ebb9@byu.net>
180 lines
6.9 KiB
Plaintext
180 lines
6.9 KiB
Plaintext
-*- 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
|
|
released version of Automake (and not a development snapshot);
|
|
preferably 1.10.1 or later so you can build an LZMA tarball. 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. Update cfg.mk with details specific to your
|
|
environment, such as your GPG key and 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'.
|
|
|
|
** XZ tarball creation
|
|
Using the `dist-xz' option of Automake requires Automake 1.11, and
|
|
fails for everyone who does not have xz installed, but for now
|
|
Autoconf only requires Automake 1.10. However, as maintainer, you
|
|
should build an xz tarball. By using Automake 1.11 or newer, you
|
|
can run `make dist-xz'; run this prior to the release target so that
|
|
the release announcement will include the .tar.xz file.
|
|
|
|
** 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 /tmp/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, 2009 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.
|