From 869f9f2354bab39be8c7b2d461c6e6cbed1aa42d Mon Sep 17 00:00:00 2001 From: Bastien Guerry Date: Sat, 23 Mar 2013 17:34:19 +0100 Subject: [PATCH] Update READMEs --- README | 6 ++- README_ELPA | 8 +++- README_maintainer | 109 +++++++--------------------------------------- 3 files changed, 25 insertions(+), 98 deletions(-) diff --git a/README b/README index 32c792566..425701c08 100644 --- a/README +++ b/README @@ -1,9 +1,11 @@ The is a distribution of Org, a plain text notes and project planning 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: diff --git a/README_ELPA b/README_ELPA index 5b4c9461b..be8932439 100644 --- a/README_ELPA +++ b/README_ELPA @@ -1,11 +1,15 @@ 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. "ELPA" stands for the "Emacs Lisp Package Archive". -The GNU ELPA is here: +The GNU ELPA is at: http://elpa.gnu.org It contains the org-*.tar package, containing only the org files diff --git a/README_maintainer b/README_maintainer index 04b04397f..65457c155 100644 --- a/README_maintainer +++ b/README_maintainer @@ -1,6 +1,6 @@ # -*- mode:org -*- -#+TITLE: Maintainer tasks +#+TITLE: Org maintainer tasks #+STARTUP: noindent 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 -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 critical bugs discovered in a main release. Minor bugs are usually @@ -50,8 +50,8 @@ maint then merged in master. ** Tagging the release -When doing a major and a minor release, after all necessary merging -is done, tag the _maint_ branch for the release with: +When doing a major and a minor release, after all necessary merging is +done, tag the _maint_ branch for the release with: git tag -a "Adding release tag" release_7.9.1 @@ -59,6 +59,10 @@ and push tags with 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 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 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 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 - The maintainer needs to keep track of copyright assignments. Even - better, find a volunteer to do this. + The maintainer needs to keep track of copyright assignments. + 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 - 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. The assignment process does not allways go smoothly, and it has 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 an email from me (Carsten) as the maintainer of Org mode has usually