OpenJDK 6 Processes

[Andrew John Hughes]

On 25 March 2010 23:21, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> 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
>

Yes, I was sort of presuming they would be posted somewhere... and
there seems a good place. +1.
-- 
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