Plastic: PR Acceptance Criteria

All approved PRs must meet the following project requirements:

Coding style and Guidelines

ODL has Java coding styles and guidelines that all Java-based code should meet.

This is currenly on the honor system, as there is no enforcement in this project (yet).

There are no guidelines yet for the Groovy-based code, so an informal observation of existing code norms is acceptable.

Testing

All code will be backed by unit tests, which are written almost exlusively in Spock (a Groovy framework).

Multi-class integration tests are encouraged and can substitute for and augment the unit tests.

Tests must be run as part of every compile/build.

Code Review

Adherence to ODL's use of the Gerrit tool for reviews is mandatory as is the approval process.

Performance Regressions

All changes need to test against performance. Currently performance testing is embodied in a small number of "unit level" tests (ie, Spock tests) that are named with "Stress" as part of the test name. Because these can take time, they are not enabled by default in the build. These need to be temporarily enabled and run, and the results included in your PR, if your changes can affect performance. Note that sometimes Groovy can do surprising things in byte code, so err on testing performance.

A long term goal for this project is to enable stress tests and to break the build if performance degrades regressively compared to the previous release.

Backwards Compatibility

All changes need to strive to be backwards compatible. Existing client code should not break. If a breaking change is needed, this must be approved in advance and separate to any code change through the PTL. There needs to be a minimum of 4 weeks notice to the PTL (and stakeholders) before a breaking change will be accepted. Such notice must be done via email to the PTL and through the plastic-dev email list. This allows stakeholders to plan for remediation if they want to accept new versions of this project.