Fix some typos and minor issues

This commit is contained in:
Carsten Dominik 2011-01-03 12:09:15 +01:00
parent 90122ad888
commit 5de5fa3eb2
1 changed files with 23 additions and 15 deletions

View File

@ -108,7 +108,7 @@ release. The release process is a single make command:
: make release TAG=7.13 : make release TAG=7.13
Before issuing this command, you should make sure that everything Before issuing this command, you should make sure that everything
during the process will work right, you can do so my running during the process will work right, you can do so by running
: make testrelease TAG=7.13 : make testrelease TAG=7.13
@ -133,15 +133,17 @@ from maint with this command:
** Between releases ** Between releases
While working on master between releases, I use something like While working on master between releases, I used to use something like
7.02trans as the version string. To set this version string in all 7.02trans as the version string. I no longer do this. =M-x
relevant files, use org-version= will spit ut complete version infor related to git, with
the neares commit and tag. I you ever need to set a special version
number, use this:
: UTILITIES/set_version 7.02trans : UTILITIES/set_version 7.02trans
and commit the result. Note that the above command does not change and commit the result. Note that the above command does not change
the version string in the file from which Org's homepage is the version string in the file from which Org's homepage is
generated. To change that as well, you would use a =--all= flag. TO generated. To change that as well, you would use a =--all= flag. To
change only this file, use =--only=. change only this file, use =--only=.
* Synchonization with Emacs * Synchonization with Emacs
@ -185,9 +187,9 @@ So the way I have been doing things with Emacs is this:
/org-colview-xemacs.el/ and /org-install.el/. The former does not /org-colview-xemacs.el/ and /org-install.el/. The former does not
belong in Emacs. And the latter would actually be harmful because belong in Emacs. And the latter would actually be harmful because
Emacs generates its own autoloads. The Emacs distribution contains Emacs generates its own autoloads. The Emacs distribution contains
an empty org-install.el, so that users can have =(require an empty /org-install.el/, so that users can have =(require
'org-install)= in .emacs with no ill effects. So if you were to 'org-install)= in .emacs with no ill effects. So if you were to
copy org-install.el, you would overwrite that empty placeholder copy /org-install.el/, you would overwrite that empty placeholder
file. file.
4. Generate the ChangeLog entries 4. Generate the ChangeLog entries
@ -232,17 +234,23 @@ So the way I have been doing things with Emacs is this:
* Updating the list of hooks on Worg * Updating the list of hooks on Worg
The file org-configs/org-hooks.org contains a list of all hooks in The file /org-configs/org-hooks.org/ contains a list of all hooks in
Org. This list has to be updated after hooks have been added or Org. This list has to be updated after hooks have been added or
removed. The perl script UTILITIES/list-hooks.pl creates the entire removed. The perl script /UTILITIES/list-hooks.pl/ creates the
section "Hooks and Function variables", including its level-one entire section "Hooks and Function variables", including its
headline. I guess babel code could be used to update this level-one headline. I guess babel code could be used to update this
automatically, but I have not implemented this - I have been doing automatically, but I have not implemented this - I have been doing
it by hand every few months. it by hand every few months.
* Copyright assignments * Copyright assignments
The maintainer needs to keep track of copyright assignments. The The maintainer needs to keep track of copyright assignments. Even
list of all contributors from who we have the papers is kept on Worg better, find a volunteer to do this. The list of all contributors
at http://orgmode.org/worg/org-contribute.php, so that committers from who we have the papers is kept on Worg at
can check if a patch can go into the core. http://orgmode.org/worg/org-contribute.php, so that committers can
check if a patch can go into the core. The assignment process does
not allways go smoothly, and it has happened several times that it
gets stuck or forgotten at the FSF. Emails from the paper submitter
have been ignored in the past, but an email from me as the
maintainer of Org mode has usually fixed such cases within a few
days.