+That is done by deploying the archive, which happens automatically
+once a day, and the changes are only reflected when the "Version:"
+header changes.
+
+** Format
+
+Each package should follow the ELPA packaging conventions, but there are
+some differences due to the way the deployment script creates the packages
+and the web-pages from this source code:
+- Multi-file packages put the package metadata in the main <pkg>.el file
+ in the format used for single-file packages: the <pkg>-pkg.el file is
+ auto-generated from it.
+- Every package should have both a "Version:" *and* a "Maintainer:".
+- the "URL:" header can be used to specify the home page
+ of the package, if it's maintained externally.
+- A "News:" section (or "NEWS" file) can/should be used to list the
+ user-visible changes of each version.
+- The "Package-Type:" header can be used to force the type of package
+ created (can be either `simple' for single-file packages or `multi' for
+ tarballs). By default the type is decided based on whether there are
+ several Elisp files in the source.
+- If you want some files to not be included in the tarball, you can
+ put a `.elpaignore' file in the root of your package directory, where you
+ can list patterns of files to ignore (this file is passed to tar's -X).
+
+** External branches
+
+Some packages are maintained in external branches. These should be
+appropriately listed in the `externals-list' file.
+There are two different cases: subtrees and externals.
+
+In both cases, a copy of the code is kept in the `elpa' repository and
+should be sync'd with the upstream every once in a while. This copy may
+include local changes, tho ideally these should be kept to a minimum.
+
+In the `subtree' case, the copy of the code is kept here in the
+corresponding `packages/<pkg>' directory. You should be able to "git
+merge -s subtree" from the upstream branch.
+
+In the `external' case, the copy of the code is not kept here but in the
+`externals/<pkg>' branch in the `elpa' repository.
+
+You can check out all the external packages into the `packages' directory
+with the command:
+
+ make externals
+
+You can check out a specific external PACKAGE into the `packages'
+directory with these commands:
+
+ cd packages
+ git clone --reference .. --single-branch --branch externals/PACKAGE $(git config remote.origin.url) PACKAGE
+
+If you already have a packages/PACKAGE directory with a previous
+checkout, you can update it like this:
+
+ cd packages/PACKAGE
+ git pull
+
+** Public incubation
+
+If you want to develop a package publicly prior to its first release (to
+benefit from others' feedback, primarily), but not in an external repo,
+you have 2 choices:
+- you can simply put "Version: 0" to indicate that this should not be
+ released yet.
+- or you can push to an "ephemeral" branch -- subject to rebase and eventual
+ removal upon finishing merge -- for the duration of the incubation.