JDK 7 Development Process
=========================
DRAFT 1 / 26 February 2009
In the continuing transition of JDK development activities to a more
open, collaborative model, we're going to completely revise the JDK
development process. The sketch presented here is based on the past
thirteen years of the Sun JDK team's experience, seasoned by ideas and
lessons learned from other, mainly non-Sun projects.
This is just a first draft. There's no one obviously "right" way to
design this sort of process; this is a starting point. Comments are,
as always, most welcome: jdk7-dev at openjdk dot java dot net.
This process is more involved than that of many free-software or
open-source projects. This is a result of the JDK team's strong
commitment to the highest standards of quality, compatibility, and
performance, and also the fact that we're maintaining and evolving not
just a large body of code but, simultaneously, the specification of one
of the world's most widely-used programming platforms.
Ultimately we will leverage our new Bugzilla instance to automate the
tracking of the various review and approval paths defined here. That's
an implementation detail, however; for now let's focus on getting the
process into a workable form.
Teams
-----
Release Team
The Release Team (RT) manages the feature list, controls changes to the
code base so as to gradually limit change over time, and in general is
responsible for delivering the release. Decisions are made by rough
consensus whenever possible; when consensus is not possible then the
chair makes a decision.
The Release Team members are Joe Darcy (Core), Phil Race (Client), Paul
Hohensee (VM), Vita Santrucek (Quality), and Mark Reinhold (chair).
Design Team
The Design Team (DT), a superset of the Release Team, is a broad group
of active, experienced senior engineers from both inside and outside
Sun. This team helps ensure the ongoing integrity, correctness, and
performance of the platform and the code by reviewing language, API,
and other interface changes throughout the release, and also by
reviewing code in the later stages of the release. The DT is on the
hook to provide timely reviews of some types of changes; it has the
right to review other types of change. The DT can provide design
advice and consultation on request.
The Design Team does not in any way supersede the authority of the JCP
over the SE Platform Specification or its component JSRs. The DT will
typically review component JSRs as they are being developed and offer
suggestions and advice to the spec lead, but the DT has no power to
mandate specific changes. Smaller specification changes will first be
reviewed by the DT and then submitted for review by the JCP as part of
the usual JSR maintenance-release process.
(As of this draft, the Design Team is being formed.)
Maintainers Team
Each distinct component of the code base is owned by one or more active
engineers who are responsible for reviewing changes to it and serving
as an initial point of contact for questions, bugs, and other issues.
(The Maintainers Team as a whole does not have a specific role.)
(TODO: Identify Maintainers)
Feature Teams
Each approved feature is designed, implemented, and delivered by a
cross-functional Feature Team whose members are responsible for
development, quality, JCK tests, documentation, and user experience.
Not every Feature Team will have a distinct member for each of these
roles; indeed, for a small feature a Feature Team can be just one
engineer. Teams for large features, however, will typically have one
or more members serving in each role.
(TODO: Identify Feature Teams)
Schedule
--------
The development timeline will be divided into a sequence of milestone
cycles, each six to eight weeks in length. There will be no formal beta
or early-access releases, as in the past.
Rationale: Past JDK feature-release cycles have been structured
around one or two beta releases and then a final push to FCS
("first customer ship"). This model worked reasonably well when
nearly all development was done within Sun and binaries were
only published at the beta and release-candidate milestones.
During JDK 6 we published binary builds every week and found,
to some surprise, that we received roughly the same amount of
feedback throughout the release but relatively little in
specific response to the formal beta releases.
Producing formal beta releases is a relatively expensive
exercise, and shipping weekly builds is relatively cheap, so
since the former don't yield significant feedback in the
presence of the latter we're just going to do the latter for
JDK 7. This will not only save effort but will also allow us
to adopt a more agile, milestone-based development schedule.
In early milestone cycles all types of changes will be allowed in all
but the last two weeks. The last two weeks of each early cycle are for
stabilization, i.e., fixing bugs discovered earlier in the cycle or
during previous cycles. During early-milestone stabilization periods
each change must be approved by a Release Team member.
Major features and other potentially-destabilizing changes should be
targeted for integration in the first two weeks of a specific milestone.
Features will be integrated only when complete, or very nearly so.
In later milestone cycles, changes will be more strictly controlled.
Each change will require the approval of a Release Team member except
during the last two weeks of a cycle, in which the entire Release Team
must approve each change.
(TODO: Post detailed milestone schedule)
Features
--------
The major work items of the release are organized into Features.
A Feature is, roughly speaking, a change of which at least one of the
following statements is true:
- It requires two or more weeks of engineering effort,
- It's a significant or controversial change, or
- It's in high demand by customers or developers.
A feature can be a logically independent project or a consolidation of a
set of closely-related bug fixes or enhancements.
Bug fixes and small enhancements are generally not considered to be
Features, and they do not need to be related to a specific Feature.
To propose a new Feature for inclusion in the release, the first step is
to write up a Feature Proposal and circulate it to the jdk7-dev list or
other lists, as appropriate, for comment and feedback. (A template will
be provided; it will look much like a traditional Sun "one pager"
document.)
When you're ready, submit your proposal to the Release Team for initial
review and approval. The RT will evaluate your proposal and decide
whether it merits inclusion in the release.
A Feature, once approved, is subject to two further approval steps:
- Design Review: Once an overall approach and design is complete it
should be submitted to the Design Team for review.
- Final Review: When the Feature is nearly ready for integration it
should be submitted to the Design Team for review and to the Release
Team for final approval and targeting to a specific milestone build.
Owners of Features already approved for JDK 7 will be asked to write and
publish a Feature Proposal, but in most cases this can be constructed
from existing documents, e.g., Sun's internal JDK feature-planning
database or team-specific one-pagers. Previously-approved Features will
be subject only to the Final Review step.
TODO: Still to come
-------------------
Documenting changes -- How to describe code/API/specification changes
Reviewing changes -- The change-review process