OpenJDK 6 Processes

[Joseph D. Darcy]

Andrew John Hughes wrote:
> 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.
>   

Yes, I've posted a version of the process document on my blog and after 
seeing if any comment come in there, I'll incorporate the process 
document into the OpenJDK 6 project page.

-Joe