Versions Compared

Old Version 5

changes.mady.by.user Ross Laidlaw

Saved on

compared with

New Version Current

changes.mady.by.user Tom Barber

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Overview

This document describes how to contribute to OODT. The purpose of this document is to help you as developers take the next step in becoming contributing members of the OODT community. We will cover a general overview of the OODT development process including the different pieces and how they fit together. We will cover how the community works and interacts, using the mailing lists to search for information and how to ask questions to ensure that they get answered. We will also cover how to go about learning the internals of the OODT codebase. We will cover how to use the JIRA for change requests and how to start developing for OODT. And finally we will cover contributing back to the OODT community. When we are finished you should have a good understanding of how the community works and how you can go about becoming a bigger part of that community.

...

You will also want to perform functional testing of your new code within your own environment as well as make sure that the build and javadoc are successful with your new code. Once your code has been completed and tested then it is time to create a patch.

Start by checking to see what files you have modified with: svn stat.

Keep this list for later because you will want to make sure that only code that you have changed is included in your patch.

In order to create a patch, just type:

svn diff > yourPatchName.patchYou can follow the guide here: https://cwiki.apache.org/confluence/display/OODT/Steps+to+generate+patches

This will report all modifications done on the OODT sources on your local disk and save them into the yourPatchName.patch file. Read the patch file. Make sure it includes ONLY the modifications required to fix a single JIRA issue.

Please do not:

  • reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits.
  • comment out code that is now obsolete: just remove it.
  • insert comments around each change, marking the change: folks can use subversion to figure out what's changed and by whom.
  • make things public which are not required by end users.

...