-This directory contains most of the source code of the GNU ELPA packages.
-
-Each directory in here corresponds to a package, which can be
-either a single-file package or a multifile package.
-
-A nightly cron job refreshes the GNU ELPA archive from this repository.
-
-This cron job only creates a new package when the "version" (as specified in
-the foo-pkg.el or in the "Version:" header) of a package is modified.
-This means that you can safely work on the next version here without
-worrying about the unstable code making it to GNU ELPA, and simply update
-the "version" when you want to release the new code.
-
-* 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 can put the package metadata in the main <pkg>.el file
- in the format used for single-file packages, in which case the script
- will auto-generate the <pkg>-pkg.el file.
-- the "URL:" header (or :url property) 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 (the other files will simply be
- ignored).
-- 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
-
-* 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 can push to an "ephemeral" branch -- subject to rebase and eventual
-removal upon finishing merge -- for the duration of the incubation.