| Open Source Erlang |
|
|
List of Erlang Enhancement Proposals (EEPs) EEP 1 - Guidlines for writing an EEP Subscribing to the EEP mailing list
There are always many discussion threads on erlang-questions and other places about enhancements, changes and extensions to the Erlang runtime system and the language. As a way to document the various proposals and the decisions taken we now introduce the Erlang Enhancement Process inspired by the Python Enhancement Process. Because Erlang is a programming language with a few million lines of running business critical code in the world, the development process must impose some rigidity and provide resistance against accepting premature changes. Users have Erlang code, linked in drivers written in C, and applications that embed Erlang, so it is important that the inconvenience of upgrading to new versions of Erlang is minimized. Language changes might also make the language more difficult for new users to learn. To ensure that changes are carefully considered, significant changes must be described in an EEP, short for Erlang Enhancement Proposal. Each EEP should explain, among other things, why the change is needed, document how it should work, and give an overview how it should be implemented. The EEP author should listen to the community's feeback and edit the EEP as necessary. Before submitting an EEP; read EEP 1 - EEP Purpose and Guidelines that thoroughly explains the purpose of EEPs, their life cycle, and prescribed format. The EEP editor will reject EEPs that do not follow the guidelines.
There is a mailing list for EEPs eeps (at) erlang (dot) org, see mailing lists. Anyone interested can subscribe to the list. The EEP editor(s) are subscribed to the list, as well as the EEP repository administrator(s). New EEPs should be sent here, as well as EEP updates by EEP authors without repository write access. Note that as with all erlang.org mailing lists only subscribers are allowed to post to the list.
The EEP sources are in the directory
The repository server runs
Subversion
of version 1.5.5, for now, both a public read-only server
svn://svn.erlang.org/projects/
(that is: svn over TCP port 3690), and a read/write server
svn+ssh://svn@svn.erlang.org/projects/
(that is: svn through SSH over TCP port 22 user EEP authors and editors that need and get repository write access should generate a password protected RSA or DSA key pair of at least 1024 bits dedicated for this (EEP commit) purpose, and submit the public key to the EEP repository administrator. The EEP author then also will get a user ID unique within the Subversion repository.
For read-only access to the repository through
svn://svn.erlang.org/projects/
you need a subversion client. For Unix/Linux/Cygwin
there is most certainly a distro package
For read/write access you also need SSH. For Unix/Linux/Cygwin you most certainly already have it. For Windows use e.g PuTTY. Since Subversion sets up several connections for many repository operations and you should have a password protected private key, it is recommended to use a key server that keeps password unlocked keys in memory and saves you from frequently typing your key password. For Unix/Linux/Cygwin use ssh-agent. For Windows (in conjunction with PuTTY) use Pageant.
To build .html EEPs you also need
In the repository The processed .html EEPs are at: http://www.erlang.org/eeps/.
Some variations on that theme: ssh-agent can be started in parallell with the running shell instead of forking a new shell. Some distros start ssh-agent during the X startup process, ...
Some variations on that theme: Pageant can be started from your autostart folder. You can edit its shortcut properties in the autostart folder to add the key filename to the start command line making it add the key when it starts. Pageant can also be started by double-clicking on your private key.
|
||||||||||||||
| Last updated 2010-11-29 13:15 UTC | |||||||||||||||