"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
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/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/
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.
** Understanding Emacs Internals.