OpenShift Origin is Open Source
OpenShift Origin is the official upstream source for the various bits hosted at http://openshift.redhat.com/. This code is actively developed by several paid Red Hat engineers. We’re not just following the letter of open source, we’re also following the spirit of it. This post is designed to explain to people who are interested in making changes to OpenShift how to actually get their code accepted.
The first thing to understand is that we’re trying to grow the community organically. We’re not setting a bunch of arbitrary of rules for how things need to work. If you have suggestions, let us know. It is, however, important to remember that we have several teams at Red Hat who are paid to work on OpenShift. Everything from development engineering, to quality engineering to operations are involved with every release.
Understanding the Development Process
There’s a balance to be had. To understand how to best get your changes into OpenShift you must first understand how our development process works. We’re presently in a three week development cycle. At the end of each of those cycles we release. With a few exceptions, every release ends up on http://openshift.redhat.com/.
The end of the sprints are very focused on bug fixes, quality control and testing. Lots and lots of testing. Therefore, the end of a sprint is probably not the best time to be making major changes for that sprint. The beginning of our sprints, then, are very engineering focused. It’s the start of the sprints that will have the highest likelihood of your code getting accepted. How do you know when the start of the sprint is? Ask!
Which brings me to my second note. Find people and ask questions. We hang out in #openshift and #openshift-dev on irc.freenode.net. Keep in mind most of us work during normal work hours between EDT and PDT time zones. Some of us are available after that. Finding someone to work with you on a merge is tricky but worth it, especially if your commit is functional or feature based. Most bug fixes (few lines of code here or there) are easier to accept. Bigger changes may take a bit more planning.
How the Process Works
That’s a view of the process of making changes. Lets look at where to make changes and how it all works. There are three main divisions in OpenShift Origin. The client facing user interface bits, the broker code and the node code. The node and broker code can be found in our crankcase repo:
The CLI tools are located here:
We’re using github which allows everyone to do pull requests. Here’s the official help:
It is via these pull requests that you can create forks of our software, alter them, then submit back to us for review and inclusion in the upstream repos. To do this, create an account at http://github.com/, next browse to one of our repos (like https://github.com/openshift/crankcase/) and click on the “fork” link at the top. This will create a fork of the repo in your own github space.
Next, clone YOUR version of the repo. Make your changes, push it back to your version of the repo. Then, browse to your repo and click “Pull Request” at the top, not the “Pull Requests” link below it. This will allow you to fill out a merge request (comments, justifications, links to bug fixes, etc).
When making a change, make sure you test it! If it’s a new feature, write a unit test or functional test for it. We’re using the Rails testing framework, as well as Cucumber for almost all of our continuous integration. Any new feature requires test before it will be included. We’re happy to direct you to the right locations. If you have the result from a test, include it in your merge request (copy and paste it into the comment or something). If you can demonstrate that you’ve made a change and have tested it with our own framework. That goes a long way to making the merger feel comfortable accepting your change.
The next step is incredibly important. Find someone to merge your request. This gets easier as you get used to who’s working on what. There’s a lot of us out there. The longer a merge request stays out there, the harder it will be to merge and the higher likelihood it will be rejected for some reason. Throwing code over the wall and hoping someone else deals with it is the least likely way to get a patch included in OpenShift.
Merge reviews take time, and some of the more complicated ones require our more senior engineers to review to make sure things continue to work as expected. Unfortunately, these same engineers are often busy with releases, deadlines, etc.
Hacking on OpenShift Origin is FUN!
I know I’m a bit biased, but this is a really fun project to work on. We’re looking for help on every aspect of OpenShift. If you’re looking to just get started, pick a couple of bugs. It’ll help you get introduced to the code and just as importantly, to the other developers. Here’s a list
Anyway, jump in, look around, get an environment going and come chat on #openshift-dev. We’re looking forward to working with you. The code you contribute will be under Apache License 2.0. so what are you waiting for? Come, help us make it better.