Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Fuel@OPNFV Work procedures and guidelines ======

===== Code of conduct =====
To follow the rules of conduct are essential to ensure good and fruitfull collab
oration:
  * Be open: We invite anyone to participate in any aspect of our projects. Our community is open, and any responsibility can be carried by a contributor who demonstrates the required capacity and competence.
  * Be considerate: People use our work, and we depend on the work of others. Consider users and colleagues before taking action. For example, changes to code, infrastructure, policy, and documentation may negatively impact others.
  * Be respectful: We expect people to work together to resolve conflict, assume good intentions, and act with empathy. Do not turn disagreements into personal attacks.
  * Be collaborative: Collaboration reduces redundancy and improves the quality of our work. We strive for transparency within our open source community, and we work closely with upstream developers and others in the free software community to coordinate our efforts.
  * Be pragmatic: Questions are encouraged and should be asked early in the process to avoid problems later. Be thoughtful and considerate when seeking out the appropriate forum for your questions. Those who are asked should be responsive and helpful.
  * Step down considerately: Members of every project come and go. When somebody leaves or disengages from the project, they should make it known and take the proper steps to ensure that others can pick up where they left off.

===== JIRA procedures =====
TBW

===== Commit procedures =====
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 **IMPROVEMENT** as a JIRA reference if it refers to a non reported bug/improvement.

**DESCRIPTION: A short commit description**

===== Review procedures =====
Contributors can vote -1,0,+1, committers can vote -2,-1,0,1,+2

  * Use -2 if you know the patch would not work or would interfere with other functionality, a review comment is mandatory.
  * Use -1 if you don't agree with the patch, or if there are improvements that you want made, a review comment is mandatory
  * Usee 0 if you just want to communicate through the comment field, 0 without any comments doesn't make sense and shall be avoided.
  * Use +1 if you agree with the patch, don't vote +1 on your own patches.
  * Use +2 if you agree with the patch and want it merged, don't vote +2 on your own patches unless the project lead agrees, and don't vote +2 until a chorum has voted +1 or a 24 hour period has passed.

===== Merge procedures =====
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.

===== Verifying a patch  =====
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/

===== Branches  =====
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.
Wiki

User Tools

Site Tools

Page Tools
