JDK7: Buffering and stabilization

[Maurizio Cimadamore]

+1
This would be great as it will reduce the amount of time a 
fix/enhancement stays in our personal repository, which I think it's 
good especially in those areas where some feedback is needed.

Maurizio

Jonathan Gibbons 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