merge upstream

3 files changed, 25 insertions, 26 deletions

diff --git a/admin/notes/bzr b/admin/notes/bzr
index 8f7d0d94fa8..d3886abfd69 100644
--- a/admin/notes/bzr
+++ b/admin/notes/bzr
@@ -347,6 +347,9 @@ Runs on commit.  Projects can enable it themselves by using `bzr
 config' to set post_commit_to option for a branch.  See `bzr help email'
 (if you have the plugin installed) for other options.
 
+The From: address will be that of your Savannah account, rather than
+your `bzr whoami' information.
+
 Note: if you have the bzr-email plugin installed locally, then when
 you commit to the Emacs repository it will also try to send a commit
 email from your local machine.  If your machine is not configured to
diff --git a/admin/notes/elpa b/admin/notes/elpa
index db14456fe32..469a0ca8bd1 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -1,24 +1,21 @@
 NOTES ON THE EMACS PACKAGE ARCHIVE
 
-The GNU Emacs package archive, at elpa.gnu.org, is managed using a Bzr
-branch named "elpa", hosted on Savannah.  To check it out:
+The GNU Emacs package archive, at elpa.gnu.org, is managed using a Git
+repository named "elpa", hosted on Savannah.  To check it out:
 
-  bzr branch bzr+ssh://USER@bzr.savannah.gnu.org/emacs/elpa elpa
+  git clone git://bzr.sv.gnu.org/emacs/elpa
   cd elpa
-  echo "public_branch = bzr+ssh://USER@bzr.savannah.gnu.org/emacs/elpa" >> .bzr/branch/branch.conf
-  bzr bind bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/elpa
+  git remote set-url --push origin git+ssh://bzr.sv.gnu.org/srv/git/emacs/elpa
   [create task branch for edits, etc.]
 
-Changes to this branch propagate to elpa.gnu.org in a semi-manual way.
-There exists a copy of the elpa branch on that machine.  Someone with
-access logs in, pulls the latest changes from Savannah, and runs a
-"deployment" script.  This script (which is itself kept in the Bzr
-branch) generates the content visible at http://elpa.gnu.org/packages.
+Changes to this branch propagate to elpa.gnu.org via a "deployment" script run
+daily.  This script (which is kept in elpa/admin/update-archive.sh) generates
+the content visible at http://elpa.gnu.org/packages.
 
-The reason we set things up this way, instead of using the package
-upload commands in package-x.el, is to let Emacs hackers conveniently
-edit the contents of the "elpa" branch.  (In particular, multi-file
-packages are stored on the branch in source form, not as tarfiles.)
+A new package is released as soon as the "version number" of that package is
+changed.  So you can use `elpa' to work on a package without fear of releasing
+those changes prematurely.  And once the code is ready, just bump the
+version number to make a new release of the package.
 
 It is easy to use the elpa branch to deploy a "local" copy of the
 package archive.  For details, see the README file in the elpa branch.
diff --git a/admin/notes/hydra b/admin/notes/hydra
index 068bc70ee9c..71e35d092c8 100644
--- a/admin/notes/hydra
+++ b/admin/notes/hydra
@@ -5,15 +5,14 @@ See the end of the file for license conditions.
 
 NOTES FOR EMACS CONTINUOUS BUILD ON HYDRA
 
-A continuous build for Emacs trunk can be found at
+A continuous build for Emacs can be found at
 http://hydra.nixos.org/jobset/gnu/emacs-trunk
+http://hydra.nixos.org/jobset/gnu/emacs-24
 
-* It builds (and runs ERT tests) on these platforms:
-i686-cygwin
-i686-freebsd
-i686-linux
-x86_64-darwin
-x86_64-linux
+* It builds Emacs on various platforms.
+Sometimes jobs fail due to hydra problems rather than Emacs problems.
+Eg it seems like the cygwin build will never work again.
+http://lists.gnu.org/archive/html/hydra-users/2013-08/msg00000.html
 
 * Mail notifications
 In addition to the web interface, Hydra can send notifications by
@@ -27,15 +26,15 @@ http://lists.gnu.org/mailman/listinfo/emacs-buildstatus
 * The Emacs jobset consists of the following jobs:
 
 ** The `tarball' job
-which gets the source tree as input, and is just a `make dist' after
-some autoconf/-make or bootstrap script.
+which gets a checkout from bzr, and does a bootstrap followed
+by running make-dist to create a tarball.  If this job fails, all the
+others will too (because they use the tarball as input).
 
 ** The `build' job
-which gets the result of the tarball job as input, together with
-system identifier, this job basically does a normal make and make install.
+which starts from the tarball and does a normal build
 
 ** The 'coverage' job
-is now running `make check'.
+does a gcov build and then runs `make check'.  Fails if any test fails.
 
 * Nix expressions
 The recipe for GNU Emacs are available via Git: