emacs-elpa-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[elpa] master c5e8eb2 1/2: * README: Add submission guideline


From: Artur Malabarba
Subject: [elpa] master c5e8eb2 1/2: * README: Add submission guideline
Date: Sun, 08 Nov 2015 12:04:21 +0000

branch: master
commit c5e8eb2b0e3a6f1174675f3611aa550457c60555
Author: Artur Malabarba <address@hidden>
Commit: Artur Malabarba <address@hidden>

    * README: Add submission guideline
---
 README |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/README b/README
index fe5a4f1..ed74125 100644
--- a/README
+++ b/README
@@ -34,7 +34,48 @@ 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.
 
-** To add a package:
+** To add a package: (submission, submit)
+
+Adding a basic package is very simple. There are thorough
+instructional, but the gist is that you:
+
+1. Notify address@hidden
+2. Place all files inside `packages/<pkg-name>/'.
+3. `git add', `git commit' and `git push'.
+
+If you don't have push access to the repository, someone will do steps
+2 and 3 for you.
+
+*** Notify address@hidden
+
+There is no approval process for GNU Elpa packages.  Still,
+you must send an email to emacs-devel for several reasons:
+
+- Notifying other developers;
+- Making sure the package doesn't break FSF rules;
+- Checking if the package is not reinventing the wheel;
+- Ensuring that first-time developers are doing it right.
+
+Before doing anything, please ensure your package follows the
+conventions described in the `** Format' section.  Then, send an email
+to the list with the subject:
+    [ELPA] New package: <pkg-name>
+
+Start your message with an explanation about the package.  A
+copy-paste of the package's Summary and Commentary is perfectly fine
+here, but you can write more or less than that if you'd like.
+
+At the bottom of the message contents include the changes you're going
+to make (the patch).  For a single-file package this can be the
+package file itself instead of the patch.  If you prefer (and if you
+have push access), you can push your changes to a branch called
+`scratch/<pkg-name>', and mention the branch in your message.
+
+After 48h, or once any issues have been addressed, someone will push
+your changes for you.  You should probably also subscribe to
address@hidden, since that's where we discuss about GNU Elpa, and
+to address@hidden, since that's where people will report bugs
+about your package.
 
 *** Add a simple (1-file) package as packages/<pkg-name>/<pkg-name>.el.
 
@@ -88,12 +129,15 @@ and the web-pages from this source code:
 
 ** External branches
 
-The easiest way to maintain and develop GNU Elpa packages is to just
-edit them right here (in elpa.git).  However, some maintainers may
-prefer to use a dedicated repository or branch for the package.  There
-are two ways to do that: subtrees and externals.
+The above instructions are enough to add regular packages, those that
+are maintained primarily here in the repository.  The instructions
+below are for those maintainers who prefer to use a dedicated
+repository or branch for the package.
+
+There are two ways to do that: subtrees and externals.
 
-Such packages should be listed in the `externals-list' file.
+Either way, such packages should always be listed in the
+`externals-list' file.
 
 In both cases, a copy of the code is kept in the `elpa' repository
 (not necessarily in the master branch) and should be sync'd with the



reply via email to

[Prev in Thread] Current Thread [Next in Thread]