JDK7: Buffering and stabilization

[Martin Buchholz]

Jonathan,

Thank you very much for this initiative.
I strongly agree that integration workspaces should always be open for business.
The pain of any temporary restrictions should be contained within the
gatekeeper community.

I would go further than you and suggest that two separate "MASTER"s
should be maintained - an ongoing "development" MASTER and a
"stabilization" MASTER.  The stabilization MASTER is
created from regular MASTER via fclone, and subsequently
selected fixes are "cherry-picked" from the development MASTER
to the stabilization MASTER.  That appears to be the
standard process in the industry.
"Cut a branch; cherrypick fixes to the branch until happy."

I suspect that developers and early adopters
will generally ignore the stabilization branch,
as shown by the history of early feedback for
beta releases in the past.

Martin

On Wed, Apr 22, 2009 at 11:38, Jonathan Gibbons
<Jonathan.Gibbons at sun.com> wrote:
> JDK folk,
>
> Recent announcements [1] have changed the rules for integrating changes into
> OpenJDK JDK7.
>
> Introducing a plan for generating stable milestone builds is a Good Thing,
> but as anyone knows who likes to throw rocks in a river,  water has a
> tendency to find its own way.
>
> In this case, the water takes the form of suggestions inside and outside Sun
> to workaround the impediment of restricted access to the integration
> workspaces as each milestone appears.  These workarounds are taking the form
> of setting up and/or using alternate integration areas for use while the
> primary integration areas are locked down.
>
> It would seem, by their nature, that there will be fewer stabilization fixes
> for each milestone than there will be features for the following milestone.
>
> Therefore, rather than have individual groups set up their own private
> integration areas, I'd like to suggest we create a single new forest for
> pushing changes to stabilize the master repository for a upcoming milestone
> -- and we leave the main integration repositories open for business,
> accumulating changes until they can next be pushed to the master.
>
> Thus the proposal would be:
>   -- milestone putback approvals still required (no change)
>   -- when a milestone approaches, the integration areas remain generally
> open for business, but temporarily hold off pushing changes to the master
>   -- when a milestone approaches, access to the master is only via the new
> "stabilization" forest which is just used for those changes that are
> necessary to stabilize the upcoming milestone
>
> Such a scheme would save developers from having to workaround the "on-again
> off-again" access to the integration areas, that we have now.  The cost is
> just one more forest to be built and tested (compared to the many that
> otherwise might now be expected to spring up.)
>
> -- Jon
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-April/000526.html
>