OpenJDK 6 Processes

[Jonathan Gibbons]

Joseph D. Darcy wrote:
> Since questions about OpenJDK 6 processes come up from time to time, I 
> thought it would be helpful to more fully document the current 
> engineering practices and receive comments about them on the list.
>
> OpenJDK 6 is an implementation of the Java SE 6 specification valuing 
> stability, compatibility, and security.  As an implementation of the 
> Java SE 6 specification, all changes to OpenJDK 6 must be allowable 
> within that specification.  This requirement precludes many API 
> changes.  Acceptable API changes include those permitted by the 
> endorsed standards mechanism, such as upgrading to a newer version of 
> a standalone technology, like a component JSR. [1]  One example of 
> such an API change was the upgrade of JAX-WS from 2.0 to 2.1 in 
> OpenJDK 6 build b06. [2]
>
> Changes allowable within the Java SE 6 specification may still be 
> rejected for inclusion in OpenJDK 6 if the *behavioral compatibility* 
> risk is judged as too large. [3] [4]  Behavioral compatibility 
> concerns implementation properties of the JDK.  Clients of the JDK can 
> knowingly or unknowingly come to rely upon 
> implementation-specification behaviors not guaranteed by the 
> specification and care should be taken to not break such applications 
> needlessly.  In contrast, if a change is appropriate for every other 
> JDK release train, it is generally appropriate for OpenJDK 6 too.  
> Examples of such universal changes include security fixes and time 
> zone information updates.
>
> With the above caveats, bug fixes in JDK 7 that do not involve 
> specification changes have presumptive validity for OpenJDK 6.  That 
> is, by default such fixes are assumed to be applicable to OpenJDK 6, 
> especially if having "soaked" in JDK 7 for a time without incident.  
> On a related point, the fixes from the stabilized HotSpot forests (for
> example HotSpot Express 14 [5] or HotSpot Express 16 [6]) are suitable 
> for bulk porting to the OpenJDK 6 HotSpot forest without review of 
> individual bugs.
>
> As a general guideline, if a change is applicable to both JDK 7 and 
> OpenJDK 6, the change should be made in JDK 7 no later than the change 
> is made in OpenJDK 6.
>
> With the exception of security fixes, all OpenJDK 6 code review 
> traffic should be sent to jdk6-dev at openjdk.java.net for consideration 
> before a commit occurs.  (For subscription instructions and to browse 
> the archives see 
> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev)  All fixes 
> require the approval of the release manager and may require additional 
> technical review and approval at the discretion of the release 
> manager.  Security fixes are first kept confidential and applied to a 
> private forest before being pushed to the public forest as part of the 
> general synchronized publication of the fix to effected JDK release 
> trains.
>
> The master Mercurial forest of OpenJDK 6 repositories resides at:
> http://hg.openjdk.java.net/jdk6/jdk6
>
> Since there is only a single master OpenJDK 6 forest, near the end of 
> a build period the release manager may defer otherwise acceptable 
> changes to the start of the next build. [7]
>
> The schedule to tag builds of OpenJDK 6 is on an as-needed basis.  The 
> timing and feature list of a build is coordinated on the jdk6-dev 
> alias with the IcedTea 6 project [8], a downstream client of OpenJDK 
> 6.  Before a build is tagged, regression and other testing is 
> performed to verify the quality of the build.
>
> Comments on any of the above?
>
> -Joe Darcy
> OpenJDK 6 Release Manager
>
> ------
>
> [1] "Java Endorsed Standards Override Mechanism",
> http://java.sun.com/javase/6/docs/technotes/guides/standards/
>
> [2] "OpenJDK 6: Sources for b06 Published,"
> http://blogs.sun.com/darcy/entry/openjdk_6_sources_for_b06
>
> [3] "Kinds of Compatibility: Source, Binary, and Behavioral,"
> http://blogs.sun.com/darcy/entry/kinds_of_compatibility
>
> [4] "JDK Release Types and Compatibility Regions,"
> http://blogs.sun.com/darcy/entry/release_types_compatibility_regions
>
> [5] http://hg.openjdk.java.net/hsx/hsx14/master
>
> [6] http://hg.openjdk.java.net/hsx/hsx16/master
>
> [7] Alternatively, in JDK 7 there are a hierarchy of staging 
> integration forests under the master to manage a higher rate of change 
> (see "OpenJDK Mercurial Wheel",
> http://blogs.sun.com/kto/entry/openjdk_mercurial_wheel).  As the rate 
> of change in OpenJDK 6 is comparatively small, as long as the end of 
> build quiet periods continue to be acceptably short, having a single 
> master forest should be simpler than starting and managing an 
> intermediate staging forest kept open to accepting changes at all times.
>
> [8] http://icedtea.classpath.org/wiki/Main_Page
>

You might consider posting these processes on the OpenJDK 6 project page 
here: http://openjdk.java.net/projects/jdk6/

-- Jon