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