"2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my previous commit"
will suffice.
-- There is no need to mention files such as NEWS, MAINTAINERS, and
- FOR-RELEASE, or to indicate regeneration of files such as
- 'configure', in the ChangeLog entry. "There is no need" means you
- don't have to, but you can if you want to.
+- There is no need to mention files such as NEWS and MAINTAINERS, or
+ to indicate regeneration of files such as 'configure', in the
+ ChangeLog entry. "There is no need" means you don't have to, but
+ you can if you want to.
** Generating ChangeLog entries
Development is discussed on the emacs-devel mailing list.
-Sometime before the release of a new major version of Emacs a "feature
-freeze" is imposed on the trunk, to prepare for creating a release
-branch. No new features may be added to the trunk after this point,
-until the release branch is created. Announcements about the freeze
-(and other important events) are made on the emacs-devel mailing
-list under the "emacs-announce" topic, and not anywhere else.
-
The trunk branch is named "master" in git; release branches are named
"emacs-nn" where "nn" is the major version.
However, if you know that the change will be difficult to merge to the
trunk (eg because the trunk code has changed a lot), you can apply the
-change to both trunk and branch yourself. Indicate in the release
-branch commit log that there is no need to merge the commit to the
-trunk; start the commit message with "Backport:". gitmerge.el will
-then exclude that commit from the merge to trunk.
+change to both trunk and branch yourself. It could also happen that a
+change is cherry-picked from master to the release branch, and so
+doesn't need to be merged back. In these cases, indicate in the
+release branch commit log that there is no need to merge the commit to
+the trunk; start the commit message with "Backport:". gitmerge.el
+will then exclude that commit from the merge to trunk.
** Other process information
-*** Non-ASCII characters in Emacs files
-
-If you introduce non-ASCII characters into Emacs source files, it is a
-good idea to add a 'coding' cookie to the file to state its encoding.
-Please use the UTF-8 encoding unless it cannot do the job for some
-good reason. As of Emacs 24.4, it is no longer necessary to have
-explicit 'coding' cookies in *.el files if they are encoded in UTF-8,
-but other files need them even if encoded in UTF-8. However, if
-an *.el file is intended for use with older Emacs versions (e.g. if
-it's also distributed via ELPA), having an explicit encoding
-specification is still a good idea.
-
-*** Useful files in the admin/ directory
-
-See all the files in admin/notes/* . In particular, see
-admin/notes/newfile, see admin/notes/repo.
-
-The file admin/MAINTAINERS records the areas of interest of frequent
-Emacs contributors. If you are making changes in one of the files
-mentioned there, it is a good idea to consult the person who expressed
-an interest in that file, and/or get his/her feedback for the changes.
-If you are a frequent contributor and have interest in maintaining
-specific files, please record those interests in that file, so that
-others could be aware of that.
-
-*** git vs rename
-
-Git does not explicitly represent a file renaming; it uses a percent
-changed heuristic to deduce that a file was renamed. So if you are
-planning to make extensive changes to a file after renaming it (or
-moving it to another directory), you should:
-
-- create a feature branch
-
-- commit the rename without any changes
-
-- make other changes
-
-- merge the feature branch to trunk, _not_ squashing the commits into
- one. The commit message on this merge should summarize the renames
- and all the changes.
-
** Emacs Mailing lists.
Discussion about Emacs development takes place on emacs-devel@gnu.org.
such patch without additional remarks, you can use a command like
'git send-email --to=bug-gnu-emacs@gnu.org 0001-DESCRIPTION.patch'.
+** Issue tracker (a.k.a. "bug tracker")
+
+The Emacs issue tracker is at http://debbugs.gnu.org/. The form
+presented by that page allows to view bug reports and search the
+database for bugs matching several criteria. Messages posted to the
+bug-gnu-emacs@gnu.org mailing list, mentioned above, are recorded by
+the tracker with the corresponding bugs/issues.
+
+GNU ELPA has a 'debbugs' package that allows accessing the tracker
+database from Emacs.
+
** Document your changes.
Any change that matters to end-users should have an entry in etc/NEWS.
** Test your changes.
Please test your changes before committing them or sending them to the
-list.
+list. If possible, add a new test along with any bug fix or new
+functionality you commit (of course, some changes cannot be easily
+tested).
Emacs uses ERT, Emacs Lisp Regression Testing, for testing. See (info
"(ert)") or https://www.gnu.org/software/emacs/manual/html_node/ert/
for more information on writing and running tests.
+If your test lasts longer than some few seconds, mark it in its
+`ert-deftest' definition with ":tags '(:expensive-test)".
+
To run tests on the entire Emacs tree, run "make check" from the
top-level directory. Most tests are in the directory
"test/automated". From the "test/automated" directory, run "make
<filename>" to run the tests for <filename>.el(c). See
"test/automated/Makefile" for more information.
+Tests which are tagged ":expensive-test" are enabled additionally, if
+you run "make check-expensive" from the top-level directory. "make
+<filename>" as mentioned above incorporates expensive tests for
+<filename>.el(c).
+
** Understanding Emacs Internals.
The best way to understand Emacs Internals is to read the code,
The file etc/DEBUG describes how to debug Emacs bugs.
+*** Non-ASCII characters in Emacs files
+
+If you introduce non-ASCII characters into Emacs source files, it is a
+good idea to add a 'coding' cookie to the file to state its encoding.
+Please use the UTF-8 encoding unless it cannot do the job for some
+good reason. As of Emacs 24.4, it is no longer necessary to have
+explicit 'coding' cookies in *.el files if they are encoded in UTF-8,
+but other files need them even if encoded in UTF-8. However, if
+an *.el file is intended for use with older Emacs versions (e.g. if
+it's also distributed via ELPA), having an explicit encoding
+specification is still a good idea.
+
+*** Useful files in the admin/ directory
+
+See all the files in admin/notes/* . In particular, see
+admin/notes/newfile, see admin/notes/repo.
+
+The file admin/MAINTAINERS records the areas of interest of frequent
+Emacs contributors. If you are making changes in one of the files
+mentioned there, it is a good idea to consult the person who expressed
+an interest in that file, and/or get his/her feedback for the changes.
+If you are a frequent contributor and have interest in maintaining
+specific files, please record those interests in that file, so that
+others could be aware of that.
+
+*** git vs rename
+
+Git does not explicitly represent a file renaming; it uses a percent
+changed heuristic to deduce that a file was renamed. So if you are
+planning to make extensive changes to a file after renaming it (or
+moving it to another directory), you should:
+
+- create a feature branch
+
+- commit the rename without any changes
+
+- make other changes
+
+- merge the feature branch to trunk, _not_ squashing the commits into
+ one. The commit message on this merge should summarize the renames
+ and all the changes.
+
\f
This file is part of GNU Emacs.