Planning your contribution
Depending on the type of changes you plan there are different preferred ways to submit your hard work for inclusion into OpenSG.
- small bug fixes or improvements.
- larger bug fixed or improvements, new classes/cores that fit best into the existing structure.
- new features that do not require core OpenSG changes.
- new features that go along with core OpenSG changes.
If you are unsure you might want to ask us first which would be the best way to start your work.
Small bug fixes or improvements
If your changes are small enough you could submit your changes as a patch for inclusion in OpenSG. If you have / work of a clone of the github OpenSGDevMaster repository a pull request would be the preferred method (see the larger bugfixes section below).
Tickets allow patch tracking in addition to bug and enhancement request tracking. The active tickets report shows current bugs which need fixing as well as other users' enhancement requests. If you fix or implement one of these, your patch should be attached to the relevant ticket. If you fix a bug which is not listed, please create a ticket for your patch and attach the patch to that ticket.
Creating the patch once you've modified your code is easy. From the Terminal, change to the opensg folder. If it is in your home directory, this would be:
and then type:
svn diff > myPatch.diff
where myPatch is a name for your patch. This will create a patch file which has only the changes you've made.
Note 1: If you have created new files, you should do:
svn add Path/To/YourFileName
for each file before running svn diff .
Please be sure your patch has been thoroughly tested and conforms to the coding style guidelines.
You might also want to send an e-mail to one of the MailingLists to notify the developers of the patch.
Larger bug fixed or improvements, new classes/cores that fit best into the existing structure
Larger changes should be staged through a github pull request, see core changes through github.
This allows you to submit you work as a set of patches which you can develop over time while having a full
repository at your disposal to manage your work. It also simplifies the feedback circle with
us, as we can get hold of the current version without tracking down mail attachments, review your work and provide feedback.
It will also keep the history intact once we merge it back into the core repository.
In case you plan to add new classes / cores please get some quick feedback from us whether we think your work is better staged through this method or through the next.
New features that do not require core OpenSG changes
New features that go along with core OpenSG changes
Work that falls into this category should be a combination of the two previous methods. Core
changes should be staged through the github pull request mentioned above for larger fixes and improvements.
The independent parts should start life as a separate set of libs following the 'new features that do not require core changes' path.