Skip to content

Latest commit

 

History

History
147 lines (116 loc) · 5.97 KB

CONTRIBUTING.rst

File metadata and controls

147 lines (116 loc) · 5.97 KB
Raw

Contributing

Any contribution, bug report, feature request and code contributions are encouraged and welcome, so please go ahead and don't withhold feedback!

Bug Reports and Feature Requests

If you find a bug or have a feature request, please search for already reported problems before submitting a new issue. Also, remember to set labels to indicate what you're filing an issue for.

If you would like to take a more active part in the CERN Analysis Preservation developments, you can watch ongoing discussions and become part of the team.

Code Contributions

We follow a typical GitHub flow.

  1. Fork this repository into your personal space.

  2. Start a new topical branch for any contribution. Give it a descriptive name, say fix-CMS-schema-mappings.

  3. Create logically separate commits for logically separate things

    Remember, it is a lot easier to squash commits into one than it is to break them apart. If you are unsure what to do, mind the following based on the official Invenio documentation:

    Split the commit
    • if the same commit addresses more than one logically separate problem
    Amend/squash the commit
    • if it breaks any tests or any functionality in it's current state (if you are not the primary author, use Co-Authored-By: name <[email protected]> in the commit message)
    Keep the commit
    • if it works as expected in it's current state
    • if you're not the primary author of this commit

  4. Please add any (closes #123) directives in your pull request message, if it closes an open issue, as well as (references #123), if it does not close but address a part of the respective issue.

  5. Test your branch on a local site and check the conformity of your commit messages with kwalitee, see the section on Formating Commit Messages. You can also check out this blog post on commit messages.

  1. If everything works as expected, issue a pull request. If the branch is not quite ready yet, please indicate WIP (=work in progress) in the pull request title.

For some general advice on using git, you might want to check out this style guide.

Formating Commit Messages

To check the conformity of your commit messages with kwalitee, you will need to install it using pip install kwalitee. Then you can check your commit messages with kwalitee check message HEAD~3... to check the last three or kwalitee check message to check only the last commit. You can also check a specific commit by attaching it's hash to the latter command.

The format required by kwalitee follows the structure indicated below:

KEYWORD: description in imperative (<=50 chars)

* more detailed description that wraps after 72 chars and starts
  with two spaces in the next line

* plus, there needs to be an empty line before every bullet point

Signed-off-by YOURSELF

KEYWORD needs to be one of these, according to the type of change that you're introducing.

To create the Signed-off-by with your name and email as configured with git config, you can use git commit -s (see https://help.github.com/articles/signing-commits-using-gpg/ for signing commits with a gpg key, verifying it was you who created this commit).

For further reading, please refer to the original repository on Github and the official documentation.

Change Propagation

Currently, CERN Analysis Preservation runs on three servers to allow internal and external testing while keeping the service stable.

  1. The Production server is the most stable version where data is savely stored and versioned. It receives rare updates to minimize the possibility of errors occuring and to maximize service up-time. This server is meant for long-term user testing and collaboration-wide access. It follows the production branch that receives updates from master after they were tested on the other two branches.
  2. The Quality Assurance server is where we test new features with certain users. It receives more frequent updates and data may disappear after a while. It follows the qa branch that receives updates from master after they were tested there.
  3. The Development server is unstable and exists for internal testing (nightly builds). Nothing is guaranteed to be preserved at any time, down-times are frequent and no warnings are given when deletion or changes occur. It follows the master branch that receives updates from pull requests.

Chatroom

Our chatroom is on gitter, it's open to everyone so feel free to join the conversation.