Skip to content
This repository has been archived by the owner on Apr 18, 2019. It is now read-only.

VSM Development

Jump to bottom
ywang19 edited this page Oct 24, 2014 · 6 revisions

Contributing to VSM

Before you decide to make contributions, here are some of the basic links:

Virtual Storage Manager (VSM) Quality Significant work has been put into coding style compliance, issue tracking workflow and functionality and stability testing. We will clarify them in following paragraphs. The guidelines described below ensure that careful attention is paid prior to proposed changes being landed, whether the engineer works for Intel or some other contributing individuals or organizations.

##Getting Started

You’ll need take some administrative tasks:

  1. Create an account on github.com for source code accessing
  2. Create an account on 01.org for issue accessing
  3. Create an account on mailing list for community participating

So far all those accounts are separate.

##Code Style

When submitting code, please make every effort to follow existing conventions and style in order to keep the code readable and consistent. VSM is based on OpenStack Horizon project, it follows horizon similar code quality standards.

Python: We follow PEP8 for all our Python code.

Django: Additionally, we follow Django’s style guide for templates, views, and other miscellany.

##Code Submission

Please fork VSM on your local repository, and all your modifications should be applied and verified on local repository before generating pull requests.

We used JIRA as the bug tracking system for issues and features tracking, and the system is not hosted for asking general questions, if you are not 100% certain it is a bug, please try to post it on the mailing list first.

##Issue Tracking Workflow The processes described below ensure that careful attention is paid prior to proposed changes being landed, whether the engineer works for Intel or some other contributing organization.

###Bugfix Patch Landing Checklist 0. Make sure the issue is not already assigned to someone else, please pick unassigned issues to prevent duplicated effort.

  1. A VSM JIRA ticket has been opened to track the issue, please include a working demonstration of the problem, if possible, or at least a clear description of the options you're using and the environment (os version, VSM version, browser version, etc.) that you're running under.
  2. Test and commit your patch locally in your own environment
  3. Your patch should follow these requirements for patch submission: * The Commit Comments are well formatted and useful * Verify patch follows VSM Code Style * An new unit test case is optional, but there should be at less one functional test case could be used to verify if the patch is taking expected effect. * The patch has the appropriate signed off by line
  4. Additional test results as appropriate for the patch being landed (interoperability, performance, etc) should be attached to the Jira ticket.
  5. Generate a pull request from your local repository, and keep monitoring feedback from gatekeeper.
  6. The branch gatekeeper will review the patch, confirm the test results, and submit it when everything goes well
  7. If the submission failed due to patch conflict(s), the gatekeeper will ask you to rebase your patch with the target branch and repeat above steps.
  8. If your patch is needed for other branch(es), please repeat above steps against corresponding branch(es).

###Landing a Feature to a Feature Release

  1. Before starting to think about the logistics associated with developing your feature it is imperative to share your plans with the VSM community before you start work.
  2. You should check the community development wiki to see if anyone is already working on something similar. If someone is then add yourself as a watcher to the JIRA ticket and offer to collaborate.
  3. If you are unable to find a match, then open a new JIRA ticket outlining your plans, including the intended purpose of the development and any initial thoughts on design. Then, mail the mailing list to draw attention to the ticket. This will alert Intel and other community members of your intentions and may well result in potential collaborators stepping forward.
  4. If you choose not to do this you may find that you are either duplicating work with someone else, or that your code needs to be reworked to accommodate other changes occurring in the same part of VSM code.
  5. While features will not be scheduled for landing into a release until they are already close to completion, it is still important that the features themselves be discussed before or during early development. This allows developers to take into account other changes that are being worked on, to avoid conflicts in network protocol changes, code restructuring, and to ensure interoperability between releases.
  6. It is also strongly suggested that you gain experience in the VSM landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a VSM feature. Feel free to ask for suggestions on the mailing list for a suitable bug to get started with.

###Feature Landing Checklist

  1. High level design has been reviewed and signed off by a reviewer, if the design is outlined with document, please upload the document to corresponding ticket as well.
  2. At less one functional test case should be provided which could cover the feature, it's optional for unit test case. for features having other side effects, it's also required to provide test cases to cover performance, stability and interoperability.
  3. Those test cases should have been reviewed and signed off by a reviewer.
  4. Results from executing those test cases should have been uploaded to corresponding ticket.
  5. Proposed revisions to the manual have been provided.
  6. The criteria from the Patch Landing Checklist (above) are met.

###Seeking Guidance Please alert in the mailing list if you need some extra guidance in getting your patch submitted for the release.

##License By contributing your code, you agree to license your contribution under the terms of the APLv2: https://github.com/01org/Virtual-Storage-Manager/blob/master/LICENSE, all files are released with the Apache 2.0 license.

If you are adding a new file it should have a header like this:

/**
 * Copyright 2014 Intel Corporation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 * http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

Virtual Storage Manager - Contact [email protected] for questions

Clone this wiki locally