digitalSTROM Server

h1. Gitorious change submission procedure

h2. General concept

Typically, changes should not be pushed directly to 'mainline'. Instead, a personal repository and a merge request should be used. This ensures that the code gets reviewed by a second person, hopefully improving quality and consistency of the 'mainline' code base.

It is required to create a separate branch for every feature/set of changes one does, since this makes it easier to create the merge request, and allows one to continue working on other features while another merge request is open. Make sure the branch is rebased to @upstream/master@ before submitting a merge request.

If a merge request needs to be adjusted before it can be committed to @dss-mainline/master@ please use the power of git to add changes inside previous commits rather than adding a new commit. E.g. if a variable got a spelling error in it, please use @git rebase --interactive@ to correct the problem and keep the history clean.

h2. Special cases

h3. Trivial merges

Sometimes, changes can be rather trivial; we want every change to be submitted as merge request, however for trivial changes, the submitted should add '@[TRIVIAL]@' to the one-line summary, which should accelerate the review process of these.

Also, if the submitter is a member of the core team, the review may optionally choose to just acknowledge the merge request in a comment, allowing the original submitter to proceed and merge the change into 'mainline' himself/herself.

h3. Extra complex merges

If changes require manual merging and/or rebasing it may be advisable to merge the changes into an integration branch in a personal repository of a core member, create another merge request, and ask the original submitter to review this one.

h2. Contributing

Use the following list to check your merge-requests. As a general rule, stick to the conventions of the files you're editing.

* New features _should_ come with a test. We'll require tests as soon as the testability of the code improves.

* The test-suite must pass (issue @make test@ in your build directory)

* Don't use tabs

* Two space indentation, strip whitespace at eol

* Use meaningful commit messages

** Keep the first line under 50 characters