Gitorious change submission procedure¶

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.

Special cases¶

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.

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.