Request for comments: JDK 7 Development Process

[Phil Race]

Mark,

 >    http://cr.openjdk.java.net/~mr/jdk7-dev-process.html


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


In an "openjdk" view the release is mainly a set of source files.
 From Sun's point of view its also what's used to create a supported
set of production binaries for a set of platforms, supporting documentation,
training material etc etc.
And the release team drives delivery of both of these, managing to
a schedule derived from the approved feature list.

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

I'd expect this team to be consulted for major or controversial changes
in the implementation, even if they don't bubble up into the platform spec.
The way I read this, something like MVM-lite isn't automatically on the
radar of the design team, even if it "it has the right to review other types of change."
In other words make this team aware of changes that meet the test of being
a "feature", even if they aren't API.

I'm also not at all sure about the inclusion of code reviews, and
"later stages" is rather vague, as is "timely reviews".
So I'd delete the code review part, and explain what timely means.

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

I suppose we have something close to that in the notion of a JCP spec
lead becoming the maintainer afterwards. I think for a feature that's
within a group you'd just say the group as a whole is the maintainers team.
But where a "feature" spans say AWT, 2D, libs, VM then you can get a bunch
of people together to develop it as a feature team, but I rather doubt
that we'd be able to hold together that group forever in any formal way.
And when you have JSR maintainers, feature maintainers, and openjdk groups
there's some overlap/duplication potential. Maybe rather than individuals,
the maintainers "team" is identified by the groups that need to be involved,
and there's no formal team.

..



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

I'm rather concerned as to the impact of this on some normal operations,
or at least we need to spell it out.
- Major features can't go into a team repo because that would mean
the team can't integrate other work until the next milestone opens.
- The feature repos would need to be built and tested and likely become
   integration repositories - ie ones that go directly to JDK7 master,
   or some other team repo would need to be the gateway.
- You only get one build to get the feature in, so you'd better be ready.

..


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

I'm having trouble picturing what that last one is about.
Do you have examples of things in high demand that aren't otherwise significant ?

-Phil.

PS I suspect this may not get added to the original thread since I can't locate
the original message to which to reply.