-
Notifications
You must be signed in to change notification settings - Fork 25
Contribution guidelines
We're open to feedback on this process. Feel free to suggest changes or ask questions!
- Discuss changes with the developers through GitHub Issues or the Mailing List
- Keep patches small, as single logical changes.
- Patches shouldn't break things---even if they're fixed it a later patch.
- Send a pull request on GitHub so the community can review the changes.
The RouteFlow organisation is set up to allow the community to maintain the core RouteFlow code and various RFProxy implementations all from one convenient place on GitHub. To keep things running smoothly, we've put together some guidelines on how to manage this repository to balance code quality with the ease of access for new contributors.
The RouteFlow repository holds the core components of RouteFlow:
- RFClient
- RFServer
- POX-RFProxy
The main two branches that are maintained on this repository are master and vandervecken. Both of these branches are maintained with stability in mind, so that when anyone wishes to clone the repository, they will get a working version of RouteFlow. Additional branches for features or projects may also be created, to allow other people to collaborate more closely (e.g., GSoC projects).
- master is maintained by Allan Vidal and CPqD. This branch is considered the canonical version with stable, accepted features and changes.
- vandervecken is maintained by Joe Stringer. In general, this branch changes more often, and may include various fixups and experimental features from people involved in that project.
This port is currently maintained by Joe Stringer.
Ryu-RFProxy is a port of RFProxy to the Ryu-2.0 platform, with OpenFlow 1.2 support. It is actively maintained and in use as part of Project CARDIGAN.
This port is currently unmaintained.
NOX10-RFProxy is a port of RFProxy to the NOX-Classic platform, with OpenFlow 1.0 support. It is known to compile and work on Ubuntu 11.10 with the March 2013 versions of RouteFlow. This code could theoretically be ported to a later NOX-Classic platform without major changes.
Before performing some work on RouteFlow, it is recommended that developers send an email to the RouteFlow mailing-list or report an issue in GitHub to discuss the changes. This way, the community can give feedback on the approach. Final patch-sets should be sent as a pull-request on GitHub. Each patch should only make a single logical change. Code tidy-ups should be separate from functional changes. Lots of small patches is preferred over sending one large patch. Pull requests should be tested by the submitter to ensure that there are no functionality regressions. Patches should be signed off by the submitter to indicate that they accept the terms of the related open source initiative licenses and are held responsible for any copyright issues of the submitted code.
The RFProxy implementations are kept reasonably small so that it is easier to run RouteFlow on multiple controller platforms. If you've ported RFProxy to a new controller, get in touch on the mailinglist and we can add the implementation to the core repository's build.sh script, so that people can install your RFProxy port directly from the main repository.
RFProxy repositories must include a README being explicit about which version of the controller platform is being used (eg, Ryu v1.2) to minimise confusion. The RFProxy repository's master branch should work with the master branch of RouteFlow core. RFProxy repositories may include a copy of the controller platform. If this is included, the master branch should periodically synchronised with upstream controller development.