Contributing

Contributing to OpenXT will be a bit awkward while we're establishing our process. Currently we're transitioning from a closed to an open source model so we don't yet have a handle on all of the new tools that we're using. For now this page is a "best practices" sort of guide.

Collaboration Tools

We're using the available free tools as much as possible. You're reading this on GitHub so you already know that we're using GitHub to host our repositories. This wiki feature is nice as well so we're migrating / building up our documentation here. We also have a "Google Group" set up for general discussion:

https://groups.google.com/forum/#!forum/openxt

Feel free to join the group and discuss any / all aspects of the project. The use of these tools is subject to change in the future. If it turns out that (for instance) the Google Group doesn't work the way we want / need it may be that some will expend the resources to set up an "old-school" mailing list. But for now, we're sticking to the free stuff.

Workflow

There are a number of ways you can contribute to OpenXT. In the future we hope to have documentation to describe how you can contribute through testing, documentation, translations etc. The first step though is getting people to contribute code.

To do this the first thing you need to do is build the existing code. This isn't particularly difficult but there is a learning curve. Start with the instructions here: How to build OpenXT

Fork

Once you've got a functional build the first thing you need to do is fork the relevant repo from the OpenXT organization. GitHub already has great docs for the using the fork and merge request features so be sure to read up on those first:

https://help.github.com/articles/fork-a-repo

https://help.github.com/articles/using-pull-requests

For a simple example we can look at some of my previous work in which I modified some of our build metadata. In this example I moved some bitbake functionality common to two image recipes into a class and added a little bit of logging to detect a weird edge case that has given me trouble in some testing. Before you make any changes though, be sure to fork the relevant git repo from the OpenXT organization (did I say that already?). So in this case our build metadata is in the xenclient-oe.git repo so I'd fork that.

Once you've got your own fork of the repo you need to go into the right place in your local build and set up a new remote to work from your fork. Let's assume that your build tree is relative to /usr/src. You'd want to go into the directory where the xenclient-oe.git repo is checked out and set up your new rewmote:

$ cd /usr/src/openxt/build/oe
$ git remote -v
origin  git://github.com/OpenXT/xenclient-oe.git (fetch)
origin  git://github.com/OpenXT/xenclient-oe.git (push)
$ git remote add mygit git@github.com:flihp/xenclient-oe.git
$ git remote -v
mygit   git@github.com:flihp/xenclient-oe.git (fetch)
mygit   git@github.com:flihp/xenclient-oe.git (push)
origin  git://github.com/OpenXT/xenclient-oe.git (fetch)
origin  git://github.com/OpenXT/xenclient-oe.git (push)

Knowing that the OpenXT build scripts checkout this repo at this specific path isn't something that people will know off the top of their head. This is where the learning curve for contributing to OpenXT is steepest. The best thing to do when you have questions like this is to go into the #openxt IRC channel on freenode and ask.