OpenJDK quality process

How is quality ensured in the openjdk project?
The jdk release team strongly believes in "quality is built in and not tested in" motto. And to support that we have incorporated industry standard best engineering and quality practices throughout the release process. One of the key advantages of these openjdk bits is this source base gets benefit from extensive testing done by engineering and the quality team on the commercial JDK bits. [Except for the minimal encumbered portions of the source.] We do have set milestones and release criteria at each milestone to ensure bits reach the desirable quality for each of the set milestones. We will make the information on these milestones and criteria once jdk7 gets going and we have the drafts for these available for community feedback.

Sun's internal quality teams will focus their energies mostly on the commercial bits. Openjdk bits, being pretty much the same as commercial bits, do get the benefit of this testing. Apart from this indirect benefit quality teams will also test the openjdk bits at regular intervals to ensure a certain quality is maintained in those bits. We will also be looking forward to the community to pitch in for the quality activities around the openjdk bits. Take a peak at how you can help.

Test methodologies	A broad range of testing methodologies are used to qualify the JDK against the agreed upon release criteria. To produce a robust, performant, stable, and high quality implementation of the Java platform.
Test phases	Incremental test phases are defined in the release cycle to find bugs as early in the development cycle as possible Unit Testing – At engineering level Nightly Testing - Identified automated tests running nightly on the component workspaces Pre Integration Testing – Based on the putbacks for a build, execution of subset of tests to find severe quality issues. SWAT testing – Towards milestones, a set of basic acceptance tests run before each build promotion to catch DOAs (Dead On Arrival). System testing – For each build most tests are run for identified set of test configurations. The configurations keep rotating each build to cover all different supported Operating Systems, Product modes, testsuites etc.
Configurations tested	The number of operating systems, window managers, browsers, and other variables we have to support and test is humongous. The combinations we test to ensure Java's promise of "write once, run everywhere"
Release criteria [TBD]	The criteria for the release. This will be drafted in due time as governance constitution formalization takes place. Stay tuned...