Contribution process

Code contributions are made as patches attached to tickets. After a ticket with an attached contribution is made, it is reviewed by the EFS project team. Public discussion about contributions is made either on the efs-dev mailing list, or as comments within the ticket. Status changes, like acceptance and rejection, are always made in the ticket system.

Contributors who have provided patches which are included in a release are mentioned in the AUTHORS file inside the release.

How to submit a bug report

If you encounter an error while working with EFS, and don’t understand what is causing it, then create a bug report.

However, if you do know how to fix the problem you encountered, then think about submitting a patch, or getting commit privileges (see below).

How to submit a patch

Try to keep your patches specific to a single change, and ensure that your change does not break any tests. Do this by running

  make test

If there is no test for the fixed bug, please try to provide one.

The preferred method of creating a patch is to use the current head of master in the EFS git repository. This ensures that the patch works with the most recent EFS source code, and makes it easier for the EFS team to apply the patch.

Using git

1. Clone the repository

  git clone git@git.openefs.org:efs-core.git

  $ cd efs
  # ...modify code...
  $ git commit -a

  $ git format-patch origin/master
  # generates a patch file (e.g. 0001-foo.patch)

The AUTHORS file

Each and every patch is an important contribution to EFS and it’s important that these efforts are recognized. To that end, the Authors file contains an informal list of contributors and their contributions made to EFS. Patch submitters are encouraged to include a new or updated entry for themselves in AUTHORS as part of their patch.The format for entries in AUTHORS is defined at the top of the file.

1. Go to the EFS ticket tracking system . Log in, or create an account if you don’t have one yet.
2. Select New Ticket.
3. Give a clear and concise summary. Prefix it with a “[PATCH]”  identifier.
4. In the description, explain of the purpose of the patch and list files affected. 5. Set the Type of the ticket to “improvement”. Set other relevant drop-down menus, such as the version (the version of EFS where you encountered the problem).
5. Check the box for “I have files to attach to this ticket” Double-check that you’ve actually done this, because it’s easy to forget. DO NOT paste the patch file content into the Description.
6. Click the “Create ticket” button. On the next page attach your patch file(s).

How to submit something new

If you have a new feature to add to EFS, such as a new test:

1. If you have a new test script ending in .t, some mailers may become confused and consider it an application/x-troff. One way around this (for *nix users) is to diff the file against /dev/null like this:

  cd efs-core
  diff -u /dev/null newfile.t > newfile.patch

1. Go to the EFS ticket tracking system . Log in, or create an account if you don’t have one yet.
2. Select New Ticket.
3. Give a clear and concise summary. Prefix it with a “[NEW]”  identifier.
4. In the description, explain of the purpose of the feature you are adding, and list any existing files affected as well as new files.
5. Set the type of the ticket to “new feature”. Set other relevant drop-down menus.
6. Check the box for “I have files to attach to this ticket” Double-check that you’ve actually done this, because it’s easy to forget. DO NOT paste the content of the new file or files into the body of the message.
7. Click the “Create ticket” button. On the next page attach the patch for your new file(s).

What happens after my patch is received?

Trac creates a ticket for the submission, and you will receive an automatic reply with details of the ticket identifier. This identifier should be used in all further correspondence concerning the submission.

Everyone on the list sees the submission, and can comment on it. An EFS project team member will make sure you have submitted your EFS Contributor Agreement before the patch or feature is accepted. A developer with git commit authority will commit it to git once it is clear that it is the right thing to do.

Even developers with git commit authority stick to this scheme for larger or more complex changes, to allow time for peer review.

A list of all unresolved tickets is available.

Applying patches

You may wish to apply a patch submitted by someone else before the patch is incorporated into the master branch on the git origin.

For single diff patches or svn patches, copy the patch file to efs, and run:

  cd efs
  patch -p0 < some.patch

For recursive diff patches, copy the patch file to workingdir, and run:

  cd workingdir
  patch -p0 < some.patch

In order to be on the safe side run ‘make test’ before actually committing the changes.

Configuration of files to ignore

Sometimes new files will be created in the configuration and build process of EFS. These files should not show up when checking the distribution with

  git status

The list of these ignore files can be set in .git/ignore:

  cd <efs-core root directory>
  vim .git/ignore
  # modify list of ignored files, and save...

If git status is now ignoring the correct files, submit a patch as described above.

 # Patches for the EFS website

The http://www.openefs.org  website is hosted in a Drupal CMS. Submit changes through the usual ticket interface in Trac.