From: Stephen Leake Date: Sat, 6 Dec 2014 08:28:38 +0000 (-0600) Subject: * CONTRIBUTE: minor improvements X-Git-Tag: emacs-25.0.90~2635^2~180 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=952c6c8f00b481cf27aa4d24d86d7a17613cb984;p=emacs.git * CONTRIBUTE: minor improvements * ChangeLog: cleanup entries for my recent commits --- diff --git a/CONTRIBUTE b/CONTRIBUTE index 9c904a798e5..dc6fd71624a 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -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 diff --git a/ChangeLog b/ChangeLog index ba0880c6181..61cada99c00 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,6 +1,13 @@ -2014-12-05 Stephen Leake +2014-12-06 Stephen Leake + + * 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 - * CONTRIBUTE: improve, move some info from admin/notes/* here. + * admin/notes/repo: move commit, branch info into ./CONTRIBUTE 2014-12-05 Stephen Leake