This is an old revision of the document!
To follow the rules of conduct are essential to ensure good and fruitfull collab oration:
Any contributor may commit code to the fuel@OPNFV repository.
Keep related/cumulative patches together in one and the same patch-set - git commit –amend
Use topic branches for patch sets, i.e. create- and work on a local branch for the patch-set - git branch my-bug, git checkout my-bug, create the patch, git add …, git commit -s, git review
Code commit messages shall follow the following format:
MERGE/DO NOT MERGE - indicates weather the intention is to merge the commit
VERIFIED/NOT VERIFIED - indicates weather the commit has passed the developers pipeline verification.
JIRA: JIRA-ID - indicates the JIRA-ID to which the commit refers to, use BUG or IMROVEMENT as a JIRA reference if it refers to a non reported bug/improvement.
DESCRIPTION: A short commit description
Contributors can vote -1,0,+1, committers can vote -2,-1,0,1,+2
Merging of a commit can be performed by project committers.
The merge of a patch shall be performed by the issuer of the patch commit, if the issuer is not a project committer, he or she shall-, after having received a +2 vote, reach out to a project committer and ask him or her to merge on behalf of the issuer.
To increase traceability and code quality, a patch shall have passed the developers ci-pipeline before it is marked as MERGE in the commit message. Indicate that it has passed the pipeline by stating VERIFIED in the commit message.
You can find the developers pipeline here: http://jonasbjurel.github.io/OPNFV-Playground/
We are generally cautious and restrictive in creating branches. Normally we only work out of the master branch until code-freeze - about four weeks before a major release.
At code-freeze of a major release, a stable branch is created. During the time from code freeze of a stable release until the release - any fixes shall first be merged and tested on master, and after having passed a nightly build/deploy be cherry picked to the stable branch.
Also at code-freeze of a major release, the master branch is opened up for feature development for the next coming major release. However no rebasing of the master must take place until the release date.
Service releases are intermediate bug-fix releases that happens a few moth after a major release. Depending on if the master branch has been rebased compared to the stable branch or not, we may chose to do the bug-fixes on master and cherry picked to stable, or directly work on stable.
If there is a need to experiment with rebasing for a next coming major release before the previous has been release we may consider to create a short lived experimental branch.