mirror of
https://git.savannah.gnu.org/git/emacs/org-mode.git
synced 2024-09-29 18:36:26 +00:00
Update READMEs
This commit is contained in:
parent
412d980f28
commit
869f9f2354
6
README
6
README
|
@ -1,9 +1,11 @@
|
||||||
The is a distribution of Org, a plain text notes and project planning
|
The is a distribution of Org, a plain text notes and project planning
|
||||||
tool for Emacs.
|
tool for Emacs.
|
||||||
|
|
||||||
The version of this release is: 7.9.1
|
The homepage of Org is at:
|
||||||
|
http://orgmode.org
|
||||||
|
|
||||||
The homepage of Org is at http://orgmode.org
|
The installations instructions are at:
|
||||||
|
http://orgmode.org/org.html#Installation
|
||||||
|
|
||||||
This distribution contains:
|
This distribution contains:
|
||||||
|
|
||||||
|
|
|
@ -1,11 +1,15 @@
|
||||||
This is the Emacs Org project, an Emacs library for organizing your life.
|
This is the Emacs Org project, an Emacs library for organizing your life.
|
||||||
|
|
||||||
The homepage of Org is at http://orgmode.org
|
The homepage of Org is at:
|
||||||
|
http://orgmode.org
|
||||||
|
|
||||||
|
Installations instructions are at:
|
||||||
|
http://orgmode.org/org.html#Installation
|
||||||
|
|
||||||
This distribution contains an ELPA packaged version of Org.
|
This distribution contains an ELPA packaged version of Org.
|
||||||
"ELPA" stands for the "Emacs Lisp Package Archive".
|
"ELPA" stands for the "Emacs Lisp Package Archive".
|
||||||
The GNU ELPA is here:
|
|
||||||
|
|
||||||
|
The GNU ELPA is at:
|
||||||
http://elpa.gnu.org
|
http://elpa.gnu.org
|
||||||
|
|
||||||
It contains the org-*.tar package, containing only the org files
|
It contains the org-*.tar package, containing only the org files
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# -*- mode:org -*-
|
# -*- mode:org -*-
|
||||||
|
|
||||||
#+TITLE: Maintainer tasks
|
#+TITLE: Org maintainer tasks
|
||||||
#+STARTUP: noindent
|
#+STARTUP: noindent
|
||||||
|
|
||||||
This document describes the tasks the Org-mode maintainer has to do
|
This document describes the tasks the Org-mode maintainer has to do
|
||||||
|
@ -37,7 +37,7 @@ branch back into maint to synchronize the two.
|
||||||
|
|
||||||
** Minor release
|
** Minor release
|
||||||
|
|
||||||
The release number for minor releases look like this: =7.13.01=
|
The release number for minor releases look like this: =7.13.1=
|
||||||
|
|
||||||
Minor releases are small amends to main releases. Usually they fix
|
Minor releases are small amends to main releases. Usually they fix
|
||||||
critical bugs discovered in a main release. Minor bugs are usually
|
critical bugs discovered in a main release. Minor bugs are usually
|
||||||
|
@ -50,8 +50,8 @@ maint then merged in master.
|
||||||
|
|
||||||
** Tagging the release
|
** Tagging the release
|
||||||
|
|
||||||
When doing a major and a minor release, after all necessary merging
|
When doing a major and a minor release, after all necessary merging is
|
||||||
is done, tag the _maint_ branch for the release with:
|
done, tag the _maint_ branch for the release with:
|
||||||
|
|
||||||
git tag -a "Adding release tag" release_7.9.1
|
git tag -a "Adding release tag" release_7.9.1
|
||||||
|
|
||||||
|
@ -59,6 +59,10 @@ and push tags with
|
||||||
|
|
||||||
git push --tags
|
git push --tags
|
||||||
|
|
||||||
|
We also encourage you to sign release tags like this:
|
||||||
|
|
||||||
|
git tag -a "Adding release tag" -s release_7.9.1
|
||||||
|
|
||||||
** Uploading the release files from the orgmode.org server
|
** Uploading the release files from the orgmode.org server
|
||||||
|
|
||||||
Log on the orgmode.org server as the emacs user and cd to
|
Log on the orgmode.org server as the emacs user and cd to
|
||||||
|
@ -72,92 +76,6 @@ From there do
|
||||||
to create the .tar.gz and .zip files, the documentation, and to
|
to create the .tar.gz and .zip files, the documentation, and to
|
||||||
upload everything at the right place.
|
upload everything at the right place.
|
||||||
|
|
||||||
* Working with patchwork
|
|
||||||
|
|
||||||
John Wiegley is running a patchwork server that looks at the
|
|
||||||
emacs-orgmode mailing list and extracts patches. The maintainer and
|
|
||||||
his helpers should work through such patches, give feedback on them
|
|
||||||
and apply the ones which are good and done. A task for the maintainer
|
|
||||||
is to every now and then try to get old stuff out of that list, by
|
|
||||||
asking some helpers to investigate the patch, by rejecting or
|
|
||||||
accepting it.
|
|
||||||
|
|
||||||
I have found that the best workflow for this is using the pw script by
|
|
||||||
Nate Case, with the modifications for Org-mode made by John Wiegley
|
|
||||||
and Carsten Dominik. The correct version of this script that should
|
|
||||||
be used with Org mode is distributed in the =mk/= directory of the Org
|
|
||||||
mode distribution. Here is the basic workflow for this.
|
|
||||||
|
|
||||||
** Access to the patchwork server
|
|
||||||
|
|
||||||
If you want to work on patchwork patches, you need write access at the
|
|
||||||
patchwork server. You need to contact John Wiegley to get this
|
|
||||||
access.
|
|
||||||
|
|
||||||
There is a web interface to look at the patches and to change the
|
|
||||||
status of patches. This interface is self-explanatory. There is also
|
|
||||||
a command line script which can be very convenient to use.
|
|
||||||
|
|
||||||
** Testing patches
|
|
||||||
|
|
||||||
To start testing a patch, first assign it to yourself
|
|
||||||
|
|
||||||
: pw update -s "Under Review" -d DELEGATE-NAME NNN
|
|
||||||
|
|
||||||
where =NNN= is a patch number and =DELEGATE-NAME= is your user name on
|
|
||||||
the patchwork server.
|
|
||||||
|
|
||||||
The get the patch into a branch:
|
|
||||||
|
|
||||||
: pw branch NNN
|
|
||||||
|
|
||||||
This will create a local topic branch in your git repository with the
|
|
||||||
name =t/patchNNN=. You will also be switched to the branch so that
|
|
||||||
you can immediately start testing it. Quite often small amends need
|
|
||||||
to be made, or documentation has to be added. Also, many contributors
|
|
||||||
do not yet provide the proper ChangeLog-like entries in the commit
|
|
||||||
message for the patch. As a maintainer, you have two options here.
|
|
||||||
Either ask the contributor to make the changes and resubmit the patch,
|
|
||||||
or fix it yourself. In principle, asking to contributor to change the
|
|
||||||
patch until it is complete is the best route, because it will educate
|
|
||||||
the contributor and minimize the work for the maintainer. However,
|
|
||||||
sometimes it can be less hassle to fix things directly and commit the
|
|
||||||
changes to the same branch =t/patchNNN=.
|
|
||||||
|
|
||||||
If you ask the contributor to make the changes, the patch should be
|
|
||||||
marked on the patchwork server as "changes requested".
|
|
||||||
|
|
||||||
: pw update -s "Changes Requested" -m "What to change" NNN
|
|
||||||
|
|
||||||
This will send an email to the contributor and the mailing list with a
|
|
||||||
request for changes. The =-m= message should not be more than one
|
|
||||||
sentence and describe the requested changes. If you need to explain
|
|
||||||
in more detail, write a separate email to the contributor.
|
|
||||||
|
|
||||||
When a new version of the patch arrives, you mark the old one as
|
|
||||||
superseded
|
|
||||||
|
|
||||||
: pw update -s "Superseded" NNN
|
|
||||||
|
|
||||||
and start working at the new one.
|
|
||||||
|
|
||||||
** Merging a final patch
|
|
||||||
|
|
||||||
Once the patch has been iterated and is final (including the
|
|
||||||
ChangeLog-like entries in the commit message), it should be merged.
|
|
||||||
The assumption here is that the final version of the patch is given by
|
|
||||||
the HEAD state in the branch =t/patchNNN=. To merge, do this:
|
|
||||||
|
|
||||||
: pw merge -m "maintainer comment" NNN
|
|
||||||
|
|
||||||
This will merge the patch into master, switch back to master and send
|
|
||||||
an email to both contributor and mailing list stating that this change
|
|
||||||
has been accepted, along with the comment given in the =-m= message.
|
|
||||||
|
|
||||||
At some point you might then want to remove the topic branch
|
|
||||||
|
|
||||||
: git branch -d t/patchNNN
|
|
||||||
|
|
||||||
* Synchonization with Emacs
|
* Synchonization with Emacs
|
||||||
|
|
||||||
This is still a significant headache. Some hand work is needed here.
|
This is still a significant headache. Some hand work is needed here.
|
||||||
|
@ -253,16 +171,19 @@ So the way I have been doing things with Emacs is this:
|
||||||
|
|
||||||
* Copyright assignments
|
* Copyright assignments
|
||||||
|
|
||||||
The maintainer needs to keep track of copyright assignments. Even
|
The maintainer needs to keep track of copyright assignments.
|
||||||
better, find a volunteer to do this.
|
Even better, find a volunteer to do this.
|
||||||
|
|
||||||
|
The assignment form is included in the repository as a file that
|
||||||
|
you can send to contributors: =request-assign-future.txt=
|
||||||
|
|
||||||
The list of all contributors from who we have the papers is kept on
|
The list of all contributors from who we have the papers is kept on
|
||||||
Worg at http://orgmode.org/worg/org-contribute.php, so that
|
Worg at http://orgmode.org/worg/org-contribute.html, so that
|
||||||
committers can check if a patch can go into the core.
|
committers can check if a patch can go into the core.
|
||||||
|
|
||||||
The assignment process does not allways go smoothly, and it has
|
The assignment process does not allways go smoothly, and it has
|
||||||
happened several times that it gets stuck or forgotten at the FSF.
|
happened several times that it gets stuck or forgotten at the FSF.
|
||||||
The contact at the FSF for this is: copyright-clerk@fsf.org
|
The contact at the FSF for this is: mailto:copyright-clerk@fsf.org
|
||||||
|
|
||||||
Emails from the paper submitter have been ignored in the past, but
|
Emails from the paper submitter have been ignored in the past, but
|
||||||
an email from me (Carsten) as the maintainer of Org mode has usually
|
an email from me (Carsten) as the maintainer of Org mode has usually
|
||||||
|
|
Loading…
Reference in a new issue