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. 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.
-
+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
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.
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)".
+'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
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 best way to understand Emacs Internals is to read the code,