Home / Development / Erlware Development Model

Execution Model for Erlware Development

This page contains information on our process. Basically how we turn our ideas into reality.

Communication for Users and Developers

The erlware-dev@googlegroups.com mailing list is the primary means of communication. Bugs and enhancements from users should be placed on the appropriate issues list at code.google.com/p/. Developers and users both should subscribe to the issues they are interested in or have created by using a *. If a user or developer wants to monitor all issues they should subscribe to erlware-artifacts@googlegroups.com. To spur discussion on a particular issue, send an email to erlware-dev or erlware-questions with a link to the issue, and ask that further discussion take place on the issue itself; preferably not over email.

Erlware developers are often online in the #erlware IRC channel, on irc.freenode.net. Feel free to drop by and ask questions, suggest enhancements, etc. We log public conversations for the record, so that you can browse old conversations or find them when searching the web.

Git and the Patch Process

We maintain Erlware code in git repositories. This eases free development, anyone can clone the repository and contribute patches with minimum effort (apart from the coding time ;)). Whenever you are the main developer of a Erlware subproject, or you want we to apply a patch in the main stream, the way to go is sending it to the development list.

Setting Up Git to Send Emails

The easiest way to send patches is using the git commands format-patch and send-email, but first you need to be set up to send email.

Setting Up Outgoing SMTP

Pick one of the following two sections for getting email working:

MSMTP

First make sure to install msmtp (on debian or ubuntu just type sudo apt-get install msmtp). Then, configure msmtp writing the following lines in $HOME/.msmtprc.

account gmail
host smtp.gmail.com
auth on
user <your username here>@gmail.com
password <your password here>
tls on
tls_starttls on
tls_certcheck off
from <your username here>@gmail.com
maildomain gmail.com
account default : gmail

Finally, set permissions 0600 in that file.

Now configure git to use msmtp. You must do this for each separate repository/project:

$ git config sendemail.smtpserver <path_to_msmtp>

Postfix

If you work on Mac OS X, it comes with postfix already installed, you just need to set it up. Here are some instructions on how to enable it:

Enable the postfix MTA

Most linux operating systems allow for postfix to be installed, instructions will vary.

If your ISP is blocking your access to port 25, as many are these days, you're going to need to relay through them, or whoever you typically send email through. Here are some instructions on setting up postfix to use SMTP Auth and relay through another server:

SMTP Authentication for Mail servers

Note that in addition to the above instructions, I had to add the following line to my main.cf:

relayhost = [mail.my-isp.com]

If you need to specify a non-standard port:

relayhost = [mail.my-isp.com]:2500

Setting the Default Git Subject Line

For each project you will be submitting patches for you need to configure a subject line.

$ git config format.subjectprefix "<repo_name> PATCH"

Emailing Patches

When you're ready to email a set of patches, first figure out how many you'd like to send. git log, git show and git show-branch can be helpful in figuring that out. Let's say you want to email 3 patches:

$ git format-patch HEAD~3
$ git send-email 0*.patch

Send-email will ask you where to send the patch to; send it to erlware-dev@googlegroups.com.

Providing Access to Your Public Git Repository

Although all patches which are accepted into canonical sources must be sent to the list, it can be useful to publish your intermediate work on your own public repository. See the git documentation on how to set up a public repo that other people can pull from. See the other developers' public repos for examples.

Publishing a Work Branch

Let's say you have a branch called work that you want to make available for others to pull from. If you are in your working repository, you can do this:

git checkout work
git push <url-for-my-public-repo> work

Your public repository URL for this operation will probably be something like:

username@my.public.server.com:path/to/my/public/repo

Note the URL that others use to pull your repository will be different, probably something starting with http:// or git://.

Pulling From Another Developer's Public Branch

Let's say another developer has published some work you would like to merge into your own tree. Add the developer's public repo to your working repo as a remote:

git remote add krondo http://git.krondo.com/erlware/faxien.git

Above we are adding the faxien repo at git.krondo.com as a remotely tracked branch to our repo. We have named it 'krondo', but we could name it whatever we want to. Now we can use the name to fetch the latest work from that repo:

git fetch krondo

Now the patches from that repository are in our tree, but none of our local branches or working directory has been changed. We can merge the changes on a branch of the remote repository into our current branch with git merge:

git merge krondo/next

That command merges the next branch from the remote repository into our current branch.