"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.
commit it to the release branch; it will be merged to the master
branch later.
-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.
+However, if you know that the change will be difficult to merge to
+master (eg because the code on master has changed a lot), you can
+apply the change to both master 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 master; start the commit message with "Backport:".
+gitmerge.el will then exclude that commit from the merge to trunk.
+Some changes should not be merged to master at all, for whatever
+reasons. These should be marked by including something like "Do not
+merge to master" or anything that matches gitmerge-skip-regexp (see
+gitmerge.el) in the log message.
** Other process information
-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.
+
+Bugs needs regular attention. A large backlog of bugs is
+disheartening to the developers, and a culture of ignoring bugs is
+harmful to users, who expect software that works. Bugs have to be
+regularly looked at and acted upon. Not all bugs are critical, but at
+the least, each bug needs to be regularly re-reviewed to make sure it
+is still reproducible.
+
+The process of going through old or new bugs and acting on them is
+called bug triage. This process is described in the file
+admin/notes/bug-triage.
+
** 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
+"test/". From the "test/" directory, run "make
<filename>" to run the tests for <filename>.el(c). See
-"test/automated/Makefile" for more information.
+"test/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). You can also define any ert selector on the command
+line. So "make check SELECTOR=nil" is equivalent to "make
+check-expensive".
+
+You could also use predefined selectors of the Makefile. "make
+<filename> SELECTOR='$(SELECTOR_DEFAULT)'" runs all tests for
+<filename>.el(c) except the tests tagged as expensive.
+
+Selectors can be defined with different methods, see (info "(ert)Test
+Selectors") or
+https://www.gnu.org/software/emacs/manual/html_node/ert/Test-Selectors.html
+If your test file contains the tests "test-foo", "test2-foo" and
+"test-foo-remote", and you want to run only the former two tests, you
+could use a regexp: "make <filename> SELECTOR='\"foo$$\"'" .
** Understanding Emacs Internals.
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.