1. Reporting Bugs

Before submitting a bug report, please make sure you are using the latest code. We recommend people to run the maintenance branch (currently 0.0-MAINT), so do a git pull to ensure you are up to date.

  1. Head over to JIRA
  2. Sign on or create yourself a new account
  3. Enter short but descriptive title. It allows to easily identify what the bug report is about.
  4. Fill the description box explaining a few important details:
    • What is the problem – what is happening?
    • What is the expected behaviour – what should be happening?
    • IMPORTANT What steps are necessary to reproduce the problem? It is essential to sort out the problem quickly.
    • Which OpenVirteX version you are using?
    • What is distribution and/or OS version?
    • Did you obtain OpenVirteX as a binary or directly from source?
  5. Submit the issue, wait for candy to be delivered. 😉

2. New Feature Development

  1. Ticket is filed in Issue Tracker.
  2. Someone (any interested party) writes a feature design document and publishes it
  3. User community and core developers weigh in
  4. Document is tweaked with their feedback
  5. Someone writes an implementation and publishes a patch on Gerrit or submits a pull request (preferably with tests and documentation), Gerrit is the preferred submission path.
  6. Patch / Repository is maintained against the current HEAD/TIP of the active DEV branch by the original author
  7. Patch is pulled into active DEV branch by current release maintainer
  8. Maintenance is now the responsibility of the core development team (patches are of course welcome!)
  9. Eventually DEV is merged into a MAINT branch and feature makes it into stable release

3. Tests

Code submissions that introduce new features must have corresponding unit tests.

4. Notes

  • While you may submit a patch or pull requests from your fork, we generally prefer it if you use Gerrit.
  • You have a better chance of getting a new feature if it is possible to disable it and take no performance hit.
  • Changing fundamental behavior is hard, even if you’re right – preserving old behavior as an option is often (but not always) a good goal.
  • Nothing is risk-free. Trying to convince the core developers otherwise is not likely to win you any points.
  • Ultimately the person writing the design document (and then the code) is in charge – they don’t have to accept user feedback they don’t agree with.
  • The core development team eventually will decide whether to pull the code into the mainline, but 100% consensus is not required for this to happen.

5. Gaining Commit Rights

Eventually a contributor may be given commit rights. This means that this contributor will have the rights to approve changes and commit them to the main branch. Clearly, gaining such rights will only happen after the candidate has demonstrated the following in their interactions with the core team:

  • Contributed several significant new features.
  • Contributions are of high quality, i.e., lack of defects.
  • Contributions do not require many iterations of improvement before acceptance.
  • Participation and assistance on project’s forum and mailing lists.