OpenJDK 6 Processes

[Andrew John Hughes]

On 25 March 2010 22:58, Joseph D. Darcy <Joe.Darcy at sun.com> 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?
>

Reads well.  A good summary of the status quo IMO.  Thanks for writing this up.

Note there is a hs17 branch now, which we probably want in b20 (should
have stabilised by then).

> -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
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8