masscollaborationlabs/emacs
2
0
Fork 0
mirror of https://github.com/masscollaborationlabs/emacs.git synced 2025-07-03 10:53:23 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

* CONTRIBUTE: minor improvements

Browse source 
* ChangeLog: cleanup entries for my recent commits
This commit is contained in:
Stephen Leake 2014-12-06 02:28:38 -06:00
parent 06264b3d24
commit 952c6c8f00
2 changed files with 33 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

45
CONTRIBUTE
View file

@ -12,7 +12,8 @@ new features to add, please suggest them too -- we might like your
idea. Porting to new platforms is also useful, when there is a new
platform, but that is not common nowadays.
For documentation on Emacs (to understand how to implement your desired change), refer to:
For documentation on Emacs (to understand how to implement your
desired change), refer to:
- the Emacs Manual
http://www.gnu.org/software/emacs/manual/emacs.html
@ -42,7 +43,8 @@ There are many ways to contribute to Emacs:
- check if existing bug reports are fixed in newer versions of Emacs
http://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs
- develop a package that works with Emacs, and publish it on your own or in Gnu ELPA.
- develop a package that works with Emacs, and publish it on your own
or in Gnu ELPA (see admin/notes/elpa).
Here are some style and legal conventions for contributors to Emacs:
@ -67,7 +69,7 @@ Emacs has additional style and coding conventions:
- Remove all trailing whitespace in all source and text files.
- Emacs has no convention on whether to use tabs in source code, but
- Emacs has no convention on whether to use tabs in source code;
please don't change whitespace in the files you edit.
- Use ?\s instead of ? in Lisp code for a space character.
@ -151,7 +153,9 @@ When using git, commit messages should use ChangeLog format, with a
single short line explaining the change, then an empty line, then
unindented ChangeLog entries. (Essentially, a commit message should
be a duplicate of what the patch adds to the ChangeLog files. We are
planning to automate this better, to avoid the duplication.)
planning to automate this better, to avoid the duplication.) You can
use the Emacs functions log-edit-add-to-changelog or
log-edit-insert-changelog to ease this process.
** The patch itself.
@ -211,14 +215,6 @@ specify the actual author; the committer defaults to you.
** Changelog notes
- Preferred form for several entries with the same content:
* help.el (view-lossage):
* kmacro.el (kmacro-edit-lossage):
* edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
(Rather than anything involving "ditto" and suchlike.)
- Emacs generally follows the GNU coding standards when it comes to
ChangeLogs:
http://www.gnu.org/prep/standards/html_node/Change-Logs.html . One
@ -231,6 +227,14 @@ specify the actual author; the committer defaults to you.
lowest ChangeLog that is higher than or at the same level as any file
changed by the commit.
- Preferred form for several entries with the same content:
* help.el (view-lossage):
* kmacro.el (kmacro-edit-lossage):
* edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
(Rather than anything involving "ditto" and suchlike.)
- In ChangeLog files, there is no standard or recommended way to
identify revisions.
@ -259,8 +263,8 @@ branch. No new features may be added to the trunk after this point,
until the release branch is created. This freeze is announced on the
emacs-devel mailing list, and not anywhere else.
For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for
23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x.
The trunk branch is named "master" in git; release branches are named
"emacs-nn" where "nn" is the major version.
You must follow emacs-devel to know exactly what kinds of changes are
allowed on what branch at any time. Announcements about the freeze
@ -270,13 +274,12 @@ If you are fixing a bug that exists in the current release, be sure to
commit it to the release branch; it will be merged to the master
branch later.
The exception is, if you know that the change will be difficult to
merge to the trunk (eg because the trunk code has changed a lot). In
that case, it's helpful if 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:". This is helpful for the person merging the release
branch to the trunk (it is handled automatically by gitmerge.el).
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.
** Other process information

11
ChangeLog
View file

@ -1,6 +1,13 @@
2014-12-05 Stephen Leake <stephen_leake@stephe-leake.org>
2014-12-06 Stephen Leake <stephen_leake@stephe-leake.org>
* CONTRIBUTE: improve, move some info from admin/notes/* here.
* CONTRIBUTE: improve; add explicit web references, move some info
from admin/notes/* here.
* INSTALL.REPO: You can't "just run make" after a clean checkout.
* admin/notes/commits: deleted; merged into ./CONTRIBUTE
* admin/notes/repo: move commit, branch info into ./CONTRIBUTE
2014-12-05 Stephen Leake <stephen_leake@stephe-leake.org>