Apache OODT CM demystified

The OODT Configuration Management (CM) area or my project's CM?

Have you ever wondered where you should put the code you're developing? We all have! Here's a small little process that I (Chris Mattmann) use to distinguish when it's best to try and get something into OODT Git, versus just committing it locally to my project.

Rules of Thumb

1. OODT CM is watched by a bunch of people. Because of this, I usually try and put code onto the OODT CM that I want vetted in the community.
2. If the code is sufficiently generic, then I try and figure out which OODT component it belongs in and then:
   1. file a JIRA issue identifying my intention;
   2. wait some time, then attach a patch against the current trunk of one of the components which provides the functionality which the issue describes; and then;
   3. if there are no objections/discussions/etc. raised, move forward with committing it or having someone with permissions commit the code. Filing issues in JIRA alerts the community as well to your intention and lets them follow along on email too.
3. Once the code is in OODT CM, then I update my project specific CM with new pointers to the version of the OODT component that contains my updated functionality. This involves updating Maven usually. The OODT lifecycle is different than the project lifecycle so you can’t always guarantee that there are enough $free cycles in OODT land to get a release out with your new patch so be prepared to either:
   1. keep your patch local to your project CM, implement it there where you have control, and then wait for the official OODT release to decommission your local project patch; or
   2. kindly ask yell at one of the existing OODT Release Managers (RMs) on one of the mailing lists (e.g., dev@ or user@) that you think it would be great to make a release and hope folks have enough time and energy to volunteer their time to do so! Or, better yet, contribute, become a committer, and roll the release yourself!